Closed
Bug 592395
Opened 14 years ago
Closed 14 years ago
Tab opened by click on URL in external app and modal dialog being open in Firefox makes tab animation delayed until modal dialog is closed
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: deleeuw+bugzilla, Unassigned)
References
(Blocks 1 open bug)
Details
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100831 Firefox/4.0b5pre Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100831 Firefox/4.0b5pre The summary says it all. Reproducible: Always Steps to Reproduce: 1. Open a modal dialog, for instance Options or Clear Recent History 2. Click a link in an IM window for instance 3. Observer the tab that results from that click Actual Results: Opens up like 2px. Expected Results: Fully opened tab.
Comment 1•14 years ago
|
||
Are those dialogs window-modal on windows, or app-modal? Clear Recent HIstory is app-modal on mac and I don't see the problem there... (but of course it could be windows-event-loop-specific).
Updated•14 years ago
|
blocking2.0: --- → ?
Reporter | ||
Comment 2•14 years ago
|
||
(In reply to comment #1) > Are those dialogs window-modal on windows, or app-modal? Window-modal.
Comment 3•14 years ago
|
||
Confirmed, but windows-specific. Roc, Neil - what are the odds that this is down to a layout glitch instead of a front-end one? The animation is handled with css transitions, hard to know where the bustage lives.
Status: UNCONFIRMED → NEW
blocking2.0: ? → betaN+
Ever confirmed: true
Comment 4•14 years ago
|
||
Yeah, ok. Window-modal on Mac uses sheets, so would be a totally different setup anyway. For the windows case... do modal dialogs use a nested event loop? I thought they used the main event loop, in which case things should Just Work. Kai, are you willing to test a try server build with some logging code to see what's going on?
Comment 5•14 years ago
|
||
Note that the animation is kicked off in a setTimeout(..., 0) callback.
Comment 6•14 years ago
|
||
That should be ok too; that uses the same timers as the refresh driver.
Comment 7•14 years ago
|
||
Modal dialogs use a different event loop I think at nsXULWindow::ShowModal()
Comment 8•14 years ago
|
||
No, that's spinning the canonical main-thread event loop.
Comment 9•14 years ago
|
||
For the record, setting the css attribute to kick off the animation directly instead of using the setTimeout fixes the problem. (though the animation skips most (if not all) frames, but that's regardless if the modal dialog is open or not)
Comment 10•14 years ago
|
||
(In reply to comment #9) > For the record, setting the css attribute to kick off the animation directly > instead of using the setTimeout fixes the problem. > (though the animation skips most (if not all) frames, but that's regardless if > the modal dialog is open or not) It wouldn't animate at all, which is why the setTimeout is there.
Comment 11•14 years ago
|
||
This appears to be working now.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•