Closed Bug 356720 Opened 14 years ago Closed 13 years ago
Event processing stops during certain UI interactions
Page loading pause while you hold down mouse button on the scroll-bars. The same goes for animations on a fully loaded website. All animations, GIF, Flash, etc. pause when you hold down the mouse button. I reproduced this on the latest Camino trunk and CocoaFox (on www.vg.no ). ...and found the regression to happend all the way back in May! - Works: Gecko/20060510 Camino/1.2+ - Fails: Gecko/20060511 Camino/1.2+ Checkins between 2006-05-10 01:00 and 2006-05-11 01:00: http://tinyurl.com/ymjp9k By the way, I can't reproduce this with yesterdays Camino 1.8 branch build.
This is almost surely a regression from the thread manager landing (bug 326273), which is smack in the middle of that range.
I've noticed this as well. If anyone can find a regression range for when the check-in happened, that would be good. I would suspect Mark's event changes (some, but not all of them, were part of the thread manager landing).
This should probably just be duped to bug 338225.
Flags: blocking1.9? → blocking1.9+
Invoking a CM (in Camino) or opening a menu also stop all loading/animations.
Yeah, this is definitely caused by the new events system, from when we had to back out the stuff we did to get Gecko events firing inside native event loops. 338225 sounds right.
Duplicate of this bug: 391301
I'm in favor of duping this to bug 338225.
This bug was perhaps the only bug fixed by a patch I wrote a few months ago (not yet posted) that removed one level of nesting of native event loops (what I've been calling my "appshell patch" or "run loop patch", and which I emailed to you (Colin) shortly after I wrote it). I'm not sure it's possible (or even desirable) to remove all levels of nesting of native event loops. But it _does_ make sense to stop this nesting from causing problems with Gecko (which on one interpretation is the subject of bug 338225). So I've DUPed as Colin suggests ... but this is (of course) only tentative.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 338225
Will you also carry over the blocking1.9+ flag? I.e., will this appshell patch make it to Firefox 3?
My appshell patch would be superceded by a fix for bug 338225. But I'm not sure it'll be possible to fix bug 338225 before Firefox 3 is released. And my appshell patch is pretty simple and exists now. I'll try to open a bug on it next week. When I do so I'll request blocking1.9 on it.
Come to think of it, it makes more sense to make this bug depend on bug 338225.
Status: RESOLVED → REOPENED
Depends on: 338225
Resolution: DUPLICATE → ---
(Following up comment #10) It took me longer than expected, but I've now posted my appshell patch at bug 395397. It doesn't fix the problem reported in comment #0 (which in any case is no longer reproducible). But it does fix the following problems, all of which are related to the original report: Gecko event processing is suspended (on the trunk in both Minefield and Camino) while you do the following: 1) Resize a browser window using its "resize region" (in the lower right corner). 2) Keep one of the "main" menus open. 3) (Camino only) Keep a context menu open. (This happens only in Camino because only Camino uses "native" context menus.)
Changed the title of this bug to reflect the fact that holding the mouse down on a scrollbar is only one way of causing the same problem and stopping pageloads is only one symptom. Resizing the window, using the native menu bar, and holding the mouse down on certain UI elements are all ways of causing this bug. Symptoms include paused page loading and paused video/sound playback from plugins (think YouTube).
Summary: Page loading pause while holding down mouse on scrollbars → Event processing stops during certain UI interactions
I just landed my appshell patch (bug 395397), which fixes this bug.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.