Closed Bug 194738 Opened 23 years ago Closed 22 years ago

Phoenix/Mozilla minimizes to toolbar then re-opens

Categories

(Core :: XUL, defect)

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

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ghahn28401, Assigned: emaijala+moz)

References

Details

(Keywords: access, regression)

Attachments

(1 file)

Patch to keep the popup frame hidden if its widget is hidden
1.23 KB, patch
roc
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: 20030223 build When I go to minimize Phoenix to the toolbar, it does then re-opens immediately Reproducible: Always Steps to Reproduce: 1. Open browser full screen 2. Click the minimize button 3. Actual Results: Browser minimized then re-opened immediately Expected Results: minimized to toolbar and stayed there
Seeing this with mozilla also. BuildID: 2003022404 on WinXP. Confirming and moving to Browser. Also if window is maximized, minimize functions as "Restore".
Status: UNCONFIRMED → NEW
Component: General → Browser-General
Ever confirmed: true
Product: Phoenix → Browser
Summary: Phoenix minimizes to toolbar then re-opens → Phoenix/Mozilla minimizes to toolbar then re-opens
Version: unspecified → Trunk
Happening on Win 98 also. Build ID Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030225
*** Bug 195074 has been marked as a duplicate of this bug. ***
This issue is also seen on 2003022610. The only affected window appears to be the Navigator. Calendar and Mail/News are not affected. I am moving this to XP Toolkit/Widgets because that component's description mentions focus issues. I upgraded the severity and nominated this as a 1.4a blocker because this issue affects the accessibility of Mozilla and it is also a malicious bug. Currently, the only workaround I have found is to use the Show Desktop command that appears in the Quick Launch toolbar of Windows. In bug 195074, it was mentioned that openning other tabs also seems to work as a workaround. I have confirmed that this works occasionally.
Severity: normal → major
Component: Browser-General → XP Toolkit/Widgets
Flags: blocking1.4a?
Keywords: access, regression
OS: Windows XP → Windows 98
A few more details. This seems to happen when the browser window is the last window on the desktop. Minimizing it at this point will cause it to restore immediatly. If there are two applications open on the desktop, minimizing mozilla will work. But; when you minimize the other, mozilla will restore. I have been unable to get mozilla to restore in a similar manner if two or more application windows remain open after mozilla is minimized.
Last time this happened it was bug 120155, for what it's worth.
.
Assignee: blaker → ere
*** Bug 195240 has been marked as a duplicate of this bug. ***
Ok, I'll try to investigate with the provided information.
I can now reproduce it. It's not so simple, I have to enter an address in the url bar to make it happen. Anyway, it happens with 2003022108 too, so it's not my focus patch :) Anyway, I'll still try to investigate it.
Build 2002021905 is also affected.
It seems very much like bug 120155. That's bad, because 120155 sucked. The symptoms are very similar if not identical, and it seems to be caused by a window in the autocomplete widget; the same widget I pointed out in bug 120155 comment 198. The patch for that bug, by the way, is still there. My Moz 1.4 build shows this bug fairly reliably. It's much harder to make it happen in my 1.3 build (I think I saw it once?) Focus is slightly different between the two builds but that may be because of the autocomplete window catching focus unexpectedly.
*** Bug 195258 has been marked as a duplicate of this bug. ***
Flags: blocking1.3?
I second rkaa-lst, this is so bad it should be fixed before 1.3. I couldn't reproduce this with 1.3a. I'll try some other builds to pinpoint the failure, but I think we should try to find out the root cause especially now that the patch for bug 120155 is still there. It's definitely once again related to the autocomplete widget as I wasn't able to reproduce it without having autocomplete open at least once.
Crap. I can't believe this is back. Dan, this is likely to be a difficult problem. Can you help us for 1.3? Ere, RKAa, others, can you help us pinpoint the build where this regressed. I've seen it once on winXP build from the 21st. Ere has seen it on a build from the 19th. Has anyone seen it on any older builds than that?
Flags: blocking1.3? → blocking1.3+
Just got it on 20030216.
This seems to be a quite reliable (and probably too complicated) way to reproduce it on my WinXP (not 100% though, it seems to be timing related): - create a new profile - ensure you have a quick launch icon for Mozilla - have one window (Command Prompt) open so that it the Mozilla window to be opened doesn't cover its Minimize button, everything else minimized - start Mozilla (I have multiple profiles so I get Profile Manager, don't know if that matters) - press Show Desktop button twice - go to url bar and enter www.google.com - minimize Command Prompt by clicking its Minimize button (I don't focus it first) - try to minimize Mozilla
Can't reproduce on 2003020608.
Unfortunately I don't have builds between 20030207 and 20030215.
i Can reproduce it on 20030225 20030226 20030227
Something causes GlobalWindowImpl::Focus() to be called when minimizing.
Looks like at least Windows thinks NetscapeDispatchWnd could be focused and tries to activate it.
Oops, forget my last comment.
It's actually a MozillaDropShadowWindowClass.
I had this problem on 2003022810 win xp. I tried build from previous days without succeeding in reproducing the bug. After doing so, I did a clean install of 2003022810 with old profiles and the bug was gone.
Maybe highly regressed version of bug 163372? 100% reproducible for me: start Mozilla (blank page as startpage), punch in about:, minimize, gaze in horror as it restores itself. WinXP Gecko/20030228
No idea whether it means anything, but the popups have styles WS_CHILD and WS_POPUP, which according to MSDN shouldn't be mixed. Will test.
It's a big window but here are the checkins between the last known working build and the first known regressed build http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=Head&sortby=Date&hours=2&date=explicit&mindate=2003-02-06+08%3A00&maxdate=2003-02-16+07%3A00 based on Ere's comment 18
The situation: There is one MozillaDropShadowWindowClass (WS_CHILD, WS_POPUP, WS_VISIBLE, WS_CLIPSIBLINGS, WS_OVERLAPPED) whose clientrect is (0,0,0,0). It has one child MozillaWindowClass which is also visible, clientrect (0,0,152,34). When the navigator window is minimized, this popup window gets an inactivation message (looks like it was active, interesting) subsequently causing an activation message to be send to the main window, which now restores. Looks like the visible window is the "Search for ..." that comes under url field. Might be the same thing Tarmo described.
BuildID:2003022709 Look at this steps. 1- Open Mozilla Browser 2- write an URL on address bar 3- Try no minimize ( The bug is here ) if you try additional steps mozilla browser work normal again. 4- Open Mozilla Mail 5- Minimize Mozilla Mail 6- Maximize mozilla Mail 7- Close Mozilla Mail 8- Minimize Mozilla Browser -> is working again
and if you are try this mozilla -mail fisrt and keep maximized mozilla mail and after you you try to open the browser from component bar the bug is not reproducible. but if you minimize mozilla mail the bug is showed again and you need to maximize mozilla mail again to disable the bug..
Ok, so there is a popup-set inside of which the search box lives. When the search box popup is shown, the popup-set creates a visible window with width 0. When the search box popup is hidden, this window stays visible. Setting hidden=true using DOM Inspector makes the window disappear (also the handle as shown on Windows by Spy++) and minimize work. I believe popup-set should destroy its window when there are no more popups visible, but I'm not yet able to do that. Feel free to jump in. Anyway, I will try to dig into this more, but it might take some time. The fix for bug 120155 etc. seems to be just a workaround for the same problem or its variant.
Looks like 2003021408 is not affected. This would narrow the timeframe a lot.
Just to report some progress. ViewManager doesn't seem to hide the popup when it should. I'll investigate why.
Visibility of the popup widget wasn't properly checked when the frame was currently hidden.
Attachment #116024 - Flags: review?(danm)
Comment on attachment 116024 [details] [diff] [review] Patch to keep the popup frame hidden if its widget is hidden Or would dbaron be a better choice for reviewer? Feel free to correct me in any case.
Attachment #116024 - Flags: review?(danm) → review?(dbaron)
Oh, and while at it, from who should I ask sr?
Is it me or do I fail to see what the patch is doing? It's replacing if (cond1) { if (cond2) { viewIsVisible = PR_FALSE; } } by if (cond1 && cond2) { viewIsVisible = PR_FALSE; } Isn't that the same or am I too tired to work?
You just need another coffee break :) Actually, you left out the important part. Let's add it: if (cond1) { if (cond2) { viewIsVisible = PR_FALSE; } } else { if (cond3) { viewIsVisible = PR_FALSE; } } is changed to: if (cond1 && cond2) { viewIsVisible = PR_FALSE; } else { if (cond3) { viewIsVisible = PR_FALSE; } } ---- Think about what happens if cond1=true, cond2=false and cond3=true.
I can get around this annoying bug by opening a new Mozilla Window, minimising the window that previously refused to minimise, and then closeing the new window that I had just created. This confirms comment #5, but also gives people a very temporary workaround if they really really must minimise the window. WinXp Mozilla build 2003022810-TRUNK
danm, can you help us with a review here? We're trying to wrap up 1.3 and this is a blocker. Thanks.
Attachment #116024 - Flags: superreview?(bzbarsky)
Comment on attachment 116024 [details] [diff] [review] Patch to keep the popup frame hidden if its widget is hidden sr=bzbarsky; switching review request to roc, since he's most familiar with this code...
Attachment #116024 - Flags: superreview?(bzbarsky)
Attachment #116024 - Flags: superreview+
Attachment #116024 - Flags: review?(roc+moz)
Attachment #116024 - Flags: review?(dbaron)
Comment on attachment 116024 [details] [diff] [review] Patch to keep the popup frame hidden if its widget is hidden r=roc+moz great catch, Ere!!
Attachment #116024 - Flags: review?(roc+moz) → review+
Thanks. I can check this into trunk, but could someone check in to branch? I don't have a branch tree at hand.
Comment on attachment 116024 [details] [diff] [review] Patch to keep the popup frame hidden if its widget is hidden 1 have a 1.3 branch
Attachment #116024 - Flags: approval1.3+
Attachment #116024 - Flags: approval1.3+ → approval1.3?
Comment on attachment 116024 [details] [diff] [review] Patch to keep the popup frame hidden if its widget is hidden The 1.3 branch is very different. It does not, for example, have an nsIFrame::SupportsVisibilityHidden method at all. This may explain why I couldn't even see this bug in a 1.3 build (comment 12). I'm removing the "blocking 1.3" flag.
Attachment #116024 - Flags: approval1.3?
Flags: blocking1.4a?
Flags: blocking1.4a+
Flags: blocking1.3-
Flags: blocking1.3+
Ah, looks like I caused the regression. Sorry about that.
And looks like I screwed up when testing different builds. Sorry about that. Still, I could have swored that I saw it on 2003021608.. I wonder why do I still see this: danm: blocking 1.3+ danm: blocking 1.4? The mail stated it correctly.
Flags: blocking1.4a?
Flags: blocking1.4a+
Flags: blocking1.3-
Flags: blocking1.3+
Ere: you restored 1.3+ ! Are you certain you want this bug to block 1.3? Also note that while I can verify this patch fixes the problem in Mozilla, it doesn't resolve the problem in Phoenix. See bug 163372 comment 7 (responding to comment # 6 in that bug, in which someone makes note of this bug (194738)).
Something crapped. I reloaded and Ctrl-reloaded, but I saw the flags as I said in my previous comment. I hope they will now be ok. I have an idea about Phoenix, but let's talk about it in the other bug.
Status: NEW → ASSIGNED
Flags: blocking1.4a?
Flags: blocking1.4a+
Flags: blocking1.3-
Flags: blocking1.3+
Not sure if this symptom is related, but just in case. Using Moz1.3b and WinXp. Changing the windows theme consistantly restores Mozilla if it is minimized. Phoenix is also affected (since 0.5 milestone at least and latest nightlies). If both Mozilla and Phoenix are running and minimized, both will restore. Steps to reproduce: 1. Minimize mozilla to the taskbar 2. Open desktop properties (Right-click desktop > properties) 3. Select "Appearance" tab 4. Change "Windows and buttons" theme (to anything else) and click "Apply" 5. Mozilla will restore during/after new theme is applied. Reproducible: Always
That would be bug 195738.
Fix checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
So we're confident that this doesn't happen on the 1.3 branch?
Works for me Mozilla 1.3 build 2003030505
Just failed for me with build 2003030504-TRUNK on WinXP SP1. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Oppps, I should have looked before I leaped. My build may not have the fix in it....changing back to Resolved until I have definitive info.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
is a dupe
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** This bug has been marked as a duplicate of 163372 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
This bug has the fix, mark the other as a duplicate if appropriate (which I think it isn't because the problem fixed here was just recently introduced).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reclosing as fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Haven't seen this problem since the check-in of the patch. Verifying.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: