Closed Bug 15596 Opened 21 years ago Closed 21 years ago

[BLOCKER] Modal dialogs cannot accept input

Categories

(Core :: XUL, defect, P1)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: alecf, Assigned: danm.moz)

References

Details

I'm guessing there is already a bug open, but I'm filing one to be sure.

On Windows and Linux, modal dialogs cannot accept any input, widgets cannot get
focus, etc.

This prevents large portions of our UI from being useable. You can't even press
ok/cancel to close any dialog windows.
*** Bug 15466 has been marked as a duplicate of this bug. ***
Assignee: trudelle → danm
Priority: P3 → P1
Target Milestone: M11
assigned to danm as p1 for M11. Please let us know if this fix is needed in M10.
I don't think M10 is busted in this way, but this needs to be fixed today to
open the tree.
*** Bug 15525 has been marked as a duplicate of this bug. ***
Assignee: danm → pavlov
It's not just modal dialogs -- nonmodal ones can be (but aren't always) broken, too.  And it's not just Linux.
Windows is broken as well.  My Mac build is still cranking, so that one I can't speak about yet.

This problem is caused by mousedown events being eaten.  It seems timer-related: whaling on the Cancel button
in the Open Web Location Dialog eventually gets its attention.  Even better, the problem can be made to
seem to go away by commenting out code added on 30 Sep by rods in windows/nsWindow.cpp which
returns early from event handling under some situations, and similar code added 27 Sep to gtk/nsWidget.cpp
by pavlov.  (That's lines 476-480 in nsWindow.cpp, rev 3.206 and line 1720 in nsWidget.cpp, rev 1.150.)

I can't tell that deleting this code does anything harmful.  Also, note this problem appeared after 27 Sep
(didn't it?) so this is probably not the actual source of the problem.  Still, I'm passing this bug on to pavlov
and cc:ing rods.
Target Milestone: M11 → M10
putting this on the m10 radar since pref diaglog testing show this problem
on the m10 branch.
fyi, danm hinted at a helpful workaround. The buttons (ok, cancel) will
fire if you 'click hard' or basically double-triple click on them. Hopefully,
this will keep folks from getting stuck w a bunch of dialogs open. And yes
m10 candidates suffer from the same woes (not Mac)
No, that doesn't help. Users are not motivated to find such hidden workarounds,
or even use them. I've found that keystroke access will sometimes work too, but
if you click on a button and it doesn't respond, it just flipped the bozo bit,
and deserves a three-finger salute.
Note to QA: when fixed, pls let mail QA know - we need to verify in our Account
Setup dialogs.
Assignee: pavlov → danm
Whiteboard: investigating
More news on this bug.  I'm taking it back for now.  The event dispatching code I vilified above
isn't actually the problem.  The problem is event capture in XP menus is never released.  It looks like
a dialog problem because most of our dialogs are summoned by menus.  Investigating...
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Alright, it *was* just a modal dialog problem.  Anyway, it was fixed by returning to normal
event processing by releasing the menu rollup listener earlier during menu execution (before
the modal window is opened).
Whiteboard: investigating
*** Bug 15461 has been marked as a duplicate of this bug. ***
*** Bug 15461 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
marking verified with the 1999100608 build
*** Bug 15410 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.