Null deref under PluginView::handlesPageScaleFactor()
https://bugs.webkit.org/show_bug.cgi?id=119231
<rdar://problem/14440207>

Reviewed by Darin Adler.

Null-check the PluginView in the caller as well.

* WebProcess/WebPage/WebFrame.cpp:
(WebKit::WebFrame::handlesPageScaleGesture):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153486 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Null deref under WebPage::scaledSnapshotWithOptions
https://bugs.webkit.org/show_bug.cgi?id=119243
<rdar://problem/14502050>

Reviewed by Darin Adler.

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::scaledSnapshotWithOptions):
WebFrame::coreFrame() can be null (if the Frame is already torn down),
so we should check it.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153487 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Plug-in process crashes if plug-in is destroyed as a result of sending NPObjectMessageReceiver::Deallocate
https://bugs.webkit.org/show_bug.cgi?id=119270
<rdar://problem/13368226>

Reviewed by Darin Adler.

Normally we use the PluginDestructionProtector RAII object to prevent plug-ins from being destroyed while
they're executing code. However, in the case of the NPObjectMessageReceiver::Deallocate message, we can't do this
since we don't know the plug-in or connection.

Instead, add a counter to Connection that keeps track of whether sendSync is currently called and defer plug-in
destruction if it is. (This approach is actually more robust and we should investigate getting rid of the destruction protector).

* Platform/CoreIPC/Connection.cpp:
(CoreIPC::Connection::Connection):
(CoreIPC::Connection::sendSyncMessage):
* Platform/CoreIPC/Connection.h:
(CoreIPC::Connection::inSendSync):
* PluginProcess/PluginControllerProxy.cpp:
(WebKit::PluginControllerProxy::destroy):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153488 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, add my new email to contributors.json.

* Scripts/webkitpy/common/config/contributors.json:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153489 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Compile fix for WebGL on 32-bit Windows.
https://bugs.webkit.org/show_bug.cgi?id=119235

Reviewed by Darin Adler.

* platform/graphics/GLContext.cpp:
Created GLNativeWindowType typedef.
(WebCore::GLContext::createContextForWindow):
* platform/graphics/GLContext.h:
Replaced uint64_t with GLNativeWindowType.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153492 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix typo in enum name ("SelectionInSnaphot" -> "SelectionInSnapshot")
https://bugs.webkit.org/show_bug.cgi?id=119275

Reviewed by Simon Fraser.

* WebCore.exp.in:
* page/FrameView.cpp:
(WebCore::FrameView::paintContentsForSnapshot):
* page/FrameView.h:
Fix typo.

* WebProcess/InjectedBundle/DOM/InjectedBundleNodeHandle.cpp:
(WebKit::imageForRect):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::scaledSnapshotWithOptions):
Fix typo.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153493 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Inactive style sheets should not trigger style recalc when loaded.
<http://webkit.org/b/119236>
<rdar://problem/14588132>

Reviewed by Antti Koivisto.

Style sheets that are either alternate sheets or are excluded by their media query should not trigger
a full style recalc when they finish loading, since the end result will not be observably different.

The sheets are still inspectable through document.styleSheets.

Changed enums from Blocking/NonBlocking to ActiveSheet/InactiveSheet to clarify what's going on.

* html/HTMLLinkElement.h:
* html/HTMLLinkElement.cpp:
(WebCore::HTMLLinkElement::HTMLLinkElement):
(WebCore::HTMLLinkElement::setDisabledState):
(WebCore::HTMLLinkElement::process):
(WebCore::HTMLLinkElement::startLoadingDynamicSheet):
(WebCore::HTMLLinkElement::addPendingSheet):
(WebCore::HTMLLinkElement::removePendingSheet):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153494 268f45cc-cd09-0410-ab3c-d52691b4dbfc