Jonathan Kew [:jfkthame] Reporter
	Description • 9 years ago

Bug 1113206 will make dropdown lists for <select> controls in vertical writing mode render and behave properly in single-process Firefox.

However, in e10s they will still be broken, because the current e10s implementation of this uses a XUL popup menu in the parent process, and we don't have vertical writing-mode support in XUL elements in general.

	Jonathan Kew [:jfkthame] Reporter
	Comment 1 • 9 years ago

There are two possible approaches we could take to this bug:

(a) Fix the XUL frame classes so that they support vertical writing modes;

(b) Replace the XUL popup used for <select>s in e10s mode (see ContentSelectDropdown in browser.xul) with an HTML implementation, as used in non-e10s.

We don't really want to do (a), because it's not worth adding major new features (such as writing-mode support) to XUL when we're trying to get away from XUL, not continue growing it. So the right way forward is (b), which I think means this is mostly a Toolkit or Firefox front-end bug rather than Layout.

	Mike Conley (:mconley) (:⚙️)
	Comment 2 • 9 years ago

I also think (b) is the right answer, but last I checked, considerable difficulty / pain lay in that direction. needinfo'ing mstange, since he helped us formulate the <xul:menulist> solution, and might know of other reasons why we avoided created an HTML-style select popup in the parent instead.

	Markus Stange [:mstange]
	Comment 3 • 9 years ago

How do other browsers deal with this, especially on OS X where they use native menus? Or are we the first to break new ground here?

Does embedding an html:div with vertical text in a XUL panel work?

	Jonathan Kew [:jfkthame] Reporter
	Comment 4 • 9 years ago

(In reply to Markus Stange [:mstange] from comment #3)
> How do other browsers deal with this, especially on OS X where they use
> native menus? Or are we the first to break new ground here?

AFAIK, we're breaking new ground.

Testcase:
  http://people.mozilla.org/~jkew/tests/vertical-select.html

In Safari 7.1.7, Chrome 46.0.2466.0 and IE 11.0.9600.17905, the <select> elements get rendered horizontally even though they're in a vertical writing-mode context, which just looks silly.

We render the <select> vertically, and without e10s it functions pretty well (though without native theming), but with e10s we get a horizontal popup below the vertical element.

	Jonathan Kew [:jfkthame] Reporter
	Comment 5 • 9 years ago

(In reply to Markus Stange [:mstange] from comment #3)
> Does embedding an html:div with vertical text in a XUL panel work?

It should; there's no reason why not, AFAIK.

	Jonathan Kew [:jfkthame] Reporter
	Comment 6 • 9 years ago

Here's a patch I played around with a bit. This sort-of-nearly-works; it results in a vertical popup, as desired, but doesn't work entirely smoothly. The most obvious problem is that it's necessary to click twice on the <select> element to open the menu: the first click triggers display of the parent process's <select> element, but the attempt to call .click() on this doesn't seem to work so the user then has to click again in order to open it. Not satisfactory. (The patch also doesn't handle fullzoom scaling, but that should be fixable.)

I'm not likely to get much further with this, as I have other priorities to work on and don't understand front-end code at all anyway. So if someone with a better grasp of this area could take it, that would be awesome.

	Jonathan Kew [:jfkthame] Reporter
	Comment 7 • 9 years ago

Marcus, Mike: can one of you take this on, or suggest an appropriate assignee? The experimental patch (comment 6 above) offers a tantalizing glimpse of what might be possible, but it needs some love from a developer with more toolkit/JS knowledge than I have (essentially zero).

Thanks! We'd hate to see this feature regress when we ship e10s.

	Jonathan Kew [:jfkthame] Reporter
	Comment 8 • 9 years ago

s/Marcus/Markus/, sorry!

	Mike Conley (:mconley) (:⚙️)
	Comment 9 • 9 years ago

I think gw280 is fiddling with this? Is that right, George?

	George Wright (:gw280) (needinfo me!)
	Comment 10 • 9 years ago

Sort of, I'm looking into it from an e10s perspective, and this bug is currently tracking-. What sort of timeframe are we looking into for getting this done? It doesn't sound like this is going to be an actionable bug from the e10s team before release.

	Jonathan Kew [:jfkthame] Reporter
	Comment 11 • 9 years ago

(In reply to George Wright (:gw280) from comment #10)
> Sort of, I'm looking into it from an e10s perspective, and this bug is
> currently tracking-. What sort of timeframe are we looking into for getting
> this done? It doesn't sound like this is going to be an actionable bug from
> the e10s team before release.

It's a clear visual/behavior regression that will be triggered by enabling e10s (compare the behavior of http://people.mozilla.org/~jkew/tests/vertical-select.html without and with e10s in current Nightly to see the effect.) But obviously it's a rare case that most users are never going to encounter, so perhaps we can live with that temporarily.

It would be good to have this on someone's radar, though, so that it doesn't just languish indefinitely...

	Jim Mathies [:jimm]
	Comment 12 • 9 years ago

we support vertical writing mode for selects in non-e10s, so I don't see why this is tracking minus. We should support the same in e10s.

	Vlad Bacia-Mociran [:VladB]
	Comment 13 • 8 years ago

Hi,

I managed to reproduce this issue on the latest Aurora(46.0a2) on Windows 8.1 with e10s enabled.

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160204004009

This issue is also reproducible on Ubuntu 14.04 and Mac OS X 10.11.

Thank you,
Vlad

	Chris Peterson [:cpeterson]
	Comment 14 • 8 years ago

The layout/forms/test/test_select_vertical.html test is disabled for e10s on all platforms because of this bug.

@ Jonathan, is this bug still an issue? Your http://people.mozilla.org/~jkew/tests/vertical-select.html test seems to work for me in both e10s and non-e10s windows in Nightly 49.

	Jonathan Kew [:jfkthame] Reporter
	Comment 15 • 8 years ago

(In reply to Chris Peterson [:cpeterson] from comment #14)
> The layout/forms/test/test_select_vertical.html test is disabled for e10s on
> all platforms because of this bug.
> 
> @ Jonathan, is this bug still an issue? Your
> http://people.mozilla.org/~jkew/tests/vertical-select.html test seems to
> work for me in both e10s and non-e10s windows in Nightly 49.

On which platform? Note that the expected behavior here is to show a popup with vertical text that appears to the left of the <select> control. A horizontal popup below the <select> is not correct.

On OS X, at least, I still get a horizontally-oriented popup below the <select> in e10s mode. So yes, this is still an issue.

	Chris Peterson [:cpeterson]
	Comment 16 • 8 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #15)
> On which platform? Note that the expected behavior here is to show a popup
> with vertical text that appears to the left of the <select> control. A
> horizontal popup below the <select> is not correct.
> 
> On OS X, at least, I still get a horizontally-oriented popup below the
> <select> in e10s mode. So yes, this is still an issue.

I see now. I misunderstood the expected behavior of the drop "down" menu in the vertical writing test. The select menus are indeed broken with e10s enabled on OS X.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 18 • 7 years ago

[Triage] not a blocker as user could still select from the drop-down list, though it's an unfortunate regression and would be really nice to fix, setting P2 for now.

	Tommy Kuo (away forever...)
	Comment 19 • 7 years ago

Because the test case :jfkthame provided is deprecated, I upload a new test case for this.

	Tommy Kuo (away forever...)
	Comment 24 • 7 years ago

On Firefox 57, the <select> element stays vertical, but the options menu is horizontal. In Chrome and Safari, the <select> element and the options menu are both horizontal.

	Gérard Talbot
	Comment 25 • 7 years ago

4 tests from Writing modes test suite:

http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/form-controls-slr-004.htm

http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/form-controls-srl-004.htm

http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/form-controls-vlr-004.htm

http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/form-controls-vrl-004.htm

	siqinbilige
	Comment 26 • 7 years ago

For a reference,
It was worked when I have browser.tabs.remote.autostart and browser.tabs.remote.autostart.2 set to false.
Thank you.

	siqinbilige
	Comment 27 • 7 years ago

But it is better to set the direction of arrow to left or right, not face down.

	Gérard Talbot
	Comment 28 • 7 years ago

> to set the direction of arrow to left or right, not face
> down.

That's bug 1209411