1336301 - drop-down list only shows first entry in weird color

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Lee McFarland]

Attachment: bug2.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170202110108

Steps to reproduce:

Used a local county website which has a drop-down list to select an entry (numbered 1 through 20).
I then captured the web page then reduced a local copy to less than 100 lines with no graphics etc.  That reduced copy also has the problem.  I also ran this on yesterday's Nightly (2/1) - same issue and FF production 51, which does not have the issue.  The problem is not in production, nor do I remember it last time I was on the county website with Nightly less than three weeks ago.  


Actual results:

Only the first item (1) shows up.  Also, the item appears in an unusual color.  By the way, a drop down list in a county website in another state shows all entries but the unexpected brown color on item one is present.


Expected results:

There is be no difference with this file when comparing Nightly 2/2 with FF Production 51

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1336301 - Styles that are applied directly to the select element should be forwarded to the popup.

Review commit: https://reviewboard.mozilla.org/r/109818/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/109818/

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Thank you very much for the detailed bug report and reduced test case!

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1336301 - Move duplicated test code to a shared function.

Review commit: https://reviewboard.mozilla.org/r/109820/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/109820/

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8833594 [details]
Bug 1336301 - Styles that are applied directly to the select element should be forwarded to the popup.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/109818/diff/1-2/

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8833595 [details]
Bug 1336301 - Move duplicated test code to a shared function.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/109820/diff/1-2/

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8833594 [details]
Bug 1336301 - Styles that are applied directly to the select element should be forwarded to the popup.

https://reviewboard.mozilla.org/r/109818/#review111680

Thanks jaws! Looks okay to me - but the background-color on <style> doesn't work (at least) on OS X, because the menupopup has a `-moz-appearance: menupopup` on it. We might need to do the same thing we did with menuitems here, and bypass that if we're doing custom styling.

Removing that rule, there's a 4px padding on the top and bottom of the menupopup that looks pretty bad in conjunction with the scrollbar.

