Closed Bug 141676 Opened 22 years ago Closed 21 years ago

Need a way to detect hidden window in widget


(SeaMonkey :: UI Design, defect)

Not set


(Not tracked)



(Reporter: stevew, Assigned: mkaply)



(1 file, 1 obsolete file)

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
Patch coming up
Ever confirmed: true
Attached patch Fix for problem (obsolete) — Splinter Review
This is an ugly fix.

I need to detect the hidden window being created and not add it to the

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

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 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
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.
Keywords: fixed1.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 → ---
Attached patch Better fixSplinter Review
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.
Closed: 21 years ago
Resolution: --- → FIXED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.