Event processing stops during certain UI interactions

RESOLVED FIXED in mozilla1.9beta1

Status

()

Core
Widget: Cocoa
--
major
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: krmathis@gmail.com, Assigned: smichaud)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla1.9beta1
PowerPC
Mac OS X
regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
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.
Blocks: 326273
Component: Widget: Mac → Widget: Cocoa
Flags: blocking1.9?
Keywords: regression
QA Contact: mac → cocoa

Comment 2

11 years ago
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.

Updated

11 years ago
Blocks: 357475

Comment 5

11 years ago
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.

Updated

11 years ago
Target Milestone: --- → mozilla1.9beta1

Updated

11 years ago
Assignee: joshmoz → smichaud

Updated

11 years ago
Target Milestone: mozilla1.9beta1 → mozilla1.9beta2
Duplicate of this bug: 391301
I'm in favor of duping this to bug 338225.
(Assignee)

Comment 8

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 338225

Comment 9

10 years ago
Will you also carry over the blocking1.9+ flag? I.e., will this appshell patch make it to Firefox 3?
(Assignee)

Comment 10

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

Comment 11

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

Updated

10 years ago
No longer blocks: 357475
(Assignee)

Updated

10 years ago
Depends on: 395397
(Assignee)

Comment 12

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

Comment 13

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

Comment 14

10 years ago
I just landed my appshell patch (bug 395397), which fixes this bug.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
Blocks: 381699
Depends on: 389931
No longer depends on: 338225
FWIW, in "Depends on", you may want to choose between bug 389931 and bug 395397.
You need to log in before you can comment on or make changes to this bug.