Closed Bug 28467 Opened 25 years ago Closed 24 years ago

Windows switch z-order when running a URL

Categories

(SeaMonkey :: General, defect, P1)

Tracking

(Not tracked)

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: nsCatFoodnsCatFood+
*** 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 ago24 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 ago24 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: 24 years ago24 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.