Closed Bug 163372 Opened 22 years ago Closed 21 years ago

Pressing the minimize button, results in the window being restored

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 207639

People

(Reporter: tironsi, Assigned: emaijala+moz)

References

Details

Attachments

(1 file)

Patch to make tabbrowser set the focus immediately
682 bytes, patch
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Win98SE; en-US; rv:1.1b; Tru Moz) Gecko/20020807 Build Identifier: Mozilla/5.0 (Windows; U; Win98SE; en-US; rv:1.1b; Tru Moz) Gecko/20020815 I thought that this was the same as Bug 120155, but I was told to file a new bug as that one was fixed. This happens to me from time to time and I have not been able to reproduce it. If I press the minimize button while having a mximized view, the browser first minimizes (i.e. dissapears momentarily from view) and then restores (i.e. becomes a smaller window). I believe this also happens if pressing Winkey+M. If this is a dupe of yet another bug, I have not been able to find it. Reproducible: Couldn't Reproduce Steps to Reproduce: NA
Same behaviour occured under XP, as described above; Winkey+M didn't trigger the same problem though (all windows became and remained minimized). Apart from that, if all other windows were already minimized, then Mozilla was minimized (having been normal or maximized prior to minimizing), then Mozilla would minimize then restore. This was with 3 tabs open, and having used the autocomplete feature during that session. Before this bug became apparent, the Mozilla window hadn't been minimized successfully while no other windows were open during that session. In addition to this; during this same session, if Mozilla was minimized while other windows retained focus, it would stay minimized /until/ all other windows were minimized/closed - then Mozilla restored itself. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
WFM - trunk build 2002082004 - WinXP.
As this is a spinoff of Bug 120155, marking the same component and assignee as that bug, so that this will get the proper attention.
Assignee: Matti → danm
URL: NA
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Toolkit/Widgets
Ever confirmed: true
QA Contact: asa → jrgm
*You may want this bug to block bug 140346, like related bug 142183 does (and bug 142184 should). [Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212] I had bug 120155 (minimize allways restoring) which was fixed. Since then, I have seen bug 163372: it happens rarely, and I don't know (yet) how to reproduce it. I suggest to change the Severity from 'Normal' to 'Minor', as the obvious workaround is to minimize the window again.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212] I found a minimal and 100% reproductible test case :-) 0a. Set Mozilla to display a Home Page at startup, and set its Location to <about:> (for example). (This test case is useless when the setting is "Blank page" at startup.) 0b. Maximize the Browser window (to help at 1b step), then close Mozilla. 1a. (re)Start Mozilla. 1b. While the splash screen is displayed, start (fast) clicking repeatedly, on Windows desktop, where the Mozilla Minimize window button will soon appear... (One click at the right time is enough, but harder to acheive ;->) When the Mozilla windows first appear: it gets minimized then restored (in restored (== unmaximized) state) ! NB: There is nothing in the JS console (as expected, but was worth checking once). If there is a "(not enough) little" delay before hitting Minimize, the bug does not show: try again. Note that I have a (K6) 200 MHz (and 64 MB) only, on which Mozilla [I know, "233 MHz is recommanded" :-<] starts "not too quickly": this can help at step 1b.!. May be using a group of tabs as startup Location can help on faster computers ??
Yep, I'll have to agree with this bug.. I can reproduce it EVERY time in a nightly build of Phoenix using WinXP (boo!) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030226 Phoenix/0.5 1. start browser 2. go to bugzilla home page (bugzilla.mozilla.org) 3. press the minimize button, it doesn't do anything, just flashes.. then the maximize then minimize buttons just resotres the window to smaller form. hoipe it can be fixed..
Serge (comment 5): I can reliably reproduce this bug (on WinXP) following your steps even on a fast machine. However you have to try pretty hard. I gather this bug appears only rarely but these unusual steps will make it happen reliably. prabhath (comment 6): I see the bounce in Phoenix and Mozilla. In Mozilla this is bug 194738. Ere has a handle on this; it will be fixed soon. However the patch in that bug, while it does fix Mozilla, doesn't fix Phoenix. Disappointing. Still, it's "only" Phoenix. I like Phoenix and I'm concerned about it but I have other things tugging on me much harder right now. Fair warning: this one's low priority for me. helpwanted.
Keywords: helpwanted
Could it be related to url bar here too? If the autocomplete widget doesn't have hidden attribute by default, the synchronization of a view will show its window. On Windows this can be seen using Spy++. If there is a MozillaDropShadowWindowClass with style WS_VISIBLE (and probably client rect of 0,0,0,0), it's showing the window. In other words, is Phoenix missing the fix from bug 120155?
*** Bug 196289 has been marked as a duplicate of this bug. ***
*** Bug 194738 has been marked as a duplicate of this bug. ***
Fixed, according to bug 194738
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reopening. This bug was present long before the one fixed in bug 194738. If it now works for everyone, I suggest closing as WFM.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Correct. This is not bug 194738. See comment 7. And Ere (comment 8), I checked, and Phoenix does have the bug 120155 fix.
I just finished my first Phoenix build. I'll take a look.
Assignee: danm → ere
Status: REOPENED → NEW
Keywords: helpwanted
Status: NEW → ASSIGNED
Works for me: Phoenix 20030310, so we'll need some "still broken" reports against the current build to keep this open.
FFM about two days ago, I'm still going to investigate.
Fixed for me -- used to happen here, now fixed as of 2003-03-11 build.
Still sucks for me, Phoenix 2003-03-11. But I'm having trouble getting my cvs build to start up...
It seems that the testcase of comment #5 is caused by a element.focus() call in delayedStartup() of browser.js (and some sort of timing glitch between it and window watcher). And it isn't as easy as before to reproduce. Do you guys think it might be related to a page load or something else completing/closing/etc just when you minimize the window? I was just wondering if there might be another situation where something is focused when window watcher says the window isn't minimized, but ww is actually lagging behind the reality a bit. So the full scenario would be something like this: 1. window is maximized or "restored", window watcher knows it 2. user minimizes the window 3. something causes a focus call forcing the window to restore (4. window watcher gets the minimize event, too late) I don't really know anything about ww yet, so I might be completely wrong, but I'm goind to do some digging.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212] Reply to comment 19: *For what it is worth: *I tried <about:>, <http://www.mozilla.org/> and <http://fr.biz.yahoo.com/paris.html>, both with or without 'Show Web Site Icons' and 'Load Images': *got the bug in all 6 attempts. (after I learned again how fast I need to click :->) *To be sure, I then tried it twice with 1-4 other window(s) opened (Notepad, W. Explorer): *got the bug too. *(I was about to make some tests about your comment 8 too; but I will rather wait for v1.3 because my v1.3a is rather old. (and v1.3b is broken on W95 :-()) My guess (as a user) is at the same stage as yours ;-< What I can say: *Comment 5 is the only way which I found (luckily) to reproduce the bug. *In "real life", the bug occurs "+/- rarely" and at random. If I remember well (but that _would_ have to be confirmed the next time it happens !), it happens only in random cases in which I minimize the Navigator while it is loading some pages, and it will eventually restore, when something (any/all page load completion !??) happens; What I am pretty sure of (to be confirmed too) is that it does not unminized immediately after minimizing, but only a few instants later (when something happens in the browser). [see comment 1 (and its end) for behaviour(s) which I might have seen.] It does not help too much ... but, if verified, it could proove to be consistent with your "focus <-> Window Watcher" clue.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312] (another) Reply to comment 19: Comment 5 test case is still valid: I got it 3/3 times: 1a. New splash screen, 1b. One click at the "very" time that the splash screen disappear and the Mozilla window appear is enough :-) NB (informational only): The XUL.mfl file was "disabled" in my v1.3a profile; it is "enabled" on my fresh v1.3 profile. I also have 256 MB instead of 64, now :-)
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312] Reply to comment 8 (and 20): I tried with Preferences... > Navigator > Smart Browsing > "Automatically complete ..." unchecked: 1) with no previous XUL.mfl; 2) with the new 798KB file; In both cases, I got the bug, as described in comment 21. NB: I don't know if this test actually helps, but it can't hurt.
XUL.mfl has absolutely nothing to do with this bug.
My comment about window watcher was a bit inaccurate. It doesn't know if the window is minimized or not. In this test case things can happen in two orders: This works: 1. startup 2. fire the idle timer (delay=0) which sets the focus 3. receive the window message and minimize This doesn't work: 1. startup 2. receive the window message and minimize 3. fire the idle timer (delay=0) which sets the focus I'm afraid this doesn't help much. Fortunately I've found another case where a minimized window pops up. I did a search for "focus\(\)" on lxr and middle-clicked link to http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#918, to open it in a new tab, then immediately minimized the window. After a short will the window can restore. This didn't happen always but often enough that I can try to find the reason.
Reply to comment 23: You're right ! I was only adding two (changed) facts related to the time it takes for my Mozilla to start up ... in case they could explain the "it isn't as easy as before to reproduce" in comment 19.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312] Another (as in comment 24) confirmation that this bug is actually still there "unchanged" (by the fixes in the other related bugs). Well... I can get this "real-life" case (almost) every time now: 0. Minimize all (DOS and Windows) windows 1. Start Mozilla 2. Load a group of 5 tabs (call it "P_NL" as a reminder) 3. Minimize Mozilla shortly after 4. Restore (at least) 1 (DOS or Windows) window 5. Minimize it: Mozilla "soon" ("0-2" seconds) restores itself ! The timing for step (4,) 5 and 6 may affect if & when Mozilla will restore; Sometimes, I need to do steps 5) and 6) two or more times... Well, I tried to narrow the steps and conditions further, but I don't feel very easy at it. And I had the "immediate" version once, while trying to reproduce: *Started Mozilla *Loaded same group of 5 tabs *Minimized Mozilla: it restored itself ! I'll let you work with your comment 24 case; Let me know if there is something I could try which could help.
(Forgive me: I'm tired, and I don't think too well right now.) Additions to my comment 26, to simplify/explicit/summarize the test case: *When I say "load the tabs", I mean that the actual load continues while Mozilla is minimized (and eventually after it restores). *As a user, it looks like there are two parts in this bug: a) Why does Mozilla restores itself when it should not ? b) Why does it restore in the unmaximized state, even if it was maximized before being minimized ? (I thought about this after verifying that the a) part happens with both starting states.) *No need to (re)start Mozilla each time !! *I start with <about:> as my home page (no tab at this point) *Then I load my group of 5 tabs, for testing *Then I can use the "close other tabs" on "about:", and test again :-) *No need for all windows except Mozilla to be minimized at the test start ! The bug shows also if I first minimize Mozilla, then the other opened windows, then restore-minimize some other window.
Thanks guys, I believe I have enough cases to test now. Unfortunately my progress is slow, but I'm working on this whenever I have time.
Here's the deal: when a new tab is created, setTimeout("window._content.focus()", 0); is called. As setTimeout() uses idle timers, the call could be postponed even for a few seconds when the browser is busy loading a page. Meanwhile the user has a chance to minimize the window. As it happens, call to focus() will restore it (this is bug 96275, I believe). There has been a setTimeout() for the focus() call in tabbrowser.xml since the beginning, but I couldn't find any reason not to call focus() directly here. There are some issues related to bug 96275 (like bug 103197), but I don't thin kit applies here as it is the content() that's focused and not an input field. There is another case in BrowserOpenTab() in navigator.js which, I believe, would cause the same problem, but we could change that if we find out that the change in tabbrowser.xml doesn't break anything. If it does, the only possibility I can see would be to fix bug 96275. Dan, what say you?
Dan? Or Neil, perhaps?
For a time we were sprinkling setTimeout()s all over chrome script. It's a panacea because it delays execution of the affected function until whatever it is we're doing at the moment is finished. Some of these are fixes for crash bugs. Looks like this one harkens back to rev 1.361 and bug 91884. I think I kind of remember that one. Comments in that bug make it seem as if we were considering a more robust change at the time gave up on that when setTimeout worked its wonders.
Bryner's comment in bug 191896 suggests this also has to do with xbl bindings not loaded before setting focus., which I understand complete. This leads back to bug 90337.
Depends on: 90337
*** Bug 205098 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4b) Gecko/20030507] Bug still there. (with v1.3 profile, at least) NB: I did not try the reproductible testcase; only saw the bug "at random".
Yep, I know. While bug 90337 is now closed, I have to consult others to find out if we could remove some hacks to make this work too.
I've filed a bug to fix this for all instances where the focus call is delayed. I'll mark this as a duplicate of it. *** This bug has been marked as a duplicate of 207639 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → DUPLICATE
Re comment 36 (and bug 207639 comment 2) You may want to check comment 4 and comment 29. Also, what about your proposed (tabbrowser.xml) patch ?
I'm going to take care that the patch here is also taken into account.
*** Bug 209265 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
(In reply to comment #38) > I'm going to take care that the patch here is also taken into account. Ere: What is the status of this patch ? Especially after bug 120148 fix ?? I haven't seen this bug for a while; Yet, the |setTimeout()| might be removed anyway: I don't know.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: