Closed
Bug 302424
Opened 19 years ago
Closed 19 years ago
dialog.xml doButtonCommand
Categories
(Toolkit :: UI Widgets, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dougt, Assigned: dougt)
Details
Attachments
(2 files)
|
1.17 KB,
patch
|
Details | Diff | Splinter Review | |
|
1.49 KB,
patch
|
mconnor
:
first-review+
benjamin
:
second-review+
benjamin
:
approval1.8b4+
|
Details | Diff | Splinter Review |
currently doButtonCommand uses a timeout to avoid closing the window during the oncommand event. this self described hack is busting me on Minimo. It seams that with this the way it is, the dialog never is closed. However, when I call _reallyDoButtonCommand directly from _doButtonCommand (avoiding the timeout), dialogs work. I have tested window.confirm(), window.alert(), and window.prompt() with the following patch on Minimo. This area of code hasn't changed since blakeros landed it on 13-Oct-02. I am not sure if this hack is still needed for all platforms, but it isn't for WindowCE. btw, i also tested window.setTimeout on Minimo and it works fine.
| Assignee | ||
Comment 1•19 years ago
|
||
| Assignee | ||
Updated•19 years ago
|
Attachment #190782 -
Flags: first-review?(mconners)
Updated•19 years ago
|
Attachment #190782 -
Flags: first-review?(mconners) → first-review?(mconnor)
| Assignee | ||
Comment 2•19 years ago
|
||
we may want to add WINCE to the #ifdef that XML can see. I am not sure how to do that. I tried s/MINIMO/WINCE in the patch, and that didn't work.
Comment 3•19 years ago
|
||
Comment on attachment 190782 [details] [diff] [review] patch v.1 I believe that this code formerly existed to prevent crashes related to the ordering of XBL constructors and JS scopes and such. If this actually works now, we should do it for all platforms.
| Assignee | ||
Comment 4•19 years ago
|
||
i tested window.confirm(), window.alert(), and window.prompt() on DeerPark Alpha 2 with a patch that removes this timeout and I am not seeing any problems. I have also played with some of the option dialogs and don't see any issues. Do we have any test cases?
| Assignee | ||
Comment 5•19 years ago
|
||
Comment 6•19 years ago
|
||
Comment on attachment 190788 [details] [diff] [review] patch v.2 -- removes timeout XP I can't find why this was done, it was three years ago and the world has changed since then. If it works and hasn't been used in seamonkey and they don't crash, it should be safe.
Attachment #190788 -
Flags: first-review+
| Assignee | ||
Updated•19 years ago
|
Attachment #190788 -
Flags: second-review?(benjamin)
Attachment #190782 -
Flags: first-review?(mconnor)
Comment 7•19 years ago
|
||
Comment on attachment 190788 [details] [diff] [review] patch v.2 -- removes timeout XP I'm interested in dbaron's opinion on whether we should take this for 1.8
Attachment #190788 -
Flags: second-review?(benjamin)
Attachment #190788 -
Flags: second-review+
Attachment #190788 -
Flags: approval1.8b4?
Comment on attachment 190788 [details] [diff] [review] patch v.2 -- removes timeout XP I don't have much of an opinion on this (and I'm not sure why you'd think I would), as long as it doesn't cause some nasty stack where we break some of the basic invariants in Gecko for which we don't have assertions (e.g., don't modify the content tree or frame tree in the middle of reflow or repaint).
Updated•19 years ago
|
Attachment #190788 -
Flags: approval1.8b4? → approval1.8b4+
| Assignee | ||
Comment 9•19 years ago
|
||
Checking in dialog.xml; /cvsroot/mozilla/toolkit/content/widgets/dialog.xml,v <-- dialog.xml new revision: 1.25; previous revision: 1.24 done
| Assignee | ||
Comment 10•19 years ago
|
||
marking fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•