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.
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).
blocking2.0: --- → ?
(In reply to comment #1) > Are those dialogs window-modal on windows, or app-modal? Window-modal.
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
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?
Note that the animation is kicked off in a setTimeout(..., 0) callback.
That should be ok too; that uses the same timers as the refresh driver.
Modal dialogs use a different event loop I think at nsXULWindow::ShowModal()
No, that's spinning the canonical main-thread event loop.
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)
(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.
This appears to be working now.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.