Closed Bug 15596 Opened 26 years ago Closed 26 years ago

[BLOCKER] Modal dialogs cannot accept input

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
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: 26 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.