1142957 - Resuming OS X freezes a previously opened Firefox instance

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Tim Taubert [:ttaubert] (inactive)]

STR:

1) Open Firefox.
2) Close your MBP's lid and wait a few seconds.
3) Open the lid and try to use Firefox.

The problem here is that hovering tabs doesn't show animations and it doesn't respond to clicks. When switching desktops it sometimes does accept a user action.

Might be related to e10s, didn't try to disable it. Could reproduce it with an fx-team build and a clean profile. Might have happened yesterday for the first time.

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

This is on 10.10.2 by the way.

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Tim Taubert [:ttaubert] from comment #0)
> 2) Close your MBP's lid and wait a few seconds.

To clarify: I closed the lid and put my ear against the MBP to wait until the fan went off. Then after a few more seconds I re-opened it. Not sure if there's an easier way to reproduce but it doesn't seem too bad.

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

MozRegression yields:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=961205421a71&tochange=4f5c077c2831

Comment 4

[Nicolas Silva [:nical]]

Dupe of bug 1142708?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Upping severity, since this makes nightlies rather unusable....

> Dupe of bug 1142708?

Could be; symptoms sound similar...

Comment 7

[Boris Zbarsky [:bzbarsky]]

Though this one is definitely a vsync compositor regression, and has steps to reproduce, which is more data than bug 1142708 has.

Comment 9

[Mason Chang [Inactive] [:mchang]]

Attachment: Backout bug 1137905

In case it's urgent enough that we have to spin up a new nightly.

Comment 10

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I think I'm seeing this as well.  When Firefox is in this state, it seems to be working normally and responding to clicks, but it doesn't update the window contents (which makes it seem like it's not responding) unless I switch to/from another app — or maybe it needs to be an overlapping window? — whereupon it repaints once and then goes back to not.  10.10.2, “MacBook Pro (Retina, 15-inch, Mid 2014)” here.

Comment 11

[Mason Chang [Inactive] [:mchang]]

From irc conversations:

Seems to occur on at least 15" Macbook Pros. They have dynamic graphics switching. They are forced sleeped while with the power adapter plugged in. Not under heavy load, just having anything on nightly seems to cause it. Goes off and on.

Comment 12

[Mason Chang [Inactive] [:mchang]]

Attachment: djc about support

On the macbook pro intel gpu instead of the nvidia one

Comment 13

[Axel Hecht]

Attachment: about:support

Comment 14

[Tim Taubert [:ttaubert] (inactive)]

Attachment: ttaubert about:support

Comment 15

[Dave Townsend [:mossop]]

Attachment: mossop about:support

Comment 16

[Mason Chang [Inactive] [:mchang]]

Thanks! I was finally able to reproduce, but only on the Intel GPU. From Tim's and Axel's about:support, they are on the nvidia GPU. 

I also verified that on the intel and nvidia GPU on a separate non-firefox test program, the vsync callback is still going. My hunch is that we're not listening to the sleep notification and keeping vsync disabled for some reason.

Comment 17

[:Felipe Gomes (needinfo for replies!)]

fwiw, when I get this and I can make Firefox get back to working properly by opening a new FF window through the menu

Comment 18

[Mason Chang [Inactive] [:mchang]]

Fairly reliable STR:

1) Switch to Intel GPU instead of nvidia GPU
2) Have power adapter connected (can't repro w/o power adapter).
3) Have an opt build (debug builds don't repro)
4) No other external adapters
5) Load 2-3 tabs. I did bugzilla, the normal nightly new tab, and hacker news
6) Start scrolling everywhere
7) Close lid while a fling animation is still occuring
8) Wait 2 minutes, open lid

Comment 19

[Mason Chang [Inactive] [:mchang]]

Essentially, when we wake up from sleep, we fail to create the CVDisplayLink [1], which is our vsync notification. Since we have no vsync notifications, nothing gets rendered. I tried waiting for a wake notification [2] kIOMessageSystemHasPoweredOn before enabling vsync again, but the CVDisplayLink still fails to initialize. Still trying to find a workaround.

[1] https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPlatformMac.cpp?from=gfxPlatformMac.cpp&case=true#471
[2] https://developer.apple.com/library/mac/documentation/Kernel/Reference/IOMessage_header_reference/index.html#//apple_ref/doc/constant_group/Miscellaneous_Defines

Comment 20

[Mason Chang [Inactive] [:mchang]]

Attachment: Fallback to the CV Main Display if ActiveDisplays are not available

The problem is that when the mac comes back from sleep, there is some time between the laptop "ready" and when the displays are actually considered active. During this time, we tried to enable vsync, but failed due to no active displays available. Thus no vsync, no composites. 

In this case, we fallback creating a displaylink to the primary display, and we'll start vsync notifications when the main display comes back up.

Comment 21

[Markus Stange [:mstange]]

Comment on attachment 8577471 [details] [diff] [review]
Fallback to the CV Main Display if ActiveDisplays are not available

Review of attachment 8577471 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/thebes/gfxPlatformMac.cpp
@@ +476,5 @@
> +        // Active displays are those that are drawable.
> +        // In these cases, default back to the main display to try to get a vsync event.
> +        // The alternative would be to keep polling the CGActiveDisplayList for the displays to be ready.
> +        if (CVDisplayLinkCreateWithCGDisplay(CGMainDisplayID(), &mDisplayLink) != kCVReturnSuccess) {
> +          MOZ_CRASH("Could not create a CVDisplayLink with either active displays or the main display");

Okay, but please also file a bug about falling back to software vsync in this case, or in the other failure cases below.

Comment 22

[Mason Chang [Inactive] [:mchang]]

(In reply to Markus Stange [:mstange] from comment #21)
> Comment on attachment 8577471 [details] [diff] [review]
> Fallback to the CV Main Display if ActiveDisplays are not available
> 
> Review of attachment 8577471 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/thebes/gfxPlatformMac.cpp
> @@ +476,5 @@
> > +        // Active displays are those that are drawable.
> > +        // In these cases, default back to the main display to try to get a vsync event.
> > +        // The alternative would be to keep polling the CGActiveDisplayList for the displays to be ready.
> > +        if (CVDisplayLinkCreateWithCGDisplay(CGMainDisplayID(), &mDisplayLink) != kCVReturnSuccess) {
> > +          MOZ_CRASH("Could not create a CVDisplayLink with either active displays or the main display");
> 
> Okay, but please also file a bug about falling back to software vsync in
> this case, or in the other failure cases below.

See bug 1143189

Comment 23

[Mason Chang [Inactive] [:mchang]]

Will try to land this soon, but inbound is closed and the trees are closed tomorrow, so might not make today or tomorrow's nightly.

Comment 24

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8577471 [details] [diff] [review]
Fallback to the CV Main Display if ActiveDisplays are not available

Patch works great on my machine. Can still reproduce the original problem but can't to reproduce with the patch applied.

Comment 25

[Mason Chang [Inactive] [:mchang]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8545a7f27c8c

Comment 26

[Mason Chang [Inactive] [:mchang]]

Backed out for JIT test failures on 10.6 debug https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=8545a7f27c8c

https://hg.mozilla.org/integration/mozilla-inbound/rev/50c59dfbe392

Comment 28

[Mason Chang [Inactive] [:mchang]]

Re-landed https://hg.mozilla.org/integration/mozilla-inbound/rev/fa8dcfad6fee

The failures were due to a security-sensitive bug so it didn't show up in treeherder as a possible intermittent. Also verified that the JIT-tests use their own js shell without xpcom, which does not even execute the this code.

Comment 30

[Justin Dolske [:Dolske]]

(In reply to Mason Chang [:mchang] from comment #11)
> From irc conversations:
> 
> Seems to occur on at least 15" Macbook Pros. They have dynamic graphics
> switching. They are forced sleeped while with the power adapter plugged in.
> Not under heavy load, just having anything on nightly seems to cause it.
> Goes off and on.

FWIW (since this comment predates the patch)... 

The automatic graphics switching was causing kernel hangs for me, so I disabled it a few months back. But I was still experiencing this bug.

Comment 33

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/fa8dcfad6fee