Closed Bug 984939 Opened 7 years ago Closed 7 years ago

[Australis] blank Panel Menu in Customize mode after scrolling inside

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 987497
Tracking Flags:
Tracking Status
firefox29 + wontfix
firefox30 + wontfix
firefox31 - affected
firefox32 --- affected

People

(Reporter: bogdan_maris, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [Australis:P3-]) 

Reproducible on the latest Aurora (BuildID: 20140318004002):
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0
Reproducible on the latest Nightly (BuildID: 20140318030202): 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Firefox/31.0

Steps to reproduce:
1. Launch latest Nightly
2. Open Panel Menu and click Customize
3. Change the height of Firefox until a scroll-bar appears in the menu
4. Focus the Panel and scroll

Expected results:
Scrolling is smooth.

Actual results:
Panel menu turns blank and if scrolled all the way down the tools are unnamed.

Notes:
1. Does not reproduce if hardware acceleration is turned off.
2. Screencast showing the issue.
3. I was able to reproduce only on Mac OS X with nVIDIA GPU (two different machines):

Machine 1:
Device ID    0x 8a4
GPU Accelerated Windows    1/1 OpenGL (OMTC)
Vendor ID    0x10de
WebGL Renderer    NVIDIA Corporation -- NVIDIA GeForce 320M OpenGL Engine
windowLayerManagerRemote    true
AzureCanvasBackend    quartz
AzureContentBackend    quartz
AzureFallbackCanvasBackend    none
AzureSkiaAccelerated    0

Machine 2:
Device ID 0x 861
GPU Accelerated Windows 0/1 Basic
Vendor ID 0x10de
WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce 9400 OpenGL Engine
windowLayerManagerRemote false
AzureCanvasBackend quartz
AzureContentBackend quartz
AzureFallbackCanvasBackend none
AzureSkiaAccelerated 0


4. This issue is a regression

m-c

Last good revision: d01bf8596d3b (2014-03-08)
First bad revision: 21f293fc8d34 (2014-03-09)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d01bf8596d3b&tochange=21f293fc8d34

m-i

Last good revision: 947e70a10659
First bad revision: 21f293fc8d34
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=947e70a10659&tochange=21f293fc8d34
So this is OSX-only?
Blocks: australis-cust
Whiteboard: [Australis:P3+]
I can't reproduce this, even though I also have an nVidia GPU:

NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine

On yesterday's (17th) nightly.

Also, you mentioned a screencast showing the issue, but I don't see any here. Can you clarify?

Decreasing priority for now.
Flags: needinfo?(bogdan.maris)
Whiteboard: [Australis:P3+] → [Australis:P3-]
(In reply to :Gijs Kruitbosch from comment #1)
> So this is OSX-only?

Yes I could only reproduce on two Mac minis (Mid 2010) with Intel Core 2 Duo 2.0 GHz both of them and only on 10.8.5, for some reason 10.9.1 and 10.7.5 are not affected.

(In reply to :Gijs Kruitbosch from comment #2)
> Also, you mentioned a screencast showing the issue, but I don't see any
> here. Can you clarify?

Sorry I forgot about the screencast, here it is: http://goo.gl/2INqne
Flags: needinfo?(bogdan.maris)
Thanks for the screencast, Bogdan! This might provide enough detail for Markus to get (a glimpse of) an idea of what might be going on... ?
Flags: needinfo?(mstange)
Amazing. I'd really like to reproduce this, but I can't :(

The bug might have to do something with component alpha layers. I could imagine that we get results like those in the screencasts when we succeed in drawing into the black buffer but fail when drawing into the white buffer. But that's just a guess.
Flags: needinfo?(mstange)
Well, I know mconley has a Mac Mini at the office... maybe it even has 10.8.5 on it? Mike. could you have a quick look with an Aurora build if this is the case?
Flags: needinfo?(mconley)
So my MacBook here has 10.8.5 on it, and the following specs:

Device ID	0x fd5
GPU Accelerated Windows	1/1 OpenGL (OMTC)
Vendor ID	0x10de
WebGL Renderer	NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine
windowLayerManagerRemote	true
AzureCanvasBackend	quartz
AzureContentBackend	quartz
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

No luck reproducing on it.

My MacMini in the office has 10.6 on it - but we might have some with 10.8.5 hanging around - I'll see what I can find out.
No luck reproducing this on my 10.6 MacMini with the following specs:

Device ID	0x 8a4
GPU Accelerated Windows	1/1 OpenGL (OMTC)
Vendor ID	0x10de
WebGL Renderer	NVIDIA Corporation -- NVIDIA GeForce 320M OpenGL Engine
windowLayerManagerRemote	 true
AzureCanvasBackend	quartz
AzureContentBackend	quartz
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

These are the same specs that Bogdan had on his Machine #1.
Update - jlin might have a line on a machine with 10.8 matching Bogdan's Machine #1. He's eating lunch, but will hook me up after.
Flags: needinfo?(mconley)
Ok, I've reproduced it booting to 10.7 on my Mac Mini.
Now that I've got it reproduced over here... what do I do? mstange, can I give you remote access to this machine for you to debug it or something?
Flags: needinfo?(mstange)
(In reply to Mike Conley (:mconley) from comment #10)
> Ok, I've reproduced it booting to 10.7 on my Mac Mini.

\o/ Half the work here is done! Thanks Mike!
More facts - disabling OMTC fixes this bug.
Ok, I showed this to BenWa, and here's what we've found out:

1) This seems to be related to MaskLayers, since the bug goes away if we remove the border-radius from the panel container
2) This seems to affect ActiveLayers only, which is why the icons / text come back after about a 5 second delay once we shift from active to inactive

Cc'ing some folks that BenWa recommended.
Component: Theme → Layout
Flags: needinfo?(mstange)
Product: Firefox → Core
Not sure if Layout was the right component, but it's certainly more correct than Firefox::Themes.
It looks like this problem was introduced first on the fx-team branch at this revision:

https://hg.mozilla.org/integration/fx-team/rev/4dab55a994e5
Blocks: 977217
The regression was caused by this chunk of the change:

https://hg.mozilla.org/integration/fx-team/rev/4dab55a994e5#l2.36

Using the Browser Toolbox, it looks like when we removed overflow: hidden from .toolbarbutton-1:not([type="menu-button"]), we introduced this.

I've confirmed that putting that rule back, and forcing overflow: hidden on those toolbaritems seems to fix the issue.

I'm not sure what to do about this. This is one of those wacky layout things, where we have a workaround, but I'm not entirely sure what other bugs the workaround might introduce.

Any thoughts, jaws?
Flags: needinfo?(jaws)
Setting overflow:hidden on that will bring back bug 977217 and maybe another bug too.
Flags: needinfo?(jaws)
Ok, if that's the case, we'd better pass this along to some platform folks. Perhaps there's something they can do, or recommend that _we_ do.

Not sure who to point at this. I'm still not sure if this is a Layout or a Graphics bug, and still no idea how many of our OS X users are going to be exposed to it.

roc - do you know offhand if this bug would fall into the layout or graphics domain? If layout, do you know who might have a few cycles to investigate this?
Flags: needinfo?(roc)
Nominating for tracking since this is a regression.
status-firefox30: --- → affected
status-firefox31: --- → affected
tracking-firefox30: --- → ?
tracking-firefox31: --- → ?
Keywords: regression
I'm on the road. Hopefully Matt Woodrow can help.
Flags: needinfo?(roc) → needinfo?(matt.woodrow)
Mike,

Is this something that needs tracking on 29 also?
status-firefox29: --- → ?
tracking-firefox29: --- → ?
Flags: needinfo?(mconley)
Yes, this affects 29.
Flags: needinfo?(mconley)
Matt, could you help here? 29 is getting closer. Thanks!
I can't reproduce this either unfortunately, with either GPU on my machine.

Assuming this has something to do with both Component Alpha, and Mask Layers, could we put a background on the scrolled content?

Currently the background is fixed, and the text scrolls relative to the background. Changing this might work around this issue, and should just perform better too.
Flags: needinfo?(matt.woodrow)
Hm, so changing the background of the scroller to an image or a color didn't help any... any other suggestions?

If needs be, Matt, I can give you remote access to this Mac Mini if you'd like to debug. Would that be useful?
Flags: needinfo?(matt.woodrow)
In the meantime, I'm going to poke at this and see where I get (likely answer is "not far", but let's give it an hour or two).
BenWa was at my desk poking at this yesterday, and he discovered a number of things.

BenWa - can you summarize your findings for future reference?
Flags: needinfo?(bgirard)
Definitely too late in FF29 cycle to look at speculative fixes so this will have to be a follow up in 30 once there's more info on reproducing and what the findings are as mentioned in comment 28.
status-firefox29: affected → wontfix
(In reply to Mike Conley (:mconley) from comment #28)
> BenWa was at my desk poking at this yesterday, and he discovered a number of
> things.
> 
> BenWa - can you summarize your findings for future reference?

We're hitting a driver specific bug with the case EFFECT_COMPONENT_ALPHA:
http://mxr.mozilla.org/mozilla-central/source/gfx/layers/opengl/CompositorOGL.cpp#1097

I didn't fully finish narrowing it down further then that. I don't know for sure if we're hitting the mask. I don't know exactly which subset here the driver bug is hitting.

A workaround should be possible here. Otherwise we could disable acceleration on that driver :(.
Flags: needinfo?(bgirard)
When you have time BenWa, I'm happy to give you remote or local access to the MacMini on my desk to help you find the root of the problem.
Putting this on BenWa's radar with a needinfo...
Flags: needinfo?(matt.woodrow) → needinfo?(bgirard)
Duplicate of this bug: 1004417
There's bug 1004417 that reproduces on Linux on Intel and AMD so this is unlikely to be a driver bug. We need to get this fixed!
Blocks: 948531
Uh... hmm... I'm no longer able to reproduce this on the same machine I experienced the issue on before with a recent Nightly...

Bogdan - do you still see it?
Flags: needinfo?(bogdan.maris)
(In reply to Mike Conley (:mconley) from comment #36)
> Uh... hmm... I'm no longer able to reproduce this on the same machine I
> experienced the issue on before with a recent Nightly...
> 
> Bogdan - do you still see it?

Did OS X get updated? (10.9.2 to 10.9.3 for instance)
(In reply to :Gijs Kruitbosch from comment #37)
> (In reply to Mike Conley (:mconley) from comment #36)
> > Uh... hmm... I'm no longer able to reproduce this on the same machine I
> > experienced the issue on before with a recent Nightly...
> > 
> > Bogdan - do you still see it?
> 
> Did OS X get updated? (10.9.2 to 10.9.3 for instance)

No, I had reproduced this on 10.8.4, and I haven't installed any updates since.
I can still reproduce this on latest Nightly, latest Aurora and Firefox 30 beta 6 using Mac OS X 10.8.5. One of the machines I reproduced it in the first place.
Flags: needinfo?(bogdan.maris)
With the difficulty to reproduce and no sign that this is affecting a significant number of users I'm untracking and wontfixing for FF30 since we're too late to take a fix of this risk to that channel.  We can certainly consider uplift nominations to branches when one is ready, depending on timing during the cycle.
status-firefox30: affected → wontfix
status-firefox32: --- → affected
tracking-firefox31: + → -
Also perhaps this is a good candidate for backlog.
Flags: firefox-backlog?
Flags: firefox-backlog? → firefox-backlog+
Flags: firefox-backlog+ → firefox-backlog-
This is very likely to be the same bug as bug 987497, and we have a patch there that seems to fix it.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(bgirard)
Resolution: --- → DUPLICATE
Duplicate of bug: 987497
You need to log in before you can comment on or make changes to this bug.