Example: set the <select> background color to red, and [this is what you get](http://imgur.com/a/qNq2P). So you might want to remove the padding on the top and bottom when custom styling as well. Good fodder for follow-up.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8833595 [details]
Bug 1336301 - Move duplicated test code to a shared function.

https://reviewboard.mozilla.org/r/109820/#review111682

Good stuff.

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8833594 [details]
Bug 1336301 - Styles that are applied directly to the select element should be forwarded to the popup.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/109818/diff/2-3/

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8833595 [details]
Bug 1336301 - Move duplicated test code to a shared function.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/109820/diff/2-3/

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8833594 [details]
Bug 1336301 - Styles that are applied directly to the select element should be forwarded to the popup.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/109818/diff/3-4/

Comment 11

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8833595 [details]
Bug 1336301 - Move duplicated test code to a shared function.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/109820/diff/3-4/

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d99909a6f86a
Styles that are applied directly to the select element should be forwarded to the popup. r=mconley
https://hg.mozilla.org/integration/autoland/rev/4dafc922f1cb
Move duplicated test code to a shared function. r=mconley

Comment 13

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Mike Conley (:mconley) from comment #6)
> Comment on attachment 8833594 [details]
> Bug 1336301 - Styles that are applied directly to the select element should
> be forwarded to the popup.
> 
> https://reviewboard.mozilla.org/r/109818/#review111680
> 
> Thanks jaws! Looks okay to me - but the background-color on <style> doesn't
> work (at least) on OS X, because the menupopup has a `-moz-appearance:
> menupopup` on it. We might need to do the same thing we did with menuitems
> here, and bypass that if we're doing custom styling.
> 
> Removing that rule, there's a 4px padding on the top and bottom of the
> menupopup that looks pretty bad in conjunction with the scrollbar.
> 
> Example: set the <select> background color to red, and [this is what you
> get](http://imgur.com/a/qNq2P). So you might want to remove the padding on
> the top and bottom when custom styling as well. Good fodder for follow-up.

I fixed this in the commit that landed, by adding an extra selector to menu.css on OSX if customoptionstyling is used.

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/d99909a6f86a
https://hg.mozilla.org/mozilla-central/rev/4dafc922f1cb

Comment 15

[Lee McFarland]

This morning Nightly is not even displaying the drop-down item when pointed at.  Previously the problem was that items only 
became visible when pointed out.  Now, even if pointed at, they are not visible.

Comment 16

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Lee McFarland from comment #15)
> This morning Nightly is not even displaying the drop-down item when pointed
> at.  Previously the problem was that items only 
> became visible when pointed out.  Now, even if pointed at, they are not
> visible.

Please file a new bug as the patches in this bug are still on mozilla-central and I can't reproduce your issue on Nightly 54.0a1 (2017-02-09) (64-bit) Windows 10. What operating system are you running? Do you have the dom.forms.selectSearch pref enabled or disabled? Do you have e10s enabled? Those would all be good information to include in your bug report. If you don't want to create a bug report you can at least include that information here as a comment.

Comment 17

[Lee McFarland]

Good to hear the problem can't be reproduced on Windows 10.  The problem persists on Linux 4.4.0-62-generic.
At minimum, someone should confirm it is fixed on the various platforms (Mac, Win 7, Win 8 and Unix).
The testcase previously included with the bug (bug2.html) as well as the government website on which
I first detected this 'invisible drop-down', are still broken with FF 54 (OK on FF51).  The text is
the same color (white) as the general background of the web page however, the drop-down background is a 
dark brown so the white text shows up.  An earlier version of the fix showed the drop-down item currently
mouse pointed as white with brown background although all other selection possibilities are white on white.  
As of this morning, even the selected possibility is white on white (invisible).

My specific system is Linux 4.4.0-62-generic.  My value for dom.forms.selectSearch is false, which is 
the default.  I did try toggling that item and saw no change. Since this issue has been observed
on existing web sites where the user community is neither technically advanced or have the desire
to be so, the fix should not involve a change of an item in about:config unless the default for that
item is reversed at the same time ie. the default must work.  The version of FF this morning is
FF 54.0.a1   (20170209110141)

Comment 18

[Jared Wein [:jaws] (please needinfo? me)]

Please don't change the status of the bug from 'resolved' to 'reopened' as that has a different meaning than I think you may be thinking. When a bug is 'reopened' it generally means that the patches were backed out and removed from our code base. If this bug is marked as 'reopened' and the patches weren't actually backed out it can cause a lot of confusion.

I only asked about dom.forms.selectSearch to help me understand why it might not be working for you. Users will not be expected to change that value. This should be working with that preference unchanged and at its default value.

I just tested on Ubuntu 16.10 and I see the problem. I will file a new bug and put a patch on it to fix the problem. Thank you for letting me know.

Comment 19

[Lee McFarland]

The problem I had reported is not present this morning.
FF:   	20170210110240
Operating system:  	Linux 4.4.0-62-generic
Useragent:  	Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

Previous to this, a comment was made that an earlier version of the fix corrected the issue on Windows 10.  
If the fix has different paths based on platform, has it been verified on other versions such as Apple?

Thanks for getting it fixed quickly.

Comment 20

[Jared Wein [:jaws] (please needinfo? me)]

This fix was verified on Windows and OSX before landing, but not on Linux, thus explaining how we missed it. The patch on the new bug only affects Linux.

You're welcome, thank you for letting me know so quickly.

Comment 21

[Emil Ghitta, QA [:emilghitta]]

I’ve reproduced the issue described in comment 0 using Firefox 54.0a1 (Build Id:20170202030211) and verified that the issue is not reproducible anymore using Firefox  54.0b2 (Build Id:20170424145525) on Windows 10 64bit , macOs 10.11.6 and Ubuntu 14.04 64bit.