I can confirm the described behaviour with the following build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050711 Firefox/1.0+ I'd like to see it fixed aswell, since I will also be doing some design mode stuff in the future.
Doesn't calling focus() on an iframe also raise the window the iframe is in? Certainly looking at nsGlobalWindow::Focus it looks like it might at least in some cases (eg for embedding apps). In any case, isn't a Firefox prefs bug.
To expand on what Boris said, if you turn off "allow scripts to raise or lower windows" in the prefs for Firefox 1.0.x, it has the same effect of setting the "dom.disable_window_flip" pref to true, which breaks the testcase here. The question then is whether it's possible to fix the behaviour with iframes while disallowing "window flipping". The arrangement of prefs is intentional - the "disable common annoyances" box breaks other features that are commonly used in pages, in particular I've seen a couple of pages which are broken by disabling switching images. Users will have to come to understand that. I believe something more sophisticated and site-specific is planned for a future (1.5? 2.0?) version of Firefox.
(In reply to comment #3) In my opinion the step from 1.0 to 1.1 was rather a step backwards than forwards by disabling to set more advanced options. I don't think that it is appropriate that I have to install an extension just because I want 5 of 6 "common annoyances" disabled and need the remaining one. As for site specific, +1 from me there, maybe even as an icon in the statusbar (like greasemonkey has).
Johnny, can you look into this?
We need to understand this before we ship. JST, when you get free, can you look at this?
Is this the same as bug 304746?
12 years ago
12 years ago
12 years ago
So the issue is that focusing an iframe _does_ raise the window. I suggest that the right fix for this bug is to turn this off (so focusing an iframe just focuses the iframe) and then to make the "window flip" pref not apply to focus() calls on iframes. Does that seem reasonable?
I agree with bz.
I could probably fix this using IsFrame() if I understood what each part of nsGlobalWindow::Focus did.
I believe the part that uses treeOwnerAsWin is what's raising the toplevel window while the part that uses presShell and focusController is what's moving the focus into the iframe.
But it's also possible that the SetFocus() call on the widget is what raises the window. Would need testing there...
(In reply to comment #12) > But it's also possible that the SetFocus() call on the widget is what raises the > window. Would need testing there... Indeed, the SetFocus(PR_TRUE) call on the widget is what raises the window to the top (if *a* firefox window is focused already), and it's also the call we need to get focus to actually move into a subframe.
So perhaps we should make it possible to focus a widget without raising the whole window...
It sounds like what we should be doing is: 1. Check the focus controller to see if the toplevel window has focus (IsActive) 2. If it does, call widget->SetFocus() and set aRaise = PR_FALSE if the disable_window_flip pref is set to true. 3. If the toplevel window doesn't have focus, then just set the focus controller's focusedWindow to the iframe being focused.
*** Bug 304746 has been marked as a duplicate of this bug. ***
*** Bug 305084 has been marked as a duplicate of this bug. ***
*** Bug 219049 has been marked as a duplicate of this bug. ***
*** Bug 118993 has been marked as a duplicate of this bug. ***
*** Bug 196922 has been marked as a duplicate of this bug. ***
Created attachment 197761 [details] [diff] [review] Fix (and also eliminate some duplicated code). This fixes this bug (first half of the diff), and also removes some duplicated code (the second half of the diff).
Comment on attachment 197761 [details] [diff] [review] Fix (and also eliminate some duplicated code). r=mrbkap
Re-nominating now that I've got a fix. This is actually very straight forward (we'd only need the first half of the patch for the branch). We could undo the backout of the change of the default value of the dom.disable_window_flip if we choose to take this.
Comment on attachment 197761 [details] [diff] [review] Fix (and also eliminate some duplicated code). let's take the patch and leave the pref alone for now.
Created attachment 198083 [details] [diff] [review] 1.8 version (same change w/o the extra cleanup).
Fixed on trunk and branch.