Bug 50352 – [Chromium] New test fast/dom/vertical-scrollbar-in-rtl fater 73063

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Victor Wang]

Test added by patch http://trac.webkit.org/changeset/73063. Maybe need scrollbar related change in chromium side?
fast/dom/vertical-scrollbar-in-rtl.html

[Ojan Vafai]

I'm not sure I understand what this test is doing. 

Here's the diff for chromium-linux:
@@ -4,6 +4,6 @@
 zoom in and out preserve scroll position: Success
 resize preserves scroll position: Success
 wheel scroll preserves vertical scroll position: Success
-KeyDown HOME move y-scroll position to bottom for RTL page: 0
+KeyDown HOME move y-scroll position to bottom for RTL page: -3425
 KeyDown END move y-scroll position to bottom for RTL page: 0
 selectAll selects all document: Success

I see the following comment in the test above the failing line:
          // Not using assert equal here since the behavior is different in each port. 
          // For example, in Mac, HOME/END key reset both x and y scroll position. 
          // In Chromium, HOME/END key only reset y scroll position, and x scroll position is preserved.

1. This describes the correct Chromium linux/win behavior, it's a bug that Chromium-mac does not do the Mac behavior with home/end.
2. Not sure what causes us to get the wrong value on linux. Maybe something RTL related?

[Xiaomei Ji]

Following is from dhyatt. So, we will just rebaseline it for now.

dhyatt: xji: technically home/end are complicated, since in a vertical document they should be moving the x value and not the y value

xji: dhyatt: is the y-value expected in http://build.webkit.org/results/Chromium%20Win%20Release%20(Tests)/r73063%20(5875)/fast/dom/vertical-scrollbar-in-rtl-diff.txt ?
[4:45pm] dhyatt: xji: technically it's wrong, but just check in bad results for now
[4:45pm] dhyatt: xji: we have to teach home/end that they're moving the x-axis in vertical text documents and not the y
[4:45pm] dhyatt: there's a separate bug about that though
[4:45pm] dhyatt: so just check in the bad results
[4:46pm] xji: dhyatt: got it.
[4:46pm] dhyatt: mac just gets lucky since it resets the opposite axis position
[4:46pm] dhyatt: but really it's not doing it right either

[Xiaomei Ji]

Committed r73186: <http://trac.webkit.org/changeset/73186>

[Xiaomei Ji]

HOME/END result is not consistent across different run.
we probably should disable the HOME/END test for now.

[Martin Robinson]

Committed r73328: <http://trac.webkit.org/changeset/73328>

[Xiaomei Ji]

horizontal-scrollbar-in-rtl result is correct for GTK.

HOME/END for vertical writing mode is not implemented, so, the result might be flaky.

But many other results in vertical-scrollbar-in-rtl in GTK are not correct either. Is vertical writing mode completely implemented in GTK?

[Martin Robinson]

(In reply to comment #6)
> horizontal-scrollbar-in-rtl result is correct for GTK.
> HOME/END for vertical writing mode is not implemented, so, the result might be flaky.
> But many other results in vertical-scrollbar-in-rtl in GTK are not correct either. Is vertical writing mode completely implemented in GTK?

As far as I know characters rendered in vertical writing mode have the incorrect orientation, so I believe this feature is not implemented currently