User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160407164938 Steps to reproduce: Create a link to jump in same page. http://www.mongolfont.com/test/firefox/a.html <a href="#chinese">chinese</a> -> <a name="chinese">chinese</a> <a href="#japanese">japanese</a> -> <a name="japanese">japanese</a> <a href="#mongolian">mongolian</a> -> <a name="mongolian">mongolian</a> Actual results: The jumping target not move to left side in vertical-lr and The jumping target not move to right side in vertical-rl. Expected results: The jumping target should move to left side in vertical-lr and The jumping target should move to right side in vertical-rl.

I don't understand your actual results. 1) Clicking on http://www.mongolfont.com/test/firefox/a.html#chinese moves to the L 2) Clicking on http://www.mongolfont.com/test/firefox/a.html#japanese doesn't do anything 3) Clicking on http://www.mongolfont.com/test/firefox/a.html#mongolian moves to the R Can you confirm that? If you confirm it, what is the expected behaviour.

My expected behaviour is like link_jump_in_page.png

like link_jump_in_page2.png

When jumping to an anchor within the page, our normal behavior (in horizontal content) is to scroll so that the target element appears at the *top* of the window. By analogy, then, in vertical-lr mode, we'd expect to scroll so that the target element appears at the *left* side (the block-start edge, or "logical top"); and in vertical-rl mode, it should appear at the *right* side. But what's actually happening is that we're scrolling just far enough to bring the target element into view on the *right* side in vertical-lr mode, or the *left* side in vertical-rl. That's the block-end side in each case, so this is analogous to bringing the target just into view at the *bottom* of the window in horizontal content.

Additional tests ---------------- 1- http://www.gtalbot.org/BugzillaSection/Bug1263810-anchor-link-jump-001.html This is the approximate equivalent of Siqinbilige's http://www.mongolfont.com/test/firefox/a.html except that I - removed unneeded -webkit vendor-prefix, - added doctype declaration, - removed the table element, - set a defined width for the <div> elements ensuring that there must a scrollable area (since scrollWidth must be much greater than clientWidth in those <div>s), - removed text-orientation: sideways-right - added lang attribute - added a text assert to the test Not tested yet is with 'writing-mode: sideways-rl' and with 'writing-mode: sideways-lr' 2- http://www.gtalbot.org/BugzillaSection/Bug1263810-anchor-link-jump-002.html This one is more self-descriptive. To restart or reset that test, you need to manually remove the fragment identifier (eg #target-vrl or #target-vlr) in the address bar. Doing [Ctrl+F5] will not suffice. Not tested yet is with 'writing-mode: sideways-rl' and with 'writing-mode: sideways-lr' - - - - - - - Other possible tests to do: - with the scrollIntoView() function https://drafts.csswg.org/cssom-view/#dom-element-scrollintoview - link and target with a whole document (instead of a single div) in all 4 vertical writing-modes

There is also an unwanted side effect (or another actual result) to intra-page link to an anchor (or link target) in a element with vertical writing-mode. The page is scrolled back to the top. I have modified the Bug1263810-anchor-link-jump-002.html test by adding empty filler <p>s in order to make the page scrollable vertically. Now, if you click the links in Bug1263810-anchor-link-jump-002.html test, you not only get at the wrong position in the element with a vertical writing-mode but you also are scrolled back to the top of the page. I think there should be no scrolling up of the page (expected); there could be scrolling up (or down) of the element if scrollHeight was greater than clientHeight and if the anchor (or link target) was in the scrollHeight area. We can create more specific tests for this.

I just realized now that Siqinbilige's test and my tests all have an orthogonal element who is object of target (anchor) linkage. We need to do tests involving entire pages with vertical writing mode: meaning non-orthogonal design. So, 4 writing-modes, 2 orthogonal contexts (orthogonal and non-orthogonal), 2 elements (link intra-navigation in body element vs link intra-navigation in div element) means 16 tests to cover all basic possibilities.