HTML parser should not associate elements inside templates with forms
https://bugs.webkit.org/show_bug.cgi?id=117779

Reviewed by Antti Koivisto.

Source/WebCore:

Merge https://chromium.googlesource.com/chromium/blink/+/45aadf7ee7ee010327eb692066cf013315ef3ed7

When parsing <form><template><input>, the previous behavior was to associate the <input> with the <form>,
even though they're not in the same tree (or even the same document).

This patch changes that by checking, prior to creating a form control element, whether the element to be
created lives in a document with a browsing context.

We don't update m_form as needed to faithfully match the HTML5 specification's form element pointer
http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#form-element-pointer
and its algorithm for creating and inserting nodes:
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#creating-and-inserting-nodes

While this leaves isindex's reference to form element pointer stale:
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#isindex
The HTML5 specification matches the behaviors of Chrome and Firefox so we leave it as is.

Test: fast/dom/HTMLTemplateElement/no-form-association.html

* html/parser/HTMLConstructionSite.cpp:
(WebCore::HTMLConstructionSite::createHTMLElement):

LayoutTests:

* fast/dom/HTMLTemplateElement/no-form-association-expected.txt: Added.
* fast/dom/HTMLTemplateElement/no-form-association.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159618 268f45cc-cd09-0410-ab3c-d52691b4dbfc
nextBoundary and previousBoundary are very slow when there is a password field
https://bugs.webkit.org/show_bug.cgi?id=123973

Reviewed by Antti Koivisto.

Source/WebCore:

Merge https://chromium.googlesource.com/chromium/blink/+/57366eec5e3edea54062d4e74c0e047f8681dbad

When iterating through DOM nodes nextBoundary and previousBoundary convert the contents of nodes using
text security to a sequence of 'x' characters. The SimplifiedBackwardsTextIterator and TextIterator
may iterate past node boundaries. Before this patch, the transformation was done looking at the starting
node rather than the current node. In some situations, this replaced all boundaries with 'x' and caused
the text iterator to continue iterating and transforming until the extent of the document.

Test: editing/deleting/password-delete-performance.html

* editing/TextIterator.h:
(WebCore::SimplifiedBackwardsTextIterator::node):
* editing/VisibleUnits.cpp:
(WebCore::previousBoundary):
(WebCore::nextBoundary):

LayoutTests:

* editing/deleting/password-delete-performance-expected.txt: Added.
* editing/deleting/password-delete-performance.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix Range.insertNode when the inserted node is in the same container as the Range
https://bugs.webkit.org/show_bug.cgi?id=123957

Reviewed by Antti Koivisto.

Source/WebCore:

Inspired by https://chromium.googlesource.com/chromium/blink/+/fb6ca1f488703e8d4f20ce6449cc8ea210be6edb

When a node from the same container is inserted, we can't simply adjust m_end with the offset.
Compute m_start and m_end from the inserted nodes instead.

Also, don't adjust m_start and m_end to nodes outside of the document if the inserted nodes had been
removed by mutation events.

Test: fast/dom/Range/range-insertNode-same-container.html

* dom/Range.cpp:
(WebCore::Range::insertNode):

LayoutTests:

Merge https://chromium.googlesource.com/chromium/blink/+/fb6ca1f488703e8d4f20ce6449cc8ea210be6edb

Used better labels between divs, and added more evalAndLog and shouldBe so that
the expected result is self-explanatory.

* fast/dom/Range/range-insertNode-same-container-expected.txt: Added.
* fast/dom/Range/range-insertNode-same-container.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159620 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed EFL gardening.

Update baselines after r159575.

* platform/efl/fast/block/float/024-expected.txt:
* platform/efl/fast/block/margin-collapse/025-expected.txt:
* platform/efl/fast/block/margin-collapse/block-inside-inline/025-expected.txt:
* platform/efl/fast/block/margin-collapse/empty-clear-blocks-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159621 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Fix accessibility media-element expectation
https://bugs.webkit.org/show_bug.cgi?id=124711

Unreviewed EFL gardening.

Changing main element AXRole AXUnknown -> AXEmbedded.

Patch by Andrzej Badowski <a.badowski@samsung.com> on 2013-11-21

* platform/efl/accessibility/media-element-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159622 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Release compilation fails when defining "LOG_DISABLED=0"
https://bugs.webkit.org/show_bug.cgi?id=124661

Patch by Andres Gomez <agomez@igalia.com> on 2013-11-21
Reviewed by Mario Sanchez Prada.

In a "Debug" build the CString.h header comes from another
indirect dependency. Now, we explicitly add this missing include.

* html/HTMLTrackElement.cpp: Explicitly adding missing include.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159623 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Added test for visual overflow with transformed content in regions.

[CSS Regions] Transform applied to content node causes overflow to be hidden
https://bugs.webkit.org/show_bug.cgi?id=116242

Reviewed by Antti Koivisto.

* fast/regions/region-visual-overflow-transform-expected.html: Added.
* fast/regions/region-visual-overflow-transform.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159624 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Created test for positioned fragmented content which overflows the regions.

[CSS Regions] Fragmented content that is relatively positioned get sliced (and overflows in the next region)
https://bugs.webkit.org/show_bug.cgi?id=117122

Reviewed by Antti Koivisto.

* fast/regions/positioned-fragmented-content-expected.html: Added.
* fast/regions/positioned-fragmented-content.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159625 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix hover area for divs with css transforms
https://bugs.webkit.org/show_bug.cgi?id=124647

Patch by Mihai Maerean <mmaerean@adobe.com> on 2013-11-21
Reviewed by Allan Sandfeld Jensen.

Source/WebCore:

Non transformed layers are now being hit last, not through or in-between transformed layers.
The paint order says that the divs creating stacking contexts (including transforms) are painted after the
other siblings so they should be hit tested in the reverse order. Also, a rotated div in a non-rotated parent
should be hit in its entire area, not hit its parent's background, even if the z-coordinate is negative where
the mouse is located.

Test: transforms/3d/hit-testing/hover-rotated-negative-z.html

* rendering/RenderLayer.cpp:
(WebCore::computeZOffset):

LayoutTests:

* transforms/3d/hit-testing/hover-rotated-negative-z.html: Added.
* transforms/3d/hit-testing/hover-rotated-negative-z-expected.txt: Added.

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