Fix ShapeResult::selectionRect handles RTL runs in wrong order

Fix ShapeResult::selectionRect handles RTL runs in wrong order

In ShapeResult::selectionRect, the Vector of ShapeResult is in logical
order, while RunInfo in ShapeResult is in visual order.

This patch fixes logical offsets to visual offsets when comparing to
RunInfo.

Also fixes to use HB_DIRECTION_IS_BACKWARD() when testing
hb_direction_t is RTL, which improves the test in vertical flow.

BUG=539108
Committed: https://crrev.com/79e5c356b8571b04a90bbfddfc8be0965e1af416
Cr-Commit-Position: refs/heads/master@{#357319}

[kojii, 2015-10-31 17:41:17]

Description was changed from

==========
selection-rect-rtl

BUG=
==========

to

==========
selection-rect-rtl

BUG=539108
==========

[kojii, 2015-11-01 07:37:50]

Description was changed from

==========
selection-rect-rtl

BUG=539108
==========

to

==========
Fix ShapeResult::selectionRect handles RTL runs in wrong order

In ShapeResult::selectionRect, the Vector of ShapeResult is in logical
order, while RunInfo in ShapeResult is in visual order.

This patch fixes logical offsets to visual offsets when comparing to
RunInfo.

Also fixes to use HB_DIRECTION_IS_BACKWARD() when testing
hb_direction_t is RTL, which improves the test in vertical flow.

BUG=539108
==========

[kojii, 2015-11-01 07:53:03]

kojii@chromium.org changed reviewers:
+ eae@chromium.org

[kojii, 2015-11-01 07:53:04]

PTAL.

I was thinking for a while to simplify |xPositionForVisualOffset()| further
since the given offset is visual now, but did not dive into that in this CL.
WDYT?

[eae, 2015-11-01 07:59:07]

LGTM

Very nice, I was planning to look into it this week after the analysis with
leviw and wkorman on Friday but you beat me to it, thank you!

[eae, 2015-11-01 07:59:12]

The CQ bit was checked by eae@chromium.org

[commit-bot: I haz the power, 2015-11-01 07:59:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1420043007/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1420043007/60001

[commit-bot: I haz the power, 2015-11-01 10:17:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-01 10:17:39]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[kojii, 2015-11-02 01:55:54]

Mac had both real and unrelated failures, thanks to Times causing fallback to
catch a bug. PS6 fixed currentX calculations.

linux_andorid and win_x64 still failing, but these look unrelated.

[wkorman, 2015-11-02 04:29:19]

wkorman@chromium.org changed reviewers:
+ wkorman@chromium.org

[wkorman, 2015-11-02 04:29:20]

lgtm

Nice!

https://codereview.chromium.org/1420043007/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaper.cpp
(right):

https://codereview.chromium.org/1420043007/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaper.cpp:424: //
Convert logical offsets to visual offsets, because results are in
Is visual the same as physical? Which name is preferred?

[kojii, 2015-11-02 05:19:44]

https://codereview.chromium.org/1420043007/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaper.cpp
(right):

https://codereview.chromium.org/1420043007/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaper.cpp:424: //
Convert logical offsets to visual offsets, because results are in
On 2015/11/02 04:29:20, wkorman wrote:
> Is visual the same as physical? Which name is preferred?

IIUC Unicode bidi reordering uses logical/visual while CSS directional
properties use logical/physical. Existing comments in HarfBuzzShaper is
consistent on that.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

[kojii, 2015-11-02 06:33:31]

The CQ bit was checked by kojii@chromium.org

[kojii, 2015-11-02 06:33:32]

The patchset sent to the CQ was uploaded after l-g-t-m from eae@chromium.org
Link to the patchset: https://codereview.chromium.org/1420043007/#ps120001
(title: "Rebaseline 1px diff on Mac")

[commit-bot: I haz the power, 2015-11-02 06:33:51]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1420043007/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1420043007/120001

[commit-bot: I haz the power, 2015-11-02 07:48:15]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2015-11-02 07:49:04]

Patchset 7 (id:??) landed as
https://crrev.com/79e5c356b8571b04a90bbfddfc8be0965e1af416
Cr-Commit-Position: refs/heads/master@{#357319}

[hiroshige, 2015-11-02 10:32:44]

On 2015/11/02 07:49:04, commit-bot: I haz the power wrote:
> Patchset 7 (id:??) landed as
> https://crrev.com/79e5c356b8571b04a90bbfddfc8be0965e1af416
> Cr-Commit-Position: refs/heads/master@{#357319}

fast/text/atsui-rtl-override-selection.html starts failing on Mac10.6 after
chromium 357317:357320, suspecting this CL.
Tracking bug: https://crbug.com/550336