Closed Bug 28467 Opened 25 years ago Closed 23 years ago

Windows switch z-order when running a URL

Categories

(SeaMonkey :: General, defect, P1)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 77675

People

(Reporter: phil, Assigned: hyatt)

References

Details

Running 2000-02-18-08 on Windows NT4 1. Open a browser window and a mail window 2. Process a bugzilla bug in the browser window, clicking "Commit" when done 3. Quickly click on the mail window before the bugzilla commit is done (should be easy :-) 4. Notice that the mail window comes to the front, and then the browser window jumps back on top of it. Expected the browser window to stay behind the mail window after bringing the mail widnow forward.
*** Bug 28471 has been marked as a duplicate of this bug. ***
Nominate for beta1. Sorry 'bout the dup. Bugzilla stopped loading the post and then it didn't show up in a query so I refiled it. Too smart by half :-)
Keywords: beta1
investigating....
Status: NEW → ASSIGNED
Target Milestone: M14
I thought this was going to be a uri loader problem where we were setting the focus incorrectly but it turns out that isn't the case. the uri loader is still working just fine. I've emailed the hook for help tracking this down. It's caused by the following code in nsPresShell's CheckForFocus: nsCOMPtr<nsIDOMWindow> domWindow = do_QueryInterface(ourWindow); if (domWindow == focusedWindow) { // We need to restore focus and make sure we null // out the focused element. commandDispatcher->SetFocusedElement(nsnull); domWindow->Focus(); } When we call domWindow->Focus() that's when our focus problem happens and the window running the url jumps to the front. This code hasn't changed recently so it must be triggered by something else. I'm wondering if the command dispatcher (which sets focusedWindow) is returning the wrong window.
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
I'm pretty sure we said PDT- in the meeting
Whiteboard: [PDT+] → [PDT-]
I'm saddened to see this get PDT- =(. Especially since it was such a recent regression after the tree closed. Anyway, in an email to the hook saari said he and hyatt knew how to fix the problem. Re-assigning.
Assignee: mscott → saari
Status: ASSIGNED → NEW
Scott, or anyone else, renominate if you want.
I would probably only re-nominate it if Saari felt the fix was quick and/or simple. I know we are trying to buckle down on cutting PDT bugs. Chris?
This is a pretty easy and safe fix to make.
Asking that this be reconsidered. It's easy to fix.
Whiteboard: [PDT-] → [PDT]
I have the fix on my NT box. Needs other platform testing and review.
Status: NEW → ASSIGNED
Whiteboard: [PDT] → [PDT+]
Well, I was about to checkin but I've found something blocking me... modal dialogs on NT don't bring the correct window to front when they close, and this interacts with my fix when you use the open location dialog. You type in a url, hit enter, and it brings the console window to front. Danm is going to try and hack this to do something better.
Whiteboard: [PDT+] → [PDT+] 2/24
> modal dialogs on NT don't bring the correct window to front when they close Yah, that drives me crazy. Would be nice to fix that if possible.
Grr this bug has lots of edge cases that I'm finding and dealing with
Whiteboard: [PDT+] 2/24 → [PDT+] 2/25
Fixed. Will still happen when a text field gets focus from onload, but 4.x does the same thing. That can't be fixed until after beta, if we even want to fix it.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Sending over to shrir to verify for me since he has NT.
QA Contact: asadotzler → shrir
verified (2000022808m15)
Status: RESOLVED → VERIFIED
*** Bug 30400 has been marked as a duplicate of this bug. ***
*** Bug 30567 has been marked as a duplicate of this bug. ***
*** Bug 30640 has been marked as a duplicate of this bug. ***
*** Bug 31209 has been marked as a duplicate of this bug. ***
*** Bug 33117 has been marked as a duplicate of this bug. ***
*** Bug 33117 has been marked as a duplicate of this bug. ***
This bug occurs on Trunk Build 2000101108 on linux. steps to reproduce: (well... it's copied from Asa's commment on Bug 30400) 1. click on a link, bookmark or type the URL into the address bar and hit enter. 2. Quickly switch to another application or another browser window. 3. Watch the browser window that was loading take back focus and return to front when the page finishes loading.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Saari said today that he can kill this behaviour, but he thinks that some piece of the DOM specification requires us to raise the window whenever anything within it is .focus()ed. I've never heard of such a thing, but I thought I'd add some DOM heads to be sure; I'd really like this to die, and there are many others like me (in this regard, anyway).
clearing status, setting p1 as this annoying a lot of people
Keywords: beta1
Priority: P3 → P1
Whiteboard: [PDT+] 2/25
Target Milestone: M14 → Future
Targeting Mozilla 0.9
Target Milestone: Future → mozilla0.9
*** Bug 59131 has been marked as a duplicate of this bug. ***
*** Bug 61199 has been marked as a duplicate of this bug. ***
Killing this behavior might be harder than I previously thought. I hacked it so it stopped bringing the window to front, but it confused the focus tracking code when the widget was not in focus but the text area conceptually was. Also, I need a way of testing when the widget should get focus, and the activate/deactivate/blur/focus event sequence isn't set up to make that easy right now, I may need another event such as NS_PRE_ACTIVATE. Gross. Another option is to move the widget focusing check out of ESM::SendFocusBlur and to the DOMWindow level. That is a scary change to say the least. Have to think about this some more.
*** Bug 55691 has been marked as a duplicate of this bug. ***
*** Bug 62740 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
>10 dups. Adding mostfreq keyword.
Platform/OS -> All/All
OS: Windows NT → All
Hardware: PC → All
*** Bug 63338 has been marked as a duplicate of this bug. ***
Targeting mozilla 0.8 due to annoyance factor
Target Milestone: mozilla0.9 → mozilla0.8
Worse than annoyance. I tend to do the following a lot: 1. Load mozilla 2. Click in the navigation toolbar 3. Press Ctrl+W to erase everything 4. Type some URL 5. Ctrl+N 6. Do steps 2-4 again And the first window *always* steal focus exactly before I type Ctrl+W (I must have really bad timing). The result is that the first window is killed (since the focus is not in a text field anymore). Is there a "mostannoying" keyword for bugs like that? Voting is not enough, 5 votes is too few for the 6-8 bugs that tend to be the what I consider the top ones. Deciding which is worse is hard.
He said already, he will work on it.
I want this behavior to be preferenced rather than killed. It is a useful feature in some cases. However, I want to prohibit any window from hiding the dialog windows that require user input. That was the point of bug 62740
*** Bug 63984 has been marked as a duplicate of this bug. ***
->moz0.9
Target Milestone: mozilla0.8 → mozilla0.9
FYI: A detail that is especially annoying: The widnows comes to thefront, but doesn't get focus. With my windows manager (sawfish, default for Redhat), this means that I have to click on the window title to bring the previous window back - a click in the content area is not sufficient. Also, Alt-Tab doesn't work as expected, IIRC, because of that.
*** Bug 66769 has been marked as a duplicate of this bug. ***
really annoying, in other words: it makes me sick. i had to switch from blackbox to icewm again, just because i can't handle mozilla without a taskbar anymore... everytime a large page is loading, i switch to something else, mostly editing stuff. everytime the mozilla window comes to the front, my editor window is hidden and i have to use something like the taskbar to get it back. stuff like this should NEVER happen, especially not when triggered by some untrusted javascript code. there should be a strict rule, that windows can only focus another window, if they currently own the focus. that would be neat. :) not even important popups should interrupt my work (unless they are telling me that my house is burning) =) sorry for so much text, i'm not used to write _short_ comments. :-/ would be glad to see this fixed soon, definetly my number one bug.
Small but important question: how should Mozilla inform you as Mozilla user that a previous load is ready, other then changing the z-order, with a small dialog window/message? And if this is going to be implemented ever, I would love to have a preference setting for this behavior! I don't like it but sometimes I *need* this feature to inform me that Mozilla is ready! But remember, if you do implement this feature, it will introduce new issues, that's for sure! Don't forget, if you have set Cookies and Images loading to block selectively, you still have to confirm to them. What about that kind of notifications? Should they also stay on the background?
Yes, i think that even those notifications shouldn't disturb me until i give the program the permission to do so. An option would be neat, but until this is implemented i would rather have mozilla never switching to the top. Of course this is just my personal taste. About notification: What about a beep signal? And/or a system tray icon. Of course system tray is not easy to implement in unix... :-/
> how should Mozilla inform you as Mozilla user that a previous load is ready, > other then changing the z-order See the NetCaptor browser for one example of UI which achieves that. We should definitely not change the z-order to indicate page load progress.
Re Shaver's comment from a while ago: >Saari said today that he can kill this behaviour, but he thinks that some piece >of the DOM specification requires us to raise the window whenever anything >within it is .focus()ed. I'm not sure what the specs say, but IMO you should have to explicitly focus the window if you actually intend to steal focus from another window. Currently, many search webpages use textbox.focus(), and have no way to get the same functionality without annoying multi-window users (bug 41813, bug 50665). I also noticed that window.focus() focuses the OS-level window (from other Mozilla windows) and also focuses the document frame/content area. It might be good to keep this behavior for backward compatibility, but it should be possible to just do one of those things at a time. Perhaps an extra function could be added to grab focus from other parts of the OS-level window, and perhaps another extra function that brings a window to the front and focuses it. (Possible names: window.focusContent() and window.focusOSWindow(), with window.focus() printing a warning on the JavaScript console.)
No. Please don't switch focus, at least not on the OS-level.
Bug 68608 is a similar (less obvious) problem.
*** Bug 68806 has been marked as a duplicate of this bug. ***
*** Bug 68608 has been marked as a duplicate of this bug. ***
Bug 68608 is a new (annoying) variation of this bug.
nominating for dogfood and nsbeta1... ****PLEASE**** fix this very annoying bug!
Keywords: dogfood, nsbeta1
*** Bug 69276 has been marked as a duplicate of this bug. ***
Adam Stiles must have taken a very close look at Opera, because NetCaptor works pretty much the same as Opera. One general browser window, with new windows starting inside the general browser window. Only Adam uses tab's but at the end still the same as Opera. You can simply click on one of them, and you don't get disturbed at all, I like that.
*** Bug 62740 has been marked as a duplicate of this bug. ***
Is this now a specific bug for keeping the modal dialog in front of browser windows?(bug 62740) Upon reading recent comments, it does not seem to have been decided what is being dealt here. IMHO, browser windows should be able to change position when it is refreshed, and this should be preferenced. However, no browser window or Mail/News window be allowed to hide a modal dialog window. These two shoule be separately treated.
*** Bug 69658 has been marked as a duplicate of this bug. ***
I don't think bug #30400 is a duplicate of this one. Please see my comments about #30400, and attachment id 26362.
*** Bug 41813 has been marked as a duplicate of this bug. ***
*** Bug 50665 has been marked as a duplicate of this bug. ***
*** Bug 60122 has been marked as a duplicate of this bug. ***
Sorry for the spam, just adding to CC list
Blocks: 59543
*** Bug 50473 has been marked as a duplicate of this bug. ***
This bug seems to be fixed now.
Seems fixed to me (2001-03-19 Win95.) Can everyone who complained about this bug retest? If we see no further comments, this bug will be fixed WORKSFORME. Gerv
It appears to work for me (Build 2001031910 Linux).
This is not fixed for me on Linux on a trunk CVS build pulled and made today. (Environment: RH 6.2, x86, fvwm2 window manager, sloppy focus mode.)
I can no longer reproduce this on demand with 2001031904 on NT, but it's still happening from time to time. It's not nearly as common as it was in the past.
Mozilla Solaris build 2001032021 still cheerfully horns its way to the front of the window stack during a page load. Insecure little beast, hmm?
I'm still getting this in Solaris - 2001032110. If fact the problem is much worse than in 0.8. In 0.8 the windows would just pop to the front when loaded. In 2001032110 I get this, plus occasional "fights" for focus, plus I can no longer iconify a window with the mouse as it regrabs focus & reopens itself! I can, however, iconify with the keyboard. Shame, as this build has a working PSM... ;-)
Aye, the windows duelling for Z-supremacy mishap is back with a vegance in the last nightly build after a day or two of peace. Did a fix accidentally get reverted? Solaris, build id: 2001031821.
Ehh, I think I've solved it; there haven't been any nightly Solaris builds since 2001-03-19. Or, it seems, for many other platforms either. I should pay more attention.
No Z-order switching occurring for me - Linux build 2001031408
I still see this problem in Linux build 2001032019. Unlike before, this time it's random. Reloading a page over and over sometimes brings it to the top and sometimes does not (I'm using KDE with sloppy focus).
In my 2001-02-08 14:25 comment, I pointed out that window.focus() currently does two things: 1. bring this window to the front and focus it 2. focus this frame, away from other parts of the window. Bug 9086, bug 50223, and bug 24423 suggest that (2) is itself two separate actions: 2a. focus this frame or an element in this frame, away from other frames or from the location bar 2b. focus this frame, away from elements within the frame Chances are distinctions between (1), (2a), and (2b) already exist for trusted js or c++ code, but afaict page javascript is stuck with window.focus() doing all three things.
Oops, that's true in IE but not in Mozilla. In Mozilla, window.focus() is only (1) and (2a). That might mean page javascript can't do (2b) at all in Mozilla.
catfood
Keywords: nsCatFood
Keywords: nsCatFood → nsCatFood+
*** Bug 69620 has been marked as a duplicate of this bug. ***
->hyatt, cc saari
Assignee: saari → hyatt
Status: REOPENED → NEW
I have no idea what this bug is referring to. Am I simply trying to fix the original mailnews vs. browser problem outlined in the bug report, or is this bug some sort of general "fix every last random z-ordering problem in the product" bug? If so, that's ridiculous, and separate bugs should be filed for all reproducible individual problems.
Status: NEW → ASSIGNED
Please look at the original problem, if it still exists; don't let the bug report morph. Any other problems should be reported separately.
Stop navigator.js from focusing the page on end load notification. Only focus if the window is currently active. Trick is making focus memory work when the page does become active again. And I'm intentionally tossing all the same cases into one bug since I don't want to deal with 50 different bugs.
It would be a good idea to attract the attention of the user in another way instead of focusing the window when the page loads. On Win32 we should use FlashWindowEx WIN32 function to make the taskbar button flash... On X11 this can be done by setting the UrgencyHint (perhaps it will actually be implemented usefully somewhere). I'm not sure what can be done in MacOS. This would emulate the behavior of IE. Perhaps a new RFE bug should be filed on this.
Reading the documentation on the following Win32 function is also interesting (can be done at http://msdn.microsoft.com/ ): SetForegroundWindow, LockSetForegroundWindow, SetActiveWindow, AllowSetForegroundWindow, ... Windows seems to have a lot of features to prevent the focus being stolen from the user and the way mozilla is implemented is unfortunatelly disabling all that. Basically, the mozilla top level windows (components - Navigator, Bookmarks window, MailNews, Composer, History window, ...) should behave like they are separate processes as described in the documentation of the above mentioned functions). On X11 it would depend on the window manager, but some extensions to common wm protocols would be needed to get the behavior that is possible on windows.
macos ideas?
On Mac OS the correct thing is to use the Notification Manager APIs. On Mac OS 9 its extremely rare if not impossible for an application to jump to the front after you put it in the background. When you call the Notification Manager it flashes the apps icon in the menubar until the user chooses it. This is how 4.x does new mail notifications too. In extreme cases a modeless dialog comes up saying "XXXXX requires your attention, please bring it to the front". I was reading some post to one of Apple's interface mailing lists which said the Notification Manager isn't fully supported on Mac OS X yet, but it *is* planned for a future release.
The need for Mac OS notification of Mozilla alerts (either by flashing the icon in the menubar or some other method) is covered in bug 53345.
Why would we want a focus() to alert the user in this way? No other browser does this, and if Mozilla starts blinking icons in my menu bar every time I load a page, I'm going to throw it in the trash.
we're off topic here. really the bug is about calling focus() in a background window bringing that window to the front. On win32, both 4.x and IE do this and is relied upon by web applications and xul. I don't think we can fix this very easily, if at all.
Bug 50665 and bug 41813 deal with textbox.focus() in a web page. This one originally said nothing about .focus(), and the bulk of the focus-stealing problems seem to occur on pages without any .focus() calls.
There should be *no* notification when a page finishes loading. Unless it's a JS popup, the user had to manually open that window and I'm sure they'll get around to looking at it when they feel like it. Notifications (at least on Mac OS) are only for application alerts or any activity that absolutely requires the user's attention. I would also reserve a spot in the trash for my copy of Mozilla if it's icon flases in the menubar every time a page finishes loading. The only difference (that I can tell) between the original report and current behavior is that *all* windows behave this way. No normal window should switch Z-order under normal circumstances. The user is the best person to decide what order they want their windows to be in, and they can best decide what window they want to be active. This should also be separate from deciding what to do when some DOM or JS code that a user loads wants to steal focus.
Blocks: 75643
I am duping this on 41813. That is what causes the mailnews symptom originally reported. *** This bug has been marked as a duplicate of 41813 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
Still broken (FizzillaCFM 2001-04-18). Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
unsetting target milestone ofr reopened bug that probably won't be fixed for 0.9
Target Milestone: mozilla0.9 → ---
This behaviour, as described by Phil at the start of the report, is still present in nightly build 20010423. The z-order "duelling" is still fixed.
Why not reopen bug 41813?
There comes a point where a bug report has become overloaded to cover too many platforms, edge cases and variations that there is (a) no way to get agreement on whether the bug is "fixed", and (b) no way for an engineer to comprehend exactly what they are supposed to "fix". For example, this bug. If there is a specific problem with a Fizzilla build, then please file that as a separate bug report (should go to pinkerton). As for the originally reported problem, testing with a 4/21 and 4/25 build on NT5 (aka win2k), I cannot reproduce this problem. So ... worksforme. If you disagree, then file a bug that specifically describes the problem you are seeing (even if just repeats the original steps to reproduce for this bug). Reopening this bug will not be the most direct route to getting <insert_description> fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
OK, as per jrgm's comment, I've filed 77675 on the problem I'm seeing on NT4 with 2001042108
*** Bug 73025 has been marked as a duplicate of this bug. ***
resolving duplicate
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** This bug has been marked as a duplicate of 77675 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Bit unsporting to mark a well-commented, well-voted well-dep-tree'd *earlier* bug a dup of a later one, if you ask me.
verifying. <postscript> this bug was fixed 2000-02-25 17:04:08. People have moved CC's and votes over and can do so if they're interested. See also Additional Comments From John Morrison 2001-04-25 14:33.
Status: RESOLVED → VERIFIED
> <postscript> this bug was fixed 2000-02-25 17:04:08. That has not been my experience. This bug (as originally reported) reproduces easily on Windows NT using the 5/24 build. Maybe the bug is a dup, but it is not fixed.
This bug and also 77675, 97067 bugs were closed, but problems described here continues! So I have filled new bug 105225 describing this problem. This CLOSED bug still has 10 votes! Please all, move your votes from this to bug 105225.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.