Closed Bug 849157 Opened 10 years ago Closed 10 years ago

[OS X] Native dialogs/menus block <video> from being redrawn on Intel HD Graphics 3000

Categories

(Core :: Graphics, defect)

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

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla23
Tracking Flags:
Tracking Status
firefox21 --- unaffected
firefox22 + fixed

People

(Reporter: MattN, Assigned: mstange)

References

Details

(Keywords: regression)

Attachments

(1 file)

v1
1.53 KB, patch
BenWa
: review+
bajaj
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
STR A:
1) Play a <video>
2) Open the native menu at the top of the window on OS X

STR B:
1) Play a <video>
2) Click Browse… on an <input type=file> to launch the native file picker.

Expected result:
Video and audio continue playing and painting to the display.

Actual result:
Audio continues playing, while video remains on the last frame before using the native widget.

about:support info:
  Graphics

        Device ID
        0x 126

        GPU Accelerated Windows
        2/2 OpenGL

        Vendor ID
        0x8086

        WebGL Renderer
        ATI Technologies Inc. -- ATI Radeon HD 6750M OpenGL Engine

        AzureCanvasBackend
        quartz

        AzureContentBackend
        none

        AzureFallbackCanvasBackend
        none

Opening another build of Nightly, the problem wasn't reproducible and I suspect this is because it was using the other graphics card (AMD Radeon HD 6750M): Device ID: 0x6741; Vendor ID: 0x1002 with the other about:support gfx details being the same.
I just found a similar issue (maybe :), running with the Australis/UX build with tabs-in-titlebar (see bug 625989 comment 60)...

With a tab stalled in the loading state, the spinning throbber is partially in the titlebar area. When I open a native menu or just click-and-hold on a windows border (as if I was going to resize the window), the animation freezes. Except for the sliver in the titlebar, which continues to animate normally. Weird.

GIFs do exactly the  same thing -- the animation in content freezes, and the scaled version in the favicon is frozen on the bottom while the bit in the titlebar is ok. A regular Nightly also exhibits the freezing for me.

eg https://people.mozilla.com/~dolske/tmp/rickroll.gif


about:support info:

Device ID 0x fd5
GPU Accelerated Windows 2/2 
OpenGLVendor ID 0x10de
  WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine
AzureCanvasBackend quartz
AzureContentBackend none
AzureFallbackCanvasBackend none
The GIF does not freeze when a native menu is open in Firefox 19.0.2, so this looks like a regression.
Keywords: regressionwindow-wanted
Last good nightly: 2013-03-05
First bad nightly: 2013-03-06

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=015da7030aab&tochange=216ec69cc531

I would guess the cause is bug 676250.
status-firefox21: --- → unaffected
status-firefox22: --- → affected
tracking-firefox22: --- → ?
Keywords: regressionwindow-wanted → regression
Getting a trace of how we get to EndTransaction in this scenario without the patch for bug 676250 would be handy. Then we can look at why we can't hit EndTransaction with that patch. I wont have time to look at it next week so if we can't get anyone to investigate we should back it out :(.
Alright, I'm OK backing it out for now.
I'll double-check this is causing the bug first, and then I'll do the backout.
Hrm, so locally reverting bug 676250 didn't resolve the problem. Locally bisecting now...
No longer blocks: 676250
(In reply to Mike Conley (:mconley) from comment #7)
> Hrm, so locally reverting bug 676250 didn't resolve the problem. Locally
> bisecting now...

I let mozregression continue to narrow down the regression with local builds and it still pointed to bug 676250.

The first bad revision is:
changeset:   123831:c95439870e05
user:        Markus Stange
date:        Tue Mar 05 10:21:28 2013 -0500
summary:     Bug 676250 - Make OpenGL painting bypass the Cocoa setNeedsDisplay/drawRect machinery. r=bgirard.
Regression found using mozcommitbuilder 0.4.10 on darwin at 2013-03-16 04:08:41
Yeah, locally bisecting confirmed that too. I guess my original backout was bogus. *sigh*.
Blocks: 676250
Any idea what's happening here, Markus?
Flags: needinfo?(mstange)
Assignee: nobody → mstange
Not yet, but I'll look into it. I haven't been able to reproduce it in a mozilla-central build yet, only in the UX nightly.
Flags: needinfo?(mstange)
Attached patch v1 — — Splinter Review 
Native menus run an event loop with a different runloop mode than the default one, and normal delayed performs only fire in the default mode. We need to explicitly specify the right mode.
Attachment #733455 - Flags: review?(bgirard)
Attachment #733455 - Flags: review?(bgirard) → review+
https://hg.mozilla.org/mozilla-central/rev/acd478e0bd55
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
(In reply to Markus Stange from comment #13)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/acd478e0bd55

Would you mind requesting uplift to FF22 with a risk evaluation?
Flags: needinfo?(mstange)
Comment on attachment 733455 [details] [diff] [review]
v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 676250
User impact if declined: animations freeze while a native menu is open
Testing completed (on m-c, etc.): 12 days on mozilla-central
Risk to taking this patch (and alternatives if risky): low risk
String or IDL/UUID changes made by this patch: none
Attachment #733455 - Flags: approval-mozilla-aurora?
Flags: needinfo?(mstange)
Attachment #733455 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Matthew N. [:MattN] from comment #0)
> STR A:
> 1) Play a <video>
> 2) Open the native menu at the top of the window on OS X
> 
> STR B:
> 1) Play a <video>
> 2) Click Browse… on an <input type=file> to launch the native file picker.
> 
> Expected result:
> Video and audio continue playing and painting to the display.
> 
> Actual result:
> Audio continues playing, while video remains on the last frame before using
> the native widget.
> 
> about:support info:
>   Graphics
> 
>         Device ID
>         0x 126
> 
>         GPU Accelerated Windows
>         2/2 OpenGL
> 
>         Vendor ID
>         0x8086
> 
>         WebGL Renderer
>         ATI Technologies Inc. -- ATI Radeon HD 6750M OpenGL Engine
> 
>         AzureCanvasBackend
>         quartz
> 
>         AzureContentBackend
>         none
> 
>         AzureFallbackCanvasBackend
>         none
> 
> Opening another build of Nightly, the problem wasn't reproducible and I
> suspect this is because it was using the other graphics card (AMD Radeon HD
> 6750M): Device ID: 0x6741; Vendor ID: 0x1002 with the other about:support
> gfx details being the same.

Hey Matt, when you get a chance can you please verify this is fixed for you now on the latest nightly. Thank you !
Verified fixed with STR A and B using the same Device ID.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.