Closed Bug 1187680 Opened 5 years ago Closed 4 years ago

'Flicker' effect when mousing over context menu items


(Core :: Graphics, defect)

41 Branch
Not set



Tracking Status
firefox41 --- affected
firefox42 --- fixed
firefox43 --- fixed


(Reporter: dana, Assigned: mstange)


(Blocks 1 open bug)


(Whiteboard: [elcapitan])


(2 files)

Attached video flicker.mp4
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150725004004

Steps to reproduce:

I've just got a 2014 MacBook Pro with a Retina display to replace my non-Retina MacBook Air. My MBA has been running Aurora on the El Capitan DP for several weeks, and i have no issues there. However, on my MBP, with the exact same versions of OS X and Firefox, there is a persistent display bug when mousing on to / off of context-menu items. There are no other relevant differences between the two machines that i can think of besides the hardware, which is why i'm assuming this is related to HiDPI in some way — but i'm not actually sure.

The problem is this: When a context menu is being displayed and none of its child nodes are in the hover state, the background of the menu (which uses the fancy blur effect introduced in Yosemite, by way of -moz-appearance: menupopup) is different from the background that appears when one of its nodes is in the hover state. When the mouse cursor is moved on and off of a context menu item, this produces a very distracting 'flicker' effect as the background is swapped in and out.

I've attached a small video illustrating the problem.

I can replicate this with a new profile, with any screen resolution, and with any context menu (both within the page content area and within the browser chrome). I've only just got the machine this week, so i'm not sure if there was a regression.

1. Right-click somewhere
2. Move cursor over a menu item
3. Move cursor off the menu

Actual results:

The background of the menu is noticeably darker / more saturated when one of its child nodes is in the hover state. (I'm not sure which background is 'correct', but i assume it's the lighter one.)

Expected results:

The background of the menu should not change when moving the mouse over it.
There is nothing like any flickr or blur on my windows machine 32 bit
Build ID 	20150725004004
User Agent 	Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0

Moving to a specific OS
Severity: normal → trivial
OS: Unspecified → Mac OS X
Severity: trivial → normal
Component: Untriaged → Graphics
Product: Firefox → Core
I was experimenting with this more and found something: The problem seems related to certain -moz-appearance values applied to the menuitem elements (the ones with the hover effects). They're set to -moz-appearance: menuitem by default.

If you add the following code to userChrome.css or to a Stylish sheet, the erroneous menu background goes away:

menuitem[_moz-menuactive="true"] {
  -moz-appearance: none !important;

Not a solution, but maybe a clue.
Can you still reproduce the issue with latest Nightly?
Flags: needinfo?(bugs)
Thanks for looking at this. Yes, i am able to replicate it with a new profile in Nightly:

Firefox 42.0a1 (2015-08-06)
OS X 10.11 Beta (15A244d) (Developer Beta 5)

For reference, i was previously using Aurora on Developer Beta 4.
Flags: needinfo?(bugs)
Oh, some mistakes in my report:

1. I thought my MBP was on DB5 based on the updates shown in the App Store. I'm actually on DB6 now.

2. I had thought that my non-Retina MacBook Air was on DB4 like my MBP was when i reported the issue; apparently i was wrong there too. I have just upgraded my MBA to DB4 (still working on DB5) and the same issue is present there. So i presume that (a) this bug was triggered by changes in OS X Developer Beta 4 and (b) it's not related to HiDPI at all.
Since this issue is only reproducible in, effectively, an alpha version of an operating system I would suggest you make sure Apple is aware of this issue. I think Apple's Developer Beta's are too much of a moving target for us to support and this isn't something we should devote a lot of resources to right now. I'd be more inclined to prioritize this if this was closer to a consumer release of OS 10.11.

Resolving this bug as INVALID for now but let's keep an eye on it.
Closed: 5 years ago
Resolution: --- → INVALID
Whiteboard: [elcapitan]
Thanks for looking at it. Just FYI, this is still an issue in Aurora on Developer Beta 7 / Public Beta 5 (build 15A263e), which was released today. I've not yet submitted a bug to Apple's Radar but i guess i will soon.

By the way, the previous two versions of OS X had 8 Developer Preview builds before final release, so assuming that pattern holds i'm not sure it's fair to call these 'alpha'.
Hello again. Apple have closed my ticket (Radar # 22357390) with the following notes:

> This is an issue for a third party to resolve based on the following:
> Mozilla is using SPI in CoreUI to mimic our interface. Not supported.
> We are closing this report.
> If you have questions about the resolution, or if this is still a critical
> issue for you, then please update your bug report with that information.
> Please be sure to regularly check new Apple releases for any updates that
> might affect this issue.

Not sure what the etiquette is on me re-opening Bugzilla tickets but there it is i guess
Apple was nice enough to add a new vibrancy material for menus in 10.11, and once we use that the flickering no longer happens.
Assignee: nobody → mstange
Ever confirmed: true
Resolution: INVALID → ---
Bug 1187680 - Use NSVisualEffectMaterialMenu for menus if it's available. r?smichaud
Attachment #8656306 - Flags: review?(smichaud)
Blocks: el-capitan
Attachment #8656306 - Flags: review?(smichaud) → review+
Comment on attachment 8656306 [details]
MozReview Request: Bug 1187680 - Use NSVisualEffectMaterialMenu for menus if it's available. r?smichaud

This looks reasonable to me, though I haven't tested it.
Closed: 5 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Comment on attachment 8656306 [details]
MozReview Request: Bug 1187680 - Use NSVisualEffectMaterialMenu for menus if it's available. r?smichaud

This is one of the two annoying regressions with 10.11, which will be released on September 30th. I think we should uplift the patch to Beta, if at all possible. It's a very simple patch, almost no risk.

Approval Request Comment
[Feature/regressing bug #]: Vibrant context menus (bug 1045213)
[User impact if declined]: Annoying flickering on 10.11, which will be released on September 30th
[Describe test coverage new/current, TreeHerder]: none, practically untestable
[Risks and why]: extremely low, very simple patch
[String/UUID change made/needed]: none
Attachment #8656306 - Flags: approval-mozilla-beta?
Attachment #8656306 - Flags: approval-mozilla-aurora?
Comment on attachment 8656306 [details]
MozReview Request: Bug 1187680 - Use NSVisualEffectMaterialMenu for menus if it's available. r?smichaud

I am going to take it for 42 as we have plenty of time for potential regressions.
Ritu will make the call for 41.
Attachment #8656306 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8656306 [details]
MozReview Request: Bug 1187680 - Use NSVisualEffectMaterialMenu for menus if it's available. r?smichaud

Landing patches in RC is very risky and should only be done for issues that are release blocking. Examples would be sec-issues that are critical and quite easily exploitable, crash/hang issues that would make Firefox unusable or major regressions compared to beta8/9. I do not think this bug meets the RC criteria.
Attachment #8656306 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
Duplicate of this bug: 1212012
Thunderbird 38.7.0 is also/still affected by this bug.
How should I proceed? (Create a separate "Thunderbird" Bug?)
Markus, do we need an equivalent "vibrancy" fix for 10.12?
Flags: needinfo?(mstange)
No, the change was for 10.11+ and still works on 10.12.
Flags: needinfo?(mstange)
You need to log in before you can comment on or make changes to this bug.