50352 2010-12-01 14:57:13 -0800 [Chromium] New test fast/dom/vertical-scrollbar-in-rtl fater 73063 2010-12-07 00:59:49 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) PC All RESOLVED FIXED P2 Normal --- 1 victorw webkit-unassigned hyatt mrobinson ojan victorw xji oldest_to_newest 315889 0 victorw 2010-12-01 14:57:13 -0800 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 315895 1 ojan 2010-12-01 15:13:00 -0800 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? 315960 2 xji 2010-12-01 17:28:47 -0800 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 316364 3 xji 2010-12-02 12:52:04 -0800 Committed r73186: <http://trac.webkit.org/changeset/73186> 316481 4 xji 2010-12-02 15:56:12 -0800 HOME/END result is not consistent across different run. we probably should disable the HOME/END test for now. 317267 5 mrobinson 2010-12-04 06:23:26 -0800 Committed r73328: <http://trac.webkit.org/changeset/73328> 318065 6 xji 2010-12-06 22:49:47 -0800 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? 318083 7 mrobinson 2010-12-07 00:59:49 -0800 (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