Closed Bug 92170 Opened 23 years ago Closed 22 years ago

minimized windows will jump back up when focused

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: saari, Assigned: bryner)

References

Details

(Keywords: topembed+) 

I you start to load a bug page, and quickly minimize it, it will pop back up
when finished loading. A different form of window focus stealing.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.4
*** Bug 92392 has been marked as a duplicate of this bug. ***
After solving 77675 stealing focus continues, but I see a little bit different
behaviour: (on a very slow computer) when I Ctrl-click on more (3,4,...) links
on a page, new windows start openning...
1) if they are all open before they start stealing focus, I switch to the original
window and then only one of the new windows now steals focus...
[and this is only difference between 77675 as I see]
2) in other cases I tried to switch to the original window every time new window
becomes open and I can see stealing focus many times.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
I'm not seeing this anymore on my win2k build
->0.9.5
2001082909: I'm still seeing this (case 2)

seeing this on w2k build 2001091403 win32 installer sea

steps to reproduce:
1. control click on a link on this page like this one ( bug 92170 ) and quickly 
2. minimize it before it finish loading.

You will find that it pops back up when it  finish loading.
repro on linux nightlies for the last week or so...
Target Milestone: mozilla0.9.5 → mozilla0.9.6
A possible reason for someone not being able to reproduce it, is a really fast
connection. Otherwise, it's fairly easy: minimise the window BEFORE
"Transferring data from..." appears in the status bar.
Yes ! I am no longer seeing this, after bug 97067 was fixed.
I was wrong. Still reproducing it. Not as easy as before, but this bug is still
alive :(
Still reproducing it too (2001101103; Win)
But: Isn't it fixed with 97067? It is theoretically a duplicate
and 97067 is fixed in 0.9.5 branch


This bug seems to cover the following problem: a page starts loading and you
quickly minimize the window.  At some point during loading, it will deiconify
itself. 

This is a different issue than bug 77675 (which covers focus-stealing
during/after pageload, not deiconification), and bug 97067, which covers a
regression of the first bug.  bug 105225 is a continuation of 97067.

Should summary be changed to reflect this?  (I don't have access to do so)
My suggested changes:

-minimized windows will jump back up when focused
+minimized windows will de-minimize themselves during page load

(the "focused" part is what's confusing)
This bug was in 0.9.3, did not exist in 0.9.4, then came back in 0.9.5.
It still exists in the daily build from 20011012  (can't find the build number).
All of this is on Linux.

Easy way to reproduce: set a matching rule in sawfish (Class: ".*mozilla.*"
then check the 'iconify' box).  
Select File->New Navigator Window.  This window will open up iconified.
Open a link in a new window.  This window will open up uniconified.  You can
(rarely) see the window in an iconfied state in the taskbar before it pops up.

Final comments:
Because of what versions show this bug, it might have something to do with the
patches talked about in bug 97067.

No other mozilla windows other than browser windows seem to uniconify
themselves: Alerts, Preferences, and other popups stay iconified.  

I can't change the OS to 'All' either, but actually it's unclear whether people
are seeing the deminimization behavior on recent Win32 builds. 
Hello Mark,

I am still seeing this bug in Mozilla 2001-10-16-06 (pre-built Windows nightly).
I am using NT 4.0 (SP5). You can see this when loading a long /. page (w/ a lot
of comments) and iconifying the window ASAP. It will de-iconify after the page
loaded...

bye, daniel :(
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Nominating for 0.9.8. It slips from milestone to milestone but it still makes
triaging bugs a pain on Win32 (e.g. if you use to open multiple new windows from
a bug list and minimize them).
Keywords: mozilla0.9.8
(Win2k build 2002011604)
I don't know if this is the same problem.
If I have just one mozilla window open and no other windows and then minimize
the mozilla window, it will jump back in a restore state.
Reproducible each time.

It won't work if you have other windows open, because the focus will switch to
the next window after you minimize.
I am seeing this bounce-back-from-minimized symptom on Mozilla builds 20020118,
20020121, and 20020122 on WinNT4.  I have gone back to release 0.9.7 and do not
see it there.

It remains a problem ... more so for me since I used the tabbed interface and
generally have only one window with multiple tabs instead of multiple windows.

I have noted one other effect.  It appears that the "other window" doesn't
always need to be Mozilla's window.

1.  I had Mozilla open with 3 tabs.
2.  Mozilla wouldn't stay minimized
3.  I left it open and launched Outlook.
4.  I read a number of email messeges and composed and sent one reply.
5.  I closed Outlook.
6.  Mozilla now minimizes as it should have before.
 
I am puzzled, but maybe one of you coders can gleen some sense for this.
 
     Dale
 
On re-reading this bug, I think my report (#17) and the one preceding (#16)
actually represent another, newer, and different bug (Bug #120155).
 
Later ...

            Dale
Target Milestone: mozilla0.9.8 → mozilla0.9.9
I am no longer seeing this appear on trunk, and have reason to believe it might
be fixed from another focus fix that just went in.

If you still see it, make sure you're testing with the current trunk, and then
reopen with OS, machine speed, and the test case used. Thanks!
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Still happens for me on WinXP with 2002013003
Sorry for spam. It was ment to be posted for bug 120155 - to many tabs on
bugzilla at ones. Sorry!
*** Bug 135051 has been marked as a duplicate of this bug. ***
*** Bug 135544 has been marked as a duplicate of this bug. ***
QA Contact: madhur → rakeshmishra
This is appearing on the trunk build 2002-06-07-04-trunk on Windows 2000, speed
733 with the URL www.netscape.com.
Reopening the bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 149344 has been marked as a duplicate of this bug. ***
*** Bug 150675 has been marked as a duplicate of this bug. ***
*** Bug 151806 has been marked as a duplicate of this bug. ***
This also happens with the mail program as well.
Keywords: mozilla1.2
I still see this happening on Windows 2000, build 2002061104. If I open a link
from the mail/news client, then minimize the opened link, it will remaximize
itself when the page loads. 
Justin: That build is about two months old. Could you try a more recent build? 
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip
Since bug 151806 was resolved as duplicate of this bug, I tried to verify if the
behavior of this bug was still present in the latest trunk build.

I opened a tab, made a bugzilla query in it, minimized the tab, gave focus to
another tab and that window did not lose focus. I repeated again 5 times this
procedure and there never was a window focus lost.

I did the same procedure with 2 different windows (not tabs) and there never was
a window focus lost.

So, it appears to me that this bug has been fixed.

Windows XP Pro , Mozilla 1.1b build 2002082508 here.
QA Contact: rakeshmishra → trix
-> wfm
Target Milestone: mozilla0.9.9 → ---
nominating for topembed

Chris Saari--your reference number is 603921

see also:  bug 120155
Keywords: topembed
topembed+
->bryner

Not sure why this particular embeddor would be showing this behavior and others
wouldn't
Assignee: saari → bryner
Status: REOPENED → NEW
Keywords: topembed → topembed+
Re-closing as FIXED.  The embedding app in question was erroneously calling
nsWebBrowser::Activate().
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.