From Bugzilla Helper: User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.0rc1) Gecko/20020418 BuildID: 2002041811 Open Mozilla (1.0 RC1 release) from the icon created by mozfold.cmd. Minimize it, then click on the icon again. Instead of restoring the minimized window, it brings up the *hidden window* instead(!). If that is closed, the browser crashes in mozjs. Reproducible: Always Expected Results: Should have restored the Mozilla browser window that was minimized.
Patch coming up
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Created attachment 82031 [details] [diff] [review] Fix for problem This is an ugly fix. I need to detect the hidden window being created and not add it to the tasklist. The only way I can find to detect it is by size. It is NOT the first window created if you type mozilla -profilemanager.
Comment on attachment 82031 [details] [diff] [review] Fix for problem r=pedemont
Attachment #82031 - Flags: review+
Comment on attachment 82031 [details] [diff] [review] Fix for problem sr=blizzard (platform specific code)
Attachment #82031 - Flags: superreview+
1. Have you tried this on Windows or some other OS? 2. Did you try using file: URLs rather than relative URLs to see if that worked?
Comment on attachment 82031 [details] [diff] [review] Fix for problem firstname.lastname@example.org for drivers. Please check into branch (and trunk if you want). Please leave the bug open and implement a better solution on trunk in the future (perhaps for merge to a future 1.0x branch target)
Attachment #82031 - Flags: approval+
I checked in this temporary fix for OS/2, but there is a bigger issue. There should be some way that the creator of the infamous "Hidden Window" tells widget that it is the hidden window in case it needs to do special things with it.
Assignee: mkaply → sgehani
Status: ASSIGNED → NEW
OS: OS/2 → All
Hardware: PC → All
Summary: Mozilla icon restores "hidden" window → Need a way to detect hidden window in widget
-> danm for a look
Assignee: sgehani → danm
adding fixed1.0.0 keyword (branch resolution). This bug has comments saying it was fixed on the 1.0 branch and a bonsai checkin comment that agrees. To verify the bug has been fixed on the 1.0 branch please replace the fixed1.0.0 keyword with verified1.0.0.
Ick. I don't follow the "first window" thing in comment 2. This bug, is it because the OS is unfortunately selecting the wrong window to activate? Or are we doing something wrong? If the former, it'd be nice to magically arrange things so that the OS just doesn't select that window, rather than having to expose knowledge of hidden-ness in the widget interface. Ick again. I wonder if this is a problem any more. Bug 120155 sounds very similar.
Target Milestone: --- → mozilla1.2alpha
On OS/2 we have a window list which lists all windows that are in the system. Curently on Mozilla, we dynamically add and remove windows from this list as Mozilla shows and hides them, since Mozilla simply hides windows rather than destroying them (hidden windows, message compose window) The issue is that we need to be told when a window is never going to be seen so that we can special case it. Otherwise we add the window to the task list (because we have no way of knowing the user is not going to see it) and then when the user clicks on the icon on the desktop to display the application, OS/2 displays the first frame created (the hidden window)
Changing target milestone to 'Future' since these seem to have missed the 1.2 alpha. If you are still considering a fix for 1.2 please re-target accordingly.
Target Milestone: mozilla1.2alpha → Future
I just happened to notice, there is a way to know whether a window at the widget level is the hidden window. This was done as part of bug 207742. You can now simply check whether mWindowType == eWindowType_invisible. Michael, I believe this makes your problem much simpler and gives you a more straightforward way to solve this bug. I'm handing it back. Lemme know. PS you may want to take a look at bug 207742 for implementation on OS/2, as well. The salient part is the three lines (the first is a comment) beginning at line 4138 in widget/src/windows/nsWindow.cpp rev 3.487.
Assignee: danm-moz → mkaply
Target Milestone: Future → ---
Created attachment 137609 [details] [diff] [review] Better fix Use the invisible window flag to clean up the patch.
Attachment #82031 - Attachment is obsolete: true
Attachment #137609 - Flags: review?(pedemont)
Attachment #137609 - Flags: review?(pedemont) → review+
there is a way to know a window is the hidden window and I checked this latest fix into the trunk. Marking fixed.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.