On Windows (tested on 7) popup menus inherit <select>'s background colour in FF 55.0, in windows classic theme

VERIFIED FIXED

Status

()

Core
CSS Parsing and Computation
VERIFIED FIXED
6 months ago
3 months ago

People

(Reporter: Dr Owain Kenway, Unassigned)

Tracking

({multiprocess, regression})

55 Branch
All
Windows 7
multiprocess, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox55- verified, firefox56 unaffected, firefox57 unaffected)

Details

Attachments

(4 attachments)

(Reporter)

Description

6 months ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170803173024

Steps to reproduce:

Write a simple html + css document:

test.html:

<html>
<link href="test.css" rel="stylesheet" type="text/css" />
<body>
<select id="test">
<option value="1">opt 1</option>
<option value="2">opt 2</option>
<option value="3">opt 3</option>

</select>
</body>
</html>

test.css:

select {
    background-color: #FF0000;
}

Open in Firefox 55 on Windows 7, 32bit.

Right click on page to get pop-up menu.  Background on Pop-up menu is grey (as it should be).  Click on <select> object to drop-down its list.  Right-click on page - background on pop-up menu is now red (same as <select>).  Open new tab.  Navigate to Google.com and right click to get pop-up menu.  Background of pop-up menu is still red. 

I tested this on Firefox 55.0 on Linux and it did *not* have this issue so I assume it is limited to Windows, possibly 7 and possibly with the "classic" appearance.


Actual results:

For all pop-up menus (including some for extensions like ad-block), opened after a <select> object with a CSS colour applied, the background colour is the colour for the select object.

This persists for all pop-up menus opened from that window regardless of tab or site.  It does not apply for other windows.  It can be reset by opening another select item without a colour applied.

I have put screenshots here: https://twitter.com/owainkenway/status/895034199266263041


Expected results:

Pop-up menus should have stayed grey.
(Reporter)

Comment 1

6 months ago
Created attachment 8895296 [details]
Screenshot of pop-up before opening select object
(Reporter)

Comment 2

6 months ago
Created attachment 8895298 [details]
Screenshot of opening select object
(Reporter)

Comment 3

6 months ago
Created attachment 8895299 [details]
Screenshot showing that right click menu now has a red background like the select object
(Reporter)

Comment 4

6 months ago
Created attachment 8895300 [details]
Screenshot showing that this red background persists to other sites (and in this case another tab)

Updated

6 months ago
Component: Untriaged → Menus
Keywords: regression, regressionwindow-wanted

Comment 5

6 months ago
[Tracking Requested - why for this release]: UI broken

Regression window:
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=2255dbea626873d861e8031726ec120468c7923e&tochange=d553313466297741d50c810b95bd9685524dd461

Regressed by: Bug 1291515
Blocks: 1291515
Status: UNCONFIRMED → NEW
status-firefox55: --- → affected
status-firefox56: --- → unaffected
status-firefox57: --- → ?
status-firefox-esr52: --- → unaffected
tracking-firefox55: --- → ?
Component: Menus → CSS Parsing and Computation
Ever confirmed: true
Keywords: regressionwindow-wanted → multiprocess
OS: Unspecified → Windows 7
Product: Firefox → Core
Hardware: Unspecified → All
Summary: On Windows (tested on 7) popup menus inherit <select>'s background colour in FF 55.0 → On Windows (tested on 7) popup menus inherit <select>'s background colour in FF 55.0, in windows classic theme
Cameron, this is probably for you ;)
I don't think it is worth taking a fix in a 55 dot release but I can be wrong.
Flags: needinfo?(cam)
Is this what bug 1375224 should have fixed?  Jared, do you know?
Flags: needinfo?(cam) → needinfo?(jaws)

Comment 8

6 months ago
(In reply to Cameron McCormack (:heycam) from comment #7)
> Is this what bug 1375224 should have fixed?  Jared, do you know?


Via local build(win32), 
Build from
mozilla-release cace0357d40e : I can reproduce the problem
mozilla-release cace0357d40e+bug 1375224 patch: I can not reproduce the problem


Yep, the patch of bug 1375224 fixes the problem.
Depends on: 1375224
Thanks for checking Alice!  My feeling is that this is not a severe enough problem to uplift to Release.
I agree, thanks!
status-firefox55: affected → wontfix
tracking-firefox55: ? → -
Flags: needinfo?(jaws)
status-firefox57: ? → unaffected
I have requested uplift to release in bug 1375224 as this will affect many other sites in the long tail.
status-firefox55: wontfix → ?
status-firefox55: ? → affected

Updated

5 months ago
Duplicate of this bug: 1390929

Updated

5 months ago
Duplicate of this bug: 1386174

Comment 14

5 months ago
is this expected to be fixed in Fx 55.0.2 via bug 1375224?
(In reply to j.j. from comment #14)
> is this expected to be fixed in Fx 55.0.2 via bug 1375224?

Yes, can you verify that this is fixed in 55.0.2?
Flags: needinfo?(moz)
(Reporter)

Comment 16

5 months ago
Hi,

I tested last night and the fix in 55.0.2 did indeed resolve the issue for me.

Thanks for the speedy fix!

Owain
thanks
Status: NEW → RESOLVED
Last Resolved: 5 months ago
status-firefox55: affected → verified
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Flags: needinfo?(moz)
You need to log in before you can comment on or make changes to this bug.