Closed Bug 54936 Opened 20 years ago Closed 19 years ago

Dismissing a dialog confuses focus

Categories

(Core :: XUL, defect, P2)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: saari, Assigned: danm.moz)

References

(Blocks 1 open bug)

Details

(Keywords: access, platform-parity)

Attachments

(1 file)

Windows only, dismissing a dialog will confuse focus.

1) put curson in urlbar
2) bring up the open location dialog
3) dismiss dialog
4) try to type in the urlbar where the cursor is blinking. No text appears. You
have to click to get it to work again.

This is a side effect of some code danm added to work around a Windows only
dialog parenting issue. His code gives the OS windows focus before my focus code
fires, messing up the sequence slightly... when I fire focus afterward, the OS
doesn't send the appropriate messages because it thinks the window already has
focus.

I'm trying to work around this by bluring and then refocusing the window in this
specific case on Windows only, but it is messy.
Nominating for rtm because this annoys me.
Status: NEW → ASSIGNED
Keywords: rtm
rtm-/future, since this isn't as bad as the similar problem in the editor, and
the fix is non-trivial.
Whiteboard: [rtm-]
Target Milestone: --- → Future
Is this because bug 52829 was fixed incorrectly?
This is definitely Mozilla 0.9 
Priority: P3 → P2
Target Milestone: Future → mozilla0.9
*** Bug 56184 has been marked as a duplicate of this bug. ***
*** Bug 60231 has been marked as a duplicate of this bug. ***
*** Bug 63172 has been marked as a duplicate of this bug. ***
*** Bug 62511 has been marked as a duplicate of this bug. ***
*** Bug 62379 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
Keywords: access, correctness, pp
Blocks: 28520
I've seen this too. In Chatzilla, build 2000121904
wow, this is irritating.  nominating for beta1.
Keywords: rtmnsbeta1
Whiteboard: [rtm-]
This also applies to the wallet dialog followed by the security dialog. I'm used
to hitting Enter to dismiss the security dialog, but I can't do this after
dismissing the wallet dialog. Things get really tricky becuase for some reason
my dialogs are currently sizing to content before the content has finished
loading...
Very annoying, target mozilla 0.8
Target Milestone: mozilla0.9 → mozilla0.8
*** Bug 63801 has been marked as a duplicate of this bug. ***
*** Bug 64402 has been marked as a duplicate of this bug. ***
*** Bug 63959 has been marked as a duplicate of this bug. ***
Blocks: focusblink
I'm adding my comments from bug 64402 because it is another situation where this
bug occurs:

1. Type Ctrl-F to open "Find in page"
2. enter something which is *not* on that page,
3. confirm the Alert popping up by pressing enter,
4. notice that you can't type anything in the "find in page" dialog any more,
   (although the window decoration still suggests keyboard focus)
*** Bug 65183 has been marked as a duplicate of this bug. ***
this also sounds a WHOLE lot like bug #53579.  Saari, do you agree?  If so, i 
will dup it to this one.

anthonyd
IMHO, maybe the two bugs depend on each other, but I think they are about
something totally different and should be tested seperately after a fix.
Bug 53579 is about Javascript in forms, while I run into this bug all the time
when using "Find in page" or "Open Web Location".
*** Bug 66024 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.8 → mozilla0.9
->moz0.9
I really think the priority should be changed to P1 on this one as it blocks two
bugs, and it is very annoying. It is also a mostfreq.

You can no longer navigate natively with the keyboard w/o being forced to click
in certain places for the focus to be set.

Ugh.
*** Bug 67724 has been marked as a duplicate of this bug. ***
*** Bug 68027 has been marked as a duplicate of this bug. ***
*** Bug 67575 has been marked as a duplicate of this bug. ***
Please test this case when verifying this bug. Also note that this happens on
Linux whereas this bug and all the other duplicates seem to be Windows only.

From bug 67575:

If two browser windows are open, the "Find in this Page" dialog will only appear
the first time the "Search/Find in this Page" menu is selected or Ctrl+F is used.

To reproduce:
0) Start Mozilla.
1) Open a second browser window.  I used Ctrl-N.
2) Click in the body of the second window.  (This is very important.)
3) Press Ctrl+F or pick the "Search/Find in this Page" menu item.
4) Dismiss the dialog with Cancel.
5) Repeat step 3.  The Find dialog does not show.

Tested with Mozilla 2001020306 on Linux and the previous day's build on NT4.
*** Bug 69594 has been marked as a duplicate of this bug. ***
*** Bug 71294 has been marked as a duplicate of this bug. ***
*** Bug 71604 has been marked as a duplicate of this bug. ***
*** Bug 71604 has been marked as a duplicate of this bug. ***
Blocks: keydead
catfood
Keywords: nsCatFood
  This problem is caused by the fix for bug 22658. I'm attaching a patch that 
makes the 22658 patch less likely to fire. It makes that bug regress a little 
bit (for instance, any modal window (like prefs) that opens a filepicker window 
will suddenly have the 22658 problem again, but most situations are still 
covered (the stacked modal dialogs in Composer, for instance, don't regress)). 
But it makes this bug happen less often (the Open Web Location dialog, for 
instance, will no longer cause focus problems when dismissed).
  I think it's a good compromise for now, since we've been unable to come up 
with a bulletproof general solution.
Attached patch look upSplinter Review
r=saari as the best comprimise solution yet. Of course I still think we should 
let the windows come to front in the wrong order and let people yell at 
Microsoft instead. Think of it as a forcing function for keeping UI simple...
Is there a base of regression tests that can be run against a build with this
patch?  Could we bandaid the remaining problem areas somehow?
Keywords: nsCatFoodnsCatFood+
The best thing I can do is run my focus tests on this on all platforms. As for
the remaining problem areas, they're going to be problem areas (with either this
bug or the OS windowing bug) unless someone comes up with a way to fix focus to
not be broken by the work around (not likely since both danm and myself have
attemped various fixes several times).

I'm happy to keep looking for another solution, but I think it is probably a
black hole and I'd take this partial fix until either danm, myself, or someone
else has a whole bunch of free time to throw at this problem.
Danm, I'm giving you this bug since you have the best patch to date. Leave 
it open once checked in, but put it out past 0.9.
Assignee: saari → danm
Status: ASSIGNED → NEW
The patch is in. The basic problem still remains, but it'll happen under fewer 
circumstances. This particular rendition (open web location steals focus from URL 
bar) *is* fixed. I've gone through some of the dependent bugs; most if not all of 
them should be fixed now, too, if they were truly just this focus problem. Since 
technically this bug is fixed, I'm gonna close it. I've opened another (futured!) 
bug 74053 to find a real, general solution. Remaining problems should be added 
there as they arise.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 68929 has been marked as a duplicate of this bug. ***
This solves the Find in Page problem described here.  There's still a more
general problem with modal dialogs losing focus, but I think that goes back to
bug 10000 or something like that.
*** Bug 76861 has been marked as a duplicate of this bug. ***
*** Bug 85581 has been marked as a duplicate of this bug. ***
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
[im new at this - forgive me if i am missing something]

i have Build 2002030403 on Windows 2000 and this bug still exists - response to
any dialog window always shoves Mozilla to the background
Yes, this is back, but this time it's tracked by bug 122765. I will set this bug
back to RESOLVED/FIXED and anyone interested in this issue can go to bug 122765.
Status: REOPENED → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → FIXED
verified (as is the followup bug)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.