1174540 - [OS X 10.6] Firefox appears to freeze for a few seconds after awakening laptop

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

On my OS X 10.6 laptop, I'm noticing that Firefox appears to freeze for a few seconds (~5-10 seconds) when I open my laptop after it sleeping. It still responds to keyboard input, but the main window doesn't repaint immediately. If hit cmd+l and tab to put focus in the search box I see a search suggestions popup which repaints fine but the text I enter into the search box doesn't show up until the "freeze" is over.

Disabling the refresh driver vsync pref fixes this issue, so almost certainly an issue related to that. Maybe the vsync doesn't start ticking for a while after I awaken my laptop? But only on pre-existing widgets (AFAIK the tooltip popups are a different widget).

Mason, I'm not sure if we care enough about 10.6 to investigate, but if you've heard reports on other platforms or if this might point to a root cause that has other side-effects we can look into it.

Comment 1

[Mason Chang [Inactive] [:mchang]]

Hmm this is interesting. Can you build a local debug build and see if you hit this assertion in your test case? [1]. Thanks!

[1] https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPlatformMac.cpp?from=gfxPlatformMac.cpp&case=true#590

Comment 2

[Kartikaya Gupta (email:[e-mail])]

I can't really do a build on that machine. I can probably run a debug build from tryserver though. Leaving ni until I have a chance to try it out. (Also if you want more logging feel free to do a 10.6 try build and I can run with that)

Comment 3

[Mason Chang [Inactive] [:mchang]]

Here's an initial try debug build - https://treeherder.mozilla.org/#/jobs?repo=try&revision=7b8b18759c73

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Attachment: Log from try build

Here's a log from the try build you posted. I created a "tmp" profile and then ran it like so:

./firefox -P tmp --new-instance 2>&1 | tee ~/tmp/vsync.log

As soon as I ran the command I cmd-tab'd over to the new instance, waited a second, and then closed my laptop lid. I waited until the laptop was asleep, then woke it up again (I think around line 471 in the log is where that happened). Then I opened a new tab and mashed the keyboard - as expected the new tab didn't paint but I got a popup from the URL bar painted. After some seconds stuff started painting again and the vsync output continued (line 611) and at that point I shut down the browser.

I also noticed that if I leave the browser in the background the vsync timer stops and then putting the laptop to sleep doesn't reproduce the problem. Similarly it doesn't happen if the browser is in the foreground and nothing is painting, since vsync goes idle. Most of the time however the cursor is blinking somewhere, and so the vsync timer is firing, and so putting the laptop to sleep in that state will reliably trigger the problem.

Comment 5

[Mason Chang [Inactive] [:mchang]]

Thanks for that information. I'm wondering if we're trying to enable vsync but it's already enabled somehow. Here's another build. Can you do the same thing as comment 4 again? Thanks!

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-e32ea32b661c/

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Attachment: Log from new try build

Around line 568 is where I woke it up on this one.

Comment 7

[Mason Chang [Inactive] [:mchang]]

Can you try this build? 

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f5e72a03bc86/

It disables vsync on a forced sleep. Otherwise it looks like it takes 25 seconds for the vsync callbacks to start again from sleep.

Comment 8

[Mason Chang [Inactive] [:mchang]]

On a side note, thanks for the log from comment 6. It points to bug 1171156, we can get a vsync timestamp 25 seconds in the past!

Next from now: 16.583871, prev from now: 0.024875, first vsync 0
Next from now: 1038.920839, prev from now: 0.112159, first vsync 0
Next from now: -25659.787137, prev from now: 25676.392074, first vsync 0
Next from now: 18.435231, prev from now: 25659.838642, first vsync 0
Next from now: 16.574667, prev from now: 0.030270, first vsync 0

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Attachment: Log from newer try build

Sorry for the delay. The observed behaviour is still pretty much the same on the new build - log attached.

Comment 10

[Mason Chang [Inactive] [:mchang]]

Thanks for trying! This one has a lot more logging:

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-7234381b0c15/

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Attachment: Log from newest try build

Comment 12

[Mason Chang [Inactive] [:mchang]]

Hmm, from the log it looks like there are no child refresh drivers to tick, so there are no vsync notifications sent to the child process, hence no painting. The parent process gets the vsync notifications, so that's probably why you can still type in the URL bar. Does this still happen with e10s disabled?

Comment 13

[Kartikaya Gupta (email:[e-mail])]

It doesn't appear to happen with e10s disabled. However, the freeze is also a lot less shorter now than it was before Whistler, using the same build that I was using before. I'm not sure what changed. It's only a second or two before it starts repainting now; before it was on the order of 10+ seconds.

Comment 14

[Mason Chang [Inactive] [:mchang]]

Thanks for running it... that's somewhat disturbing. I'd really like to see why the child process isn't ticking or subscribing to vsync notifications. Well I'll leave this open for a couple more days, but if it comes back, please let me know! Thanks!

Comment 15

[Mason Chang [Inactive] [:mchang]]

Since this isn't reproducible, and I can't find any new bugs reporting similar issues since Gecko 39 was released, resolving as WFM. Please reopen if the issue comes back.