Image menu is offset by the amount the view is scrolled
<rdar://problem/16818966> and https://bugs.webkit.org/show_bug.cgi?id=132663

Reviewed by Tim Horton.

* WebCoreSupport/WebContextMenuClient.mm:
(WebContextMenuClient::showContextMenu): Use FrameView::contentsToWindow instead of contentsToRoot,
  and skip the [NSView convertPoint:toView:] step.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168438 268f45cc-cd09-0410-ab3c-d52691b4dbfc
HTMLMediaElement should exitFullscreen when view is removed from the window.
https://bugs.webkit.org/show_bug.cgi?id=132506

Patch by Jeremy Jones <jeremyj@apple.com> on 2014-05-07
Reviewed by Tim Horton.

Source/WebCore:
* platform/ios/WebVideoFullscreenControllerAVKit.h:
Add -requestExitFullscreen.

* platform/ios/WebVideoFullscreenControllerAVKit.mm:
(-[WebVideoFullscreenController requestExitFullscreen]):
Forward request onto WebVideoFullscreenModelMediaElement.

* platform/ios/WebVideoFullscreenModelMediaElement.mm:
(WebVideoFullscreenModelMediaElement::requestExitFullscreen):
Add some protection here since this may be called when not in fullscreen.

Source/WebKit/mac:
* WebView/WebView.mm:
(-[WebView viewDidMoveToWindow]):
Request WebVideoFullscreenController to exitFullscreen when view is removed from the window.

Source/WebKit2:
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::viewStateDidChange):
Request WebVideoFUllscreenManagerProxy to exitFullscreen when removed from the window.
* UIProcess/ios/WebVideoFullscreenManagerProxy.h:
Make requestExitFullscreen() public instead of private.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168439 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] Acclerated overflow-scrolling broken in WK1
https://bugs.webkit.org/show_bug.cgi?id=132665
<rdar://problem/16842909>

Reviewed by Tim Horton.

r168301 added a CALayer delegate to disable implicit animations,
but for some layers we wrap them in UIViews (which are themselves
layer delegates), so bad things happened.

Fix by falling back to setting the null actions dictionary for
layers with custom scrolling behavior.

* platform/graphics/GraphicsLayer.h:
* platform/graphics/ca/mac/PlatformCALayerMac.h:
* platform/graphics/ca/mac/PlatformCALayerMac.mm:
(PlatformCALayerMac::updateCustomBehavior):
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateScrollingLayers):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168440 268f45cc-cd09-0410-ab3c-d52691b4dbfc
<rdar://problem/16831276> [iOS] Unparenting a WKWebView that’s loading pauses it
https://bugs.webkit.org/show_bug.cgi?id=132659

Reviewed by Tim Horton.

* UIProcess/Cocoa/NavigationState.h: Added a member variable.
* UIProcess/Cocoa/NavigationState.mm:
(WebKit::NavigationState::didChangeIsLoading): When transitioning into loading state,
acquire a background activity token. When transitioning out of loading state, dispose of
the token.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168441 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Mac, iOS] REGRESSION: WK2 YouTube support
https://bugs.webkit.org/show_bug.cgi?id=132568
<rdar://problem/11464344>

Reviewed by Darin Adler.


Source/WebCore: 
Move the custom YouTube loader code out of the WebFrameLoaderClient into a
PluginReplacement-based class.

* Modules/plugins/PluginReplacement.h:
(WebCore::PluginReplacement::supportsURL): New predicate so we can restrict
use of a plugin to a particular category of URLs.
* Modules/plugins/QuickTimePluginReplacement.mm:
(WebCore::QuickTimePluginReplacement): Updated for new registrar signature.
* Modules/plugins/YouTubePluginReplacement.h: Added.
(WebCore::YouTubePluginReplacement::parentElement):
* Modules/plugins/YouTubePluginReplacement.cpp: Added.
(WebCore::YouTubePluginReplacement::registerPluginReplacement):
(WebCore::YouTubePluginReplacement::create):
(WebCore::YouTubePluginReplacement::supportsMimeType):
(WebCore::YouTubePluginReplacement::supportsFileExtension):
(WebCore::kit):
(WebCore::YouTubePluginReplacement::YouTubePluginReplacement):
(WebCore::YouTubePluginReplacement::createElementRenderer):
(WebCore::objectForKey):
(WebCore::YouTubePluginReplacement::installReplacement):
(WebCore::createYouTubeURL):
(WebCore::processAndCreateYouTubeURL):
(WebCore::YouTubePluginReplacement::youTubeURL):
* WebCore.exp.in: Add new export from WebCore.
* WebCore.xcodeproj/project.pbxproj:
* html/HTMLPlugInElement.cpp:
(WebCore::pluginReplacementForType): Update to also check that the URL is supported
by the plugin.
(WebCore::registeredPluginReplacements): Add new YouTubePluginReplacement to registry.
* html/HTMLPlugInImageElement.cpp:
(WebCore::HTMLPlugInImageElement::createElementRenderer): Remove custom YouTube code
now that this logic is handled in the plugin replacement class.
(WebCore::HTMLPlugInImageElement::createShadowIFrameSubtree): Deleted.
* html/HTMLPlugInImageElement.h:
* html/shadow/YouTubeEmbedShadowElement.cpp:
(WebCore::YouTubeEmbedShadowElement::YouTubeEmbedShadowElement):
(WebCore::YouTubeEmbedShadowElement::shadowPseudoId): Use correct pseudoID for the
plugin replacement architecture.
* html/shadow/YouTubeEmbedShadowElement.h:
* platform/mac/WebCoreNSURLExtras.h:
* platform/mac/WebCoreNSURLExtras.mm:
(WebCore::unescapedQueryValue): Moved from WebKit/Misc/WebNSURLExtras.
(WebCore::queryKeysAndValues): Ditto.

Source/WebKit/mac: 
* Misc/WebNSURLExtras.h:
* Misc/WebNSURLExtras.mm: Remove code that has been converted to C++
and added to YouTubePluginReplacement.cpp.
(-[NSURL _webkit_youTubeURL]):
(-[NSString _webkit_queryKeysAndValues]):
(createYouTubeURL): Deleted.
(-[NSString _webkit_unescapedQueryValue]): Deleted.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168442 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION(r166678): Dromaeo/cssquery-dojo.html crashes regularly.
<https://webkit.org/b/131356>

Reviewed by Geoffrey Garen.

The issue is that GC needs to be made aware of writes to m_inferredValue
in the VariableWatchpointSet, but was not.  As a result, if a JSCell*
is written to a VariableWatchpointSet m_inferredValue, and that JSCell
does not survive an eden GC shortly after, we will end up with a stale
JSCell pointer left in the m_inferredValue.

This issue can be detected more easily by running Dromaeo/cssquery-dojo.html
using DumpRenderTree with the VM heap in zombie mode.

The fix is to change VariableWatchpointSet m_inferredValue to type
WriteBarrier<Unknown> and ensure that VariableWatchpointSet::notifyWrite()
is executed by all the execution engines so that the WriteBarrier semantics
are honored.

We still check if the value to be written is the same as the one in the
inferredValue.  We'll by-pass calling the slow path notifyWrite() if the
values are the same.        

* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
- need to pass the symbolTable to prepareToWatch() because it will be needed
  for instantiating the VariableWatchpointSet in prepareToWatch().

* bytecode/VariableWatchpointSet.h:
(JSC::VariableWatchpointSet::VariableWatchpointSet):
- VariableWatchpointSet now tracks its owner symbol table for its m_inferredValue
  write barrier, and yes, m_inferredValue is now of type WriteBarrier<Unknown>.
(JSC::VariableWatchpointSet::inferredValue):
(JSC::VariableWatchpointSet::invalidate):
(JSC::VariableWatchpointSet::finalizeUnconditionally):
(JSC::VariableWatchpointSet::addressOfInferredValue):
(JSC::VariableWatchpointSet::notifyWrite): Deleted.
* bytecode/VariableWatchpointSetInlines.h: Added.
(JSC::VariableWatchpointSet::notifyWrite):

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::cellConstant):
- Added an assert in case we try to make constants of zombified JSCells again.

* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- We now let the slow path handle the cases when the VariableWatchpointSet is
  in state ClearWatchpoint and IsWatched, and the slow path will ensure that
  we handle the needed write barrier semantics correctly.
  We will by-pass the slow path if the value being written is the same as the
  inferred value.

* ftl/FTLIntrinsicRepository.h:
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
- Let the slow path handle the cases when the VariableWatchpointSet is
  in state ClearWatchpoint and IsWatched.
  We will by-pass the slow path if the value being written is the same as the
  inferred value.

* heap/Heap.cpp:
(JSC::Zombify::operator()):
- Use a different value for the zombified bits (to distinguish it from 0xbbadbeef
  which is used everywhere else).
* heap/Heap.h:
(JSC::Heap::isZombified):
- Provide a convenience test function to check if JSCells are zombified.  This is
  currently only used in an assertion in the DFG bytecode parser, but the intent
  it that we'll apply this test in other strategic places later to help with early
  detection of usage of GC'ed objects when we run in zombie mode.

* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_captured_mov):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitNotifyWrite):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitNotifyWrite):
(JSC::JIT::emitSlow_op_put_to_scope):
- Let the slow path for notifyWrite handle the cases when the VariableWatchpointSet
  is in state ClearWatchpoint and IsWatched.
  We will by-pass the slow path if the value being written is the same as the
  inferred value.
        
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
- Let the slow path for notifyWrite handle the cases when the VariableWatchpointSet
  is in state ClearWatchpoint and IsWatched.
  We will by-pass the slow path if the value being written is the same as the
  inferred value.
        
* runtime/CommonSlowPaths.cpp:

* runtime/JSCJSValue.h: Fixed some typos in the comments.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addGlobalVar):
(JSC::JSGlobalObject::addFunction):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTablePut):
(JSC::symbolTablePutWithAttributes):
* runtime/SymbolTable.cpp:
(JSC::SymbolTableEntry::prepareToWatch):
(JSC::SymbolTableEntry::notifyWriteSlow):
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::notifyWrite):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168443 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS WK2] Speculative fix for crash in PlatformCALayerRemote::recursiveBuildTransaction
https://bugs.webkit.org/show_bug.cgi?id=132666

Reviewed by Tim Horton.

Crash reports suggest that owner() can be null. Assert and protect
against this.

* WebProcess/WebPage/mac/PlatformCALayerRemote.cpp:
(WebKit::PlatformCALayerRemote::recursiveBuildTransaction):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168445 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WK2: Programatic scroll requests during scroll or zoom animation to reveal focused element are ignored.
https://bugs.webkit.org/show_bug.cgi?id=132657
<rdar://problem/16468462>

Reviewed by Benjamin Poulain.

With the scrolling model we use on iOS, a programatic scroll
request can be received while we are still animating to reveal

Source/WebCore: 
the focused input element. The WebProcess is unaware that the
scroll position is being changed in the UIProcess, and does not
honor the scroll request from JavaScript.
This is patch changes the behavior for clients using scroll delegates
to always send the scroll request to the UIProcess without checking
the current scroll position.

* page/FrameView.h:
* platform/ScrollView.cpp:
(WebCore::ScrollView::setScrollPosition):
* platform/ScrollView.h:
(WebCore::ScrollView::inProgrammaticScroll):

Source/WebKit2: 
the focused input element. Changing the scroll offset while animating
leads to unpredictable results. We now cancel the animation if
a programatic scroll request is received.

* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _scrollToContentOffset:WebCore::]):
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::getAssistedNodeInformation):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168447 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use after free in WebCore::RenderObject::nextSibling / WebCore::RenderBoxModelObject::moveChildrenTo
https://bugs.webkit.org/show_bug.cgi?id=132625

Reviewed by David Hyatt.

Source/WebCore:
Fixed problem with dynamically inserting first letter elements.

Test: fast/multicol/newmulticol/first-letter-create.html

* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::getFirstLetter):
(WebCore::RenderBlock::updateFirstLetter):
* rendering/RenderBlock.h:
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::moveChildrenTo):

LayoutTests:
Added test for special case which might cause use after free.

* fast/multicol/newmulticol/first-letter-create-expected.html: Added.
* fast/multicol/newmulticol/first-letter-create.html: Added.


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