1243254 - [e10s] <option> element attributes changing whilst <select> is open aren't indicated immediately

Status: RESOLVED DUPLICATE of bug 1350670

(Core :: Layout: Form Controls, defect, P3)

Description

[George Wright (:gw280) (needinfo me!)]

mconley spotted this when discussing bug 1242450.

Basically, if an option element's attribute changes whilst the popup is open (e.g. we add the hidden attribute, or the disabled attribute, etc), we have to close and reopen the popup in order to see a popup which reflects the new status.

Testcase: https://jsfiddle.net/8nnh6sL6/

Comment 1

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Did some light investigation:

* on OS X w/ Safari and Chrome, neither browser visually updates the menu
* on Win10 w/Edge and Chrome, edge doesn't show the change, chrome I intermittently ran into a bug where the second option's text was displayed or hidden, but it was not easy or reliable to get things into this state. Probably a bug in blink, and in most cases the select pop-up did not change.

This is another interesting case where they behaviour we've arrived at with e10s is more consistent with other browsers, and non-e10s Firefox is the odd man out.

Comment 2

[Sam Foster [:sfoster] (he/him)]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #1)
> Did some light investigation:
> 
> * on OS X w/ Safari and Chrome, neither browser visually updates the menu
> * on Win10 w/Edge and Chrome, edge doesn't show the change, chrome I
> intermittently ran into a bug where the second option's text was displayed
> or hidden, but it was not easy or reliable to get things into this state.
> Probably a bug in blink, and in most cases the select pop-up did not change.
> 
> This is another interesting case where they behaviour we've arrived at with
> e10s is more consistent with other browsers, and non-e10s Firefox is the odd
> man out.

So, is this a bug that needs fixing, or a feature that is good as-is? As it stands with this bug open, we seem to be saying that its a bug that those changes are not reflected until the popup is next shown. But, by saying we're now consistent with other browsers its implied that this is a good thing (and therefore this bug should be closed as invalid)

My 2c is that other browsers showing similar behavior provides reason to ask the question, but doesn't by itself provide an answer. The behavior is a judgement call, but one way to look at it is like this: if we had  <select> with size > 1 (i.e. the options are displayed as a list on the page, not in a popup), I think the expectation would be that making an option hidden should immediately remove it from the list visible to the user. I would argue that this means the same should be true for <select size=1>. Having items from the popup options list appear and disappear while it is shown might be a poor user experience in some cases, but the page author has the necessary context to make this decision; we (the browser) do not.

Comment 3

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I think a few things need to happen with this bug:

1. some UX / standards feedback on what we should do considering the behavior is basically undefined / inconsistent.
2. based on that feedback, I would be happy with wontfixing if we think the current behavior is fine or actually addressing this issue and matching the suggested behavior.

I assigned P3 to get it out of the way of e10s at the time. A year later, I have no stronger opinion than then.

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

[Triage] on Mac Nightly 55, the list will be updated immediately, and verified by two folks, so going to close it.
If you don't think this is the right behaviour, we'd suggest you file another new bug for further UI discussion.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I used mozregression tool and got the result - it's resolved by bug 1350670