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.
Assignee: nobody → mchang
Status: NEW → ASSIGNED
See Also: → bug 1171156
Hmm this is interesting. Can you build a local debug build and see if you hit this assertion in your test case? . Thanks!  https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPlatformMac.cpp?from=gfxPlatformMac.cpp&case=true#590
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)
Here's an initial try debug build - https://treeherder.mozilla.org/#/jobs?repo=try&revision=7b8b18759c73
Created attachment 8622831 [details] 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.
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://email@example.com/
Created attachment 8623439 [details] Log from new try build Around line 568 is where I woke it up on this one.
Can you try this build? https://firstname.lastname@example.org/ It disables vsync on a forced sleep. Otherwise it looks like it takes 25 seconds for the vsync callbacks to start again from sleep.
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
Created attachment 8624559 [details] Log from newer try build Sorry for the delay. The observed behaviour is still pretty much the same on the new build - log attached.
Attachment #8624559 - Attachment mime type: text/x-log → text/plain
Thanks for trying! This one has a lot more logging: https://email@example.com/
Attachment #8625010 - Attachment mime type: text/x-log → text/plain
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?
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.
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!
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.