Resuming OS X freezes a previously opened Firefox instance

RESOLVED FIXED in Firefox 39

Status

()

Core
Graphics
--
blocker
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: ttaubert, Assigned: mchang)

Tracking

({regression, reproducible})

Trunk
mozilla39
x86_64
Mac OS X
regression, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox39 fixed)

Details

(Whiteboard: [gfx-noted])

Attachments

(6 attachments)

(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
This is on 10.10.2 by the way.
(Reporter)

Comment 2

3 years ago
(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.
(Reporter)

Updated

3 years ago
Component: General → Graphics
Dupe of bug 1142708?
Whiteboard: [gfx-noted]
Upping severity, since this makes nightlies rather unusable....

> Dupe of bug 1142708?

Could be; symptoms sound similar...
Severity: normal → blocker
Though this one is definitely a vsync compositor regression, and has steps to reproduce, which is more data than bug 1142708 has.
Blocks: 1142708
Flags: needinfo?(mchang)
(Assignee)

Updated

3 years ago
Assignee: nobody → mchang
Status: NEW → ASSIGNED
Flags: needinfo?(mchang)
(Assignee)

Comment 9

3 years ago
Created attachment 8577255 [details] [diff] [review]
Backout bug 1137905

In case it's urgent enough that we have to spin up a new nightly.
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.
(Assignee)

Comment 11

3 years ago
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.
(Assignee)

Comment 12

3 years ago
Created attachment 8577281 [details]
djc about support

On the macbook pro intel gpu instead of the nvidia one

Comment 13

3 years ago
Created attachment 8577285 [details]
about:support
(Reporter)

Comment 14

3 years ago
Created attachment 8577288 [details]
ttaubert about:support
Created attachment 8577289 [details]
mossop about:support
(Assignee)

Comment 16

3 years ago
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.
fwiw, when I get this and I can make Firefox get back to working properly by opening a new FF window through the menu
(Assignee)

Comment 18

3 years ago
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
(Assignee)

Comment 19

3 years ago
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
(Assignee)

Comment 20

3 years ago
Created attachment 8577471 [details] [diff] [review]
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.
Attachment #8577471 - Flags: review?(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.
Attachment #8577471 - Flags: review?(mstange) → review+
(Assignee)

Updated

3 years ago
Blocks: 1143189
(Assignee)

Comment 22

3 years ago
(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
(Assignee)

Comment 23

3 years ago
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.
(Reporter)

Comment 24

3 years ago
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.
(Assignee)

Updated

3 years ago
Duplicate of this bug: 1142708
(Assignee)

Comment 28

3 years ago
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.
Duplicate of this bug: 1143400
(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.
Duplicate of this bug: 1143779
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1144050
https://hg.mozilla.org/mozilla-central/rev/fa8dcfad6fee
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1144304
Depends on: 1144638
You need to log in before you can comment on or make changes to this bug.