REGRESSION (r172826): Password field placeholder text is missing if
placeholder attribute precedes type attribute

<https://bugs.webkit.org/show_bug.cgi?id=138682>
<rdar://problem/18574213>

Source/WebCore:

When the placeholder attribute is encountered, a shadow tree is created
to include the placeholder element. When the type attribute is
encountered, the previous shadow tree is destroyed, and a new shadow
tree is created. TextFieldInputType::createShadowSubtree() did not
handle creating the placeholder element.

This regressed in r172826 because prior to r172826, the placeholder
element would be recreated when
HTMLTextFormControlElement::updatePlaceholderVisibility() was called.
In r172826, updatePlaceholderVisibility() was changed to only show or
hide the placeholder element if it exists.

Reviewed by Benjamin Poulain.

* html/TextFieldInputType.cpp:
(WebCore::TextFieldInputType::createShadowSubtree):
Call updatePlaceholderVisibility() to insert the placeholder element
(after the inner text element has been inserted, as it appears before
it in the shadow DOM).

LayoutTests:

Reviewed by Benjamin Poulain.

* fast/forms/placeholder-attribute-ordering-expected.html: Added.
* fast/forms/placeholder-attribute-ordering.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176082 268f45cc-cd09-0410-ab3c-d52691b4dbfc
ARMv7(s) Assembler: LDRH with immediate offset is loading from the wrong offset
https://bugs.webkit.org/show_bug.cgi?id=136914

Reviewed by Michael Saboff.

TLDR: the immediate offset of half-word load was divided by 2.

Story time: So I started getting those weird reports of :nth-child() behaving bizarrely
on ARMv7 and ARMv7s. To make things worse, the behavior changes depending on style updates.

I started looking the disassembly on the tests cases...

The first thing I noticed was that the computation of An+B looked wrong. For example,
in the case of n+6, the instruction should have been:
    subs r1, r1, #6
but was
    subs r1, r1, #2

After spending a lot of time trying to find the error in the assembler, I discovered
the problem was not real, but just a bug in the disassembler.
This is the first fix: ARMv7DOpcodeAddSubtractImmediate3's immediate3() was truncating
the value to 2 bits instead of 3 bits.

The disassembler being fixed, I still have no lead on the weird bug. Some disassembly later,
I realize the LDRH instruction is not decoded at all. The reason is that both LDRH and STRH
were under the umbrella ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord but the pattern
only matched SRTH.

I fix that next, ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord is split into
ARMv7DOpcodeStoreRegisterImmediateHalfWord and ARMv7DOpcodeLoadRegisterImmediateHalfWord,
each with their own pattern and their instruction group.

Now that I can see the LDRHs correctly, there is something fishy about them, their offset
is way too small for the data I load.

This time, looking at the binary, the generated code is indeed incorrect. It turns out that
the ARMv7 assembler shifted the offset of half-word load as if they were byte load: divided by 4.
As a result, all the load of half-words with more than zero offset were loading
values with a smaller offset than what they should have.

That being fixed, I dump the assembly: still wrong. I am ready to throw my keyboard through
my screen at that point.

Looking at the disassembler, there is yet again a bug. The computation of the scale() adjustment
of the offset was incorrect for anything but word loads.
I replaced it by a switch-case to make it explicit.

STRH is likely incorrect too. I'll fix that in a follow up, I want to survey all the 16 bits cases
that are not directly used by the CSS JIT.

* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::ldrh):
Fix the immediate scaling. Add an assertion to make sure the alignment of the input is correct.

* disassembler/ARMv7/ARMv7DOpcode.cpp:
(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale):
Fix the scaling code. Just hardcode instruction-to-scale table.

* disassembler/ARMv7/ARMv7DOpcode.h:
(JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::immediate3):
The mask for a 3 bits immediate is not 3 :)

(JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale): Deleted.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176083 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Implement the matching for :nth-last-child(An+B of selector-list)
https://bugs.webkit.org/show_bug.cgi?id=138650

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-11-13
Reviewed by Andreas Kling.

Source/WebCore:

Matching is trivial based on the existing CSS4 infrastructure.

The tricky part is style invalidation. In the cases of the old :nth-last-child()
and :nth-last-of-type(), we were using the flag ChildrenAffectedByBackwardPositionalRules.

The problem with ChildrenAffectedByBackwardPositionalRules is that it only invalidate
subtrees when nodes are being added or removed. It is a valuable optimization by itself
since tree updates are less common than property updates.

For the case of property updates, I have added the new flag "ChildrenAffectedByPropertyBasedBackwardPositionalRules".
It pretty much work the same way but invalidates subtree on style recalc.

Tests: fast/css/nth-child-and-nth-last-child.html
       fast/css/nth-last-child-of-classname.html
       fast/css/nth-last-child-of-complex-selector.html
       fast/css/nth-last-child-of-compound-selector.html
       fast/css/nth-last-child-of-style-sharing-1.html
       fast/css/nth-last-child-of-style-sharing-2.html
       fast/css/nth-last-child-of-style-update-optimization.html
       fast/css/nth-last-child-of-tagname.html
       fast/selectors/nth-last-child-of-class-style-update.html

* css/SelectorChecker.cpp:
(WebCore::SelectorChecker::checkOne):
* dom/Element.cpp:
(WebCore::Element::setChildrenAffectedByPropertyBasedBackwardPositionalRules):
(WebCore::Element::hasFlagsSetDuringStylingOfChildren):
(WebCore::Element::rareDataChildrenAffectedByPropertyBasedBackwardPositionalRules):
* dom/Element.h:
(WebCore::Element::childrenAffectedByPropertyBasedBackwardPositionalRules):
* dom/ElementRareData.h:
(WebCore::ElementRareData::childrenAffectedByPropertyBasedBackwardPositionalRules):
(WebCore::ElementRareData::setChildrenAffectedByPropertyBasedBackwardPositionalRules):
(WebCore::ElementRareData::ElementRareData):
(WebCore::ElementRareData::resetDynamicRestyleObservations):
* dom/Node.cpp:
(WebCore::Node::updateAncestorsForStyleRecalc):
(WebCore::Node::setNeedsStyleRecalc):
(WebCore::markAncestorsWithChildNeedsStyleRecalc): Deleted.
* dom/Node.h:
Unlike the other marking steps, ChildrenAffectedByPropertyBasedBackwardPositionalRules can only really
affect one level (because we don't have a parent-selectors). It is quite easy to mark large
trees with ChildrenAffectedByPropertyBasedBackwardPositionalRules by using a selector list that is a bit
too generic. When that happen, we must be careful not invalidating everything, just the affected subtree.

LayoutTests:

* fast/selectors/nth-last-child-of-class-style-update-expected.txt: Added.
* fast/selectors/nth-last-child-of-class-style-update.html: Added.
Verify simple cases of style update.

* fast/css/nth-last-child-of-style-update-optimization-expected.txt: Added.
* fast/css/nth-last-child-of-style-update-optimization.html: Added.
Verify that style invalidation stays reasonable.

* fast/css/nth-last-child-of-style-sharing-1-expected.html: Added.
* fast/css/nth-last-child-of-style-sharing-1.html: Added.
* fast/css/nth-last-child-of-style-sharing-2-expected.html: Added.
* fast/css/nth-last-child-of-style-sharing-2.html: Added.
Check that style sharing is disabled for elements matching :nth-last-child().

* fast/css/nth-child-and-nth-last-child-expected.html: Added.
* fast/css/nth-child-and-nth-last-child.html: Added.
Test uniqueness testing by combining :nth-child() and :nth-last-child().

* fast/css/nth-last-child-of-classname-expected.html: Added.
* fast/css/nth-last-child-of-classname.html: Added.
* fast/css/nth-last-child-of-complex-selector-expected.html: Added.
* fast/css/nth-last-child-of-complex-selector.html: Added.
* fast/css/nth-last-child-of-compound-selector-expected.html: Added.
* fast/css/nth-last-child-of-compound-selector.html: Added.
* fast/css/nth-last-child-of-tagname-expected.html: Added.
* fast/css/nth-last-child-of-tagname.html: Added.
Test matching, those are the "last-child" counterpart of the existing
"nth-child-of" tests.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176084 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove Source/Platform cruft
https://bugs.webkit.org/show_bug.cgi?id=138658

Reviewed by Anders Carlsson.

* CMakeLists.txt:
* Source/Platform: Removed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176085 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Adjust the WKBundlePageOverlay Data Detectors SPI
https://bugs.webkit.org/show_bug.cgi?id=138685
<rdar://problem/18947156>

Reviewed by Anders Carlsson.

* UIProcess/mac/WKActionMenuController.mm:
(-[WKActionMenuController _defaultMenuItemsForDataDetectedText]):
Forward DDActionContext callbacks to the Web process.

* WebProcess/InjectedBundle/API/c/WKBundlePageOverlay.cpp:
* WebProcess/InjectedBundle/API/c/WKBundlePageOverlay.h:
* WebProcess/WebPage/WebPageOverlay.cpp:
* WebProcess/WebPage/WebPageOverlay.h:
Add four DataDetectors-related WebKit2-only page overlay callbacks:

(WebKit::WebPageOverlay::actionContextForResultAtPoint):
Called during the action menu hit test; clients can reply with a DDActionContext
and a DOM range, and WebKit will treat that result and range as if it had
detected it itself, building the action menu and showing the yellow highlight as usual.

(WebKit::WebPageOverlay::dataDetectorsPresentedUI):
(WebKit::WebPageOverlay::dataDetectorsChangedUI):
(WebKit::WebPageOverlay::dataDetectorsHidUI):
These correspond to the DDActionContext callbacks, and can be used by clients
to show/hide corresponding UI while DataDetectors in the UI process is presenting UI.

(WebKit::WebPageOverlay::prepareForActionMenu): Deleted.
Get rid of prepareForActionMenu, as nobody ever used it.

* WebProcess/WebPage/WebPage.cpp:
Add WebPageOverlay.h so that we can build, because the destructor lives here.

* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/WebPage.messages.in:

* WebProcess/WebPage/mac/WebPageMac.mm:
(WebKit::WebPage::performActionMenuHitTestAtLocation):
Give all of the WebPageOverlays the first shot at data detection; if none of them
reply with a valid DDActionContext/DOM range, we'll go ahead and do our normal detection.

(WebKit::WebPage::dataDetectorsPresentedUI):
(WebKit::WebPage::dataDetectorsChangedUI):
(WebKit::WebPage::dataDetectorsHidUI):
Forward these along to the active WebPageOverlay.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176086 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Update WebKit to build with LLVM TOT
https://bugs.webkit.org/show_bug.cgi?id=138519

Patch by Juergen Ributzka <juergen@apple.com> on 2014-11-13
Reviewed by Geoffrey Garen.

* Configurations/LLVMForJSC.xcconfig:
* llvm/LLVMAPIFunctions.h:
* llvm/library/LLVMExports.cpp:
(initializeAndGetJSCLLVMAPI):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176087 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Update the "combineModules" script to handel more LLVM metadata.
https://bugs.webkit.org/show_bug.cgi?id=138514

Patch by Juergen Ributzka <juergen@apple.com> on 2014-11-13
Reviewed by Filip Pizlo.

* ReducedFTL/combineModules.rb:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176088 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rename ios-sim to ios-sim-deprecated.

The results here are historical and new results should go into ios-simulator
directory. Eventually, we should get rid of this directory completely.

Rubber-stamped by Simon Fraser.

* platform/ios-sim: Removed.
* platform/ios-sim-deprecated: Copied from LayoutTests/platform/ios-sim.



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