[BLOCKER] Modal dialogs cannot accept input

VERIFIED FIXED in M10

Status

()

Core
XUL
P1
blocker
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Alec Flett, Assigned: Dan M)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
*** Bug 15466 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Assignee: trudelle → danm
Priority: P3 → P1
Target Milestone: M11

Comment 2

19 years ago
assigned to danm as p1 for M11. Please let us know if this fix is needed in M10.
(Reporter)

Comment 3

19 years ago
I don't think M10 is busted in this way, but this needs to be fixed today to
open the tree.
(Reporter)

Comment 4

19 years ago
*** Bug 15525 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Assignee: danm → pavlov
(Assignee)

Comment 5

19 years ago
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.

Updated

19 years ago
Target Milestone: M11 → M10

Comment 6

19 years ago
putting this on the m10 radar since pref diaglog testing show this problem
on the m10 branch.

Comment 7

19 years ago
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)

Comment 8

19 years ago
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.

Comment 9

19 years ago
Note to QA: when fixed, pls let mail QA know - we need to verify in our Account
Setup dialogs.
(Assignee)

Updated

19 years ago
Assignee: pavlov → danm
Whiteboard: investigating
(Assignee)

Comment 10

19 years ago
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...
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

19 years ago
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).
(Assignee)

Updated

19 years ago
Whiteboard: investigating
(Assignee)

Comment 12

19 years ago
*** Bug 15461 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

19 years ago
*** Bug 15461 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 14

19 years ago
marking verified with the 1999100608 build
(Assignee)

Comment 15

19 years ago
*** 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.