Need a way to detect hidden window in widget

RESOLVED FIXED

Status

RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: stevew, Assigned: mkaply)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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

a=rjesup@wgate.com 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

Comment 8

17 years ago
-> danm for a look
Assignee: sgehani → danm

Comment 9

17 years ago
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

Comment 10

17 years ago
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)

Comment 12

16 years ago
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

Comment 13

15 years ago
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)

Updated

15 years ago
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
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.