paragraphs with different directionality in textarea with unicode-bidi: plaintext are aligned the same
https://bugs.webkit.org/show_bug.cgi?id=71194

Reviewed by David Hyatt.

Merged from Blink r157263 by <igor.o@sisa.samsung.com>
<https://src.chromium.org/viewvc/blink?revision=157263&view=revision>

Source/WebCore:

In the css3-text spec (http://www.w3.org/TR/css3-text/#bidi-linebox):

The start and end edges of a line box are determined by the inline
base direction of the line box. In most cases, this is given by
its containing block's computed ‘direction’. However if its
containing block has ‘unicode-bidi: plaintext’, the inline base
direction the line box must be determined by the base direction of
the bidi paragraph to which it belongs: that is, the bidi
paragraph for which the line box holds content.

This patch just implements the behavior described above modifying
updateLogicalWidthForAlignment and setting the bidi level of the
RootInlineBox.

* rendering/RenderBlockFlow.h:
* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlockFlow::updateLogicalWidthForAlignment):
(WebCore::RenderBlockFlow::computeInlineDirectionPositionsForSegment):
(WebCore::RenderBlockFlow::createLineBoxesFromBidiRuns):
(WebCore::RenderBlockFlow::layoutRunsAndFloatsInRange):
(WebCore::RenderBlockFlow::deleteEllipsisLineBoxes):
(WebCore::RenderBlockFlow::checkLinesForTextOverflow):
(WebCore::RenderBlockFlow::startAlignedOffsetForLine):

LayoutTests:

Modified expectations for two layout tests to make them conforming to the spec.

* fast/text/international/unicode-bidi-plaintext-expected.html:
* platform/gtk/fast/text/international/unicode-bidi-plaintext-in-textarea-expected.txt:
* platform/mac-mountainlion/fast/text/international/unicode-bidi-plaintext-in-textarea-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164867 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Shapes] Update line segments for ShapeInside only if the new line is wide enough
https://bugs.webkit.org/show_bug.cgi?id=129461

Reviewed by David Hyatt.

Shape-inside can make a line only narrower than the original line width, thus we don't need
to update the line/shape segments in fitBelowFloats for every single line inside shape-inside.
This patch adds a helper function, which updates the line segments, furthermore it updates the
line segments only when the content would fit without the shape.

No new tests, no behavior change.

* rendering/line/BreakingContextInlineHeaders.h: Use new helper.
(WebCore::updateSegmentsForShapes):
* rendering/line/LineWidth.cpp: Use new helper.
(WebCore::LineWidth::updateLineSegment): Add new helper.
(WebCore::LineWidth::fitBelowFloats):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164868 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Grid Layout] Fix positioning grid items using named grid lines/areas
https://bugs.webkit.org/show_bug.cgi?id=129372

Reviewed by Darin Adler.

Source/WebCore:

Our code was assuming that a <custom-ident> in
-webkit-grid-{column|row}-{start|end} and
-webkit-grid-{column|row} was always a grid area name. That's
wrong because the <custom-ident> could be also a explicitly named
grid line or the an implicitly named grid line created by a grid
area definition.

The style resolution code was not correct either. This patch fixes
it so it now matches the spec, which means that:
- first we try to match any existing grid area.
- then if there is a named grid line with the name
<custom-ident>-{start|end} for -webkit-grid-{column|row}-{start|end}
defined before the grid area then we use it instead of the grid
area.
- otherwise if there is a named grid line we resolve to the first such line.
- otherwise we treat it as 'auto'.

Fixing this uncovered a bug in GridPosition, we were not using the
name of the stored grid area to check if two GridPositions were
the same.

Tests: fast/css-grid-layout/grid-item-position-changed-dynamic.html
       fast/css-grid-layout/named-grid-lines-with-named-grid-areas-resolution.html

* css/StyleResolver.cpp:
(WebCore::gridLineDefinedBeforeGridArea): New function to check if
a given named grid line was defined before an implicit named grid
line created by a grid area definition.
(WebCore::StyleResolver::adjustNamedGridItemPosition): New
function that adjusts the position of a GridPosition parsed as a
grid area.
(WebCore::StyleResolver::adjustGridItemPosition): Use the new
function adjustNamedGridItemPosition to adjust the positions of
named grid lines.
* css/StyleResolver.h:
* rendering/RenderGrid.cpp:
(WebCore::RenderGrid::resolveNamedGridLinePositionFromStyle): Use GridPosition:: namespace.
(WebCore::RenderGrid::resolveGridPositionFromStyle): Ditto.
(WebCore::RenderGrid::resolveRowEndColumnEndNamedGridLinePositionAgainstOppositePosition): Ditto.
* rendering/RenderGrid.h:
* rendering/style/GridPosition.h:
(WebCore::GridPosition::adjustGridPositionForRowEndColumnEndSide): Moved from RenderGrid.cpp.
(WebCore::GridPosition::adjustGridPositionForSide): Ditto.
(WebCore::GridPosition::operator==): Use the named grid line to check equality.

LayoutTests:

Added a new test that checks that we correctly position grid items
using named grid lines, grid areas and also with the implicit
named grid lines created by grid areas.

I'm also importing a test from Blink that checks that we can
dynamically change the position of a grid item by changing the
name of the grid lines used to position it.

* fast/css-grid-layout/grid-item-position-changed-dynamic-expected.txt:
Merged from Blink r153913 by <jchaffraix@chromium.org>.
* fast/css-grid-layout/grid-item-position-changed-dynamic.html: Ditto.
* fast/css-grid-layout/named-grid-lines-with-named-grid-areas-resolution-expected.txt: Added.
* fast/css-grid-layout/named-grid-lines-with-named-grid-areas-resolution.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164869 268f45cc-cd09-0410-ab3c-d52691b4dbfc
MouseEvent.offsetX/Y should just return 0,0 for simulated clicks.
<https://webkit.org/b/129477>

Source/WebCore:

There's no need to compute the exact target-relative coordinates for
simulated mouse events, e.g those fired by HTMLElement.click().

The offsetX/Y properties are not supported by Firefox.

Test: fast/events/relative-offset-of-simulated-click.html

Reviewed by Alexey Proskuryakov.

* dom/MouseRelatedEvent.cpp:
(WebCore::MouseRelatedEvent::offsetX):
(WebCore::MouseRelatedEvent::offsetY):

LayoutTests:

Add a test documenting the behavior of offsetX/Y on the simulated
mouse events that get sent by HTMLElement.click().

Reviewed by Alexey Proskuryakov.

* fast/events/relative-offset-of-simulated-click-expected.txt: Added.
* fast/events/relative-offset-of-simulated-click.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164871 268f45cc-cd09-0410-ab3c-d52691b4dbfc
paragraphs with different directionality in textarea with unicode-bidi: plaintext are aligned the same
https://bugs.webkit.org/show_bug.cgi?id=71194

* platform/mac/fast/text/international/unicode-bidi-plaintext-in-textarea-expected.txt:
Updated Mac results for Mavericks (the original patch only updated Mountain Lion results).



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164872 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Mac] Disambiguate calls to [[window contentView] layer] and [... setLayer:]
https://bugs.webkit.org/show_bug.cgi?id=129491

Reviewed by Alexey Proskuryakov.

-[NSWindow contentView] returns a bare id, leading to ambiguity when calling
certain methods, including -layer and -setLayer:. Resolve the ambiguity by
explicitly casting the -contentView call to a NSView*.

* platform/mac/WebVideoFullscreenController.mm:
(-[WebVideoFullscreenController setupVideoOverlay:]):
(-[WebVideoFullscreenController windowDidLoad]):
(-[WebVideoFullscreenController windowDidExitFullscreen]):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164873 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Properly clear m_logicallyLastRun to remove use-after-free possibility
https://bugs.webkit.org/show_bug.cgi?id=129489

Reviewed by David Hyatt.

A use-after-free issue was caught in Blink because m_logicallyLastRun
is not cleared when the item it points to is deleted. Clearing it
turns the use-after-free into a segfault, and prevents any future
use-after-frees from happening.

* platform/text/BidiRunList.h:
(WebCore::BidiRunList<Run>::deleteRuns):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164876 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit2: VisitedLinkProvider should keep track of processes, not pages
https://bugs.webkit.org/show_bug.cgi?id=129497

Reviewed by Dan Bernstein.

Use a counted set of WebProcessProxy pointers instead of a set of pages.

* UIProcess/VisitedLinkProvider.cpp:
(WebKit::VisitedLinkProvider::~VisitedLinkProvider):
Assert that m_processes is null.

(WebKit::VisitedLinkProvider::addProcess):
Add the process to the set.

(WebKit::VisitedLinkProvider::removeProcess):
Remove the process from the set.

* UIProcess/VisitedLinkProvider.h:

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::WebPageProxy):
If our process is currently running, add it to the visited link provider.
Otherwise it will be added in connectionWillOpen.

(WebKit::WebPageProxy::close):
If our process is running, remove it from the visited link provider.
Otherwise it's either crashed or not yet launched and will not have been added.

(WebKit::WebPageProxy::connectionWillOpen):
Add the process to the visited link provider.

(WebKit::WebPageProxy::resetStateAfterProcessExited):
Remove the process from the visited link provider.

Tools: Remove logging.

Reviewed by Dan Bernstein.

* MiniBrowser/mac/WK2BrowserWindowController.m:
(-[WK2BrowserWindowController browsingContextController:decidePolicyForNavigationAction:decisionHandler:]):

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