614851 - Preserve the option element's direction and text-alignment after an item is chosen from a <select> drop-down menu

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[(no longer active)]

See the test case.  Select the second item in the left-most drop-down box.  The contents of the two select elements, after that, should be the same (sans the direction of the drop-down control.

The HTML5 spec has been modified to suggest that:

"User agents are expected to render the labels in a select in such a manner
that any alignment remains is consistent whether the label is being displayed
as part of the page or in a menu control."

<http://dev.w3.org/html5/spec/Overview.html#the-select-element-0>

Comment 1

[Boris Zbarsky [:bzbarsky]]

OK.  So the spec text doesn't make sense (I'll file a bug about that), but at least I can see why the expected behavior in the attached testcase might be desirable.  ;)

It's a bit of a pain to implement with our current combobox setup, but maybe we should consider changing that setup; we've had previous bugs about preserving the font styles, colors, etc from the option in the display area too...

Comment 2

[(no longer active)]

What about the current setup makes this difficult to implement?

Comment 3

[Boris Zbarsky [:bzbarsky]]

The display area is just a child of the <select> and gets styles by direct rules applied to it and by inheriting from the <select>.  So to use the same styles as some <option> it has to have those styles set on it directly.  But changing styles on it dynamically as the selected option is changed is risky business, esp if we want it to pick up the "direction" property (since we've thought about making that recreate frames in the past).

Comment 4

[(no longer active)]

Hmm, is there any way to set the style context on a child node override that of its parent?

Comment 5

[Boris Zbarsky [:bzbarsky]]

What do you mean?  Style contexts aren't on nodes, for one thing (so far, etc).

Comment 6

[(no longer active)]

(In reply to comment #5)
> What do you mean?  Style contexts aren't on nodes, for one thing (so far, etc).

I mean, is there any way to change the inheritance of style contexts so that they inherit from a child to a parent, instead of the usual way (from the parent to the child)?

Comment 7

[Boris Zbarsky [:bzbarsky]]

There is, sorta, but how would that help here?

Comment 8

[(no longer active)]

(In reply to comment #7)
> There is, sorta, but how would that help here?

Well, if we could make the select element inherit the styles from the selected option element... or am I barking off the wrong tree?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Yeah, wrong tree.  That's equivalent to just setting inline style or something on the select; in particular it will change its computed style and possibly trigger a reframe, which I don't think we want.

I wonder... can we use something like -moz-element to set the background of the display area to the currently selected <option> or some such hackery?  We'd need to not stomp on the user-visible -moz-element namespace... but it would make sure that the display area looks exactly like the <option>.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, we could do something like that.

The easiest way might be to have nsComboboxControlFrame::BuildDisplayList find the selected <option> frame and do a BuildDisplayListForStackingContext on it, and wrap the returned display items in an nsDisplayTransform to make sure they end up in the right place. We wouldn't do this for event handling of course.

Comment 11

[Boris Zbarsky [:bzbarsky]]

We should check what other UAs do (esp IE)... if their display area and dropdown are always in sync looks-wise, then this is a viable approach.

Comment 12

[(no longer active)]

Chrome:

http://grab.by/7DRK

Webkit nightly:

http://grab.by/7DRN

Opera 11.0beta:

http://grab.by/7DRR

None of them are getting this right...

Comment 13

[Boris Zbarsky [:bzbarsky]]

<sigh>.

What about IE?

Should we just try to standardize my proposal from comment 9?  ;)

Comment 14

[Johnathan Nightingale [:johnath]]

Attachment: IE8 screenshot

Comment 15

[Johnathan Nightingale [:johnath]]

Attachment: IE9 screenshot

Comment 16

[Boris Zbarsky [:bzbarsky]]

So IE8/9, Opera, and Chrome all do the same thing with the bidi stuff, right?

What do they do with colors, font-size, text-decoration, letter-spacing on options?

Comment 17

[(no longer active)]

(In reply to comment #16)
> So IE8/9, Opera, and Chrome all do the same thing with the bidi stuff, right?

Yes, and I guess that means that they all need to change their implementation!

> What do they do with colors, font-size, text-decoration, letter-spacing on
> options?

Chrome doesn't respect those styles at all, neither in the drop-down menu nor when the option is selected.

Webkit nightly only seems to respect the font-size in the drop-down menu, and nothing when the option is selected.

Opera doesn't respect any of those settings anywhere.

IE9 only seems to respect the color in the drop-down menu, and nothing when the option is selected.

I'm starting to think that what we want is to only reflect the direction in the selected mode...

Comment 18

[Boris Zbarsky [:bzbarsky]]

> Opera doesn't respect any of those settings anywhere.

Opera 10.6 on Mac seems to at least respect the color in the display area (but not in the dropdown) here.

Those are very interesting results; I'm not sure how to explain bug 79107 and its various duplicates given the above results.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Do the results differ in standards mode, btw?

Comment 20

[(no longer active)]

(In reply to comment #19)
> Do the results differ in standards mode, btw?

No.

(In reply to comment #18)
> > Opera doesn't respect any of those settings anywhere.
> 
> Opera 10.6 on Mac seems to at least respect the color in the display area (but
> not in the dropdown) here.
> 
> Those are very interesting results; I'm not sure how to explain bug 79107 and
> its various duplicates given the above results.

I've also noticed that browsers who tend to use platform native controls for drop-down elements tend to ignore the styling.  For example, IE9, if connected to the computer via remote desktop, would use a non-native control, and hence would start respecting the color for when the option is selected too.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Oh, interesting.  So what happens if you do something to the <select> that drops native theming (like styling its border or background or whatnot), across browsers?

Comment 22

[(no longer active)]

OK, using this testcase:

data:text/html,<select style="width:200px;border:5px solid green"><option dir=ltr>foo</option><option dir=rtl style="color:red;font-size:30px;text-decoration:underline;letter-spacing:3em">bar.</option></select><select dir=rtl style="width:200px;border:5px solid green"><option>bar.</option></select>

Firefox behaves the same.
Opera behaves the same.
Chrome behaves the same.
Webkit behaves the same.
IE behaaves the same as it being run in RDC mode.

Comment 23

[Aharon (Vladimir) Lanin]

I looked at this again in Nightly, and the status is that Firefox respects the directionality of <option> only in the drop-down. Once it has been selected, the directionality of the <select> is applied to the <option> value, which is then thus potentially displayed incorrectly. For example, <select dir=rtl><option dir=ltr>2001: A Space Odyssey</option></select> is displayed (correctly) as "2001: A Space Odyssey" in the drop-down, but (incorrectly) as "A Space Odyssey :2001" once selected. This is not according to the HTML5 spec, and is a real problem.

WebKit now behaves correctly.

Please let's concentrate on the directionality aspect. The alignment aspect is, without a doubt, secondary.

I am attaching a test case.

Comment 24

[Aharon (Vladimir) Lanin]

Attachment: test case

Comment 25

[(no longer active)]

Given the discussion on this bug, I'm confused as to what we would want to do here...

Comment 26

[Aharon (Vladimir) Lanin]

I think that the first thing to do is to ignore the style issue, and concentrate on getting the directionality of the <option> determine the display of its value after it has been selected. That is by far more important than deciding what <option> styles (if any) to apply, or whether they should be applied equally in the drop-down and after the option has been selected.

Comment 27

[(no longer active)]

This entire discussion was spawn off of comment 1.  Boris, do you think we can focus on the direction problem in this bug, and not try to solve all of the problems at once?  :-)

Comment 28

[Boris Zbarsky [:bzbarsky]]

That's fine, but the direction problem may be the hard one; see comment 3.  Does it cause a reframe right now?

Comment 29

[Aharon (Vladimir) Lanin]

Just a somewhat obvious note: the chosen <option>'s direction should not be applied to the whole <select>, just to the selected value inside it. For example, the arrow button that opens the drop-down should always be on the end side relative to the <select>'s direction, regardless of which <option> is selected.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Sure; for purposes of resolving the implementation difficulties here that happens to not matter because the "selected value" part has no independent existence in some senses.

Comment 31

[(no longer active)]

(In reply to Boris Zbarsky (:bz) from comment #28)
> That's fine, but the direction problem may be the hard one; see comment 3. 
> Does it cause a reframe right now?

It does for things like textareas.  Can we do the same for selects, or do you expect performance problems?

Comment 32

[Boris Zbarsky [:bzbarsky]]

> Can we do the same for selects, or do you expect performance problems?

Let me back up.

Right now, a change to mDirection triggers a frame reconstruct.

This bug is asking for changes to the direction of the combobox display area when a different option is selected.  That would involve a reconstruct of that display area.  Since it just uses the <select> as its content node, that means a reconstruct of the select itself.

This would be pretty bad.  For example, if you click on a combobox and then use arrow keys to change the selected option you might get reconstructs as you go.... but then you lose your opened dropdown and whatnot.

One possible approach is to have the display area correspond to an actual anonymous element that contains another element that then contains the text.  We could then change styles on the inner element as needed, I think; even reframing it would be fine.  That does involve having two extra elements around and whatnot.

Comment 33

[(no longer active)]

I don't understand the need for the second extra element.  The display area could be an anonymous div which contains a textnode, right?  That way, we can change the dir attribute on the div as the listbox selection changes, which should do the right thing, IINM.

Comment 34

[Boris Zbarsky [:bzbarsky]]

You can't usefully reframe roots of native anonymous content subtrees, because reframing involves a remove and reinsert, and we don't have a way to express _where_ to reinsert for native anon content roots.

Comment 35

[(no longer active)]

Ah, OK, I did not know that.

Simon, are you going to have cycles to work on this by any chance?