141676 - Need a way to detect hidden window in widget

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Steve Wendt]

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.

Comment 1

[Mike Kaply [:mkaply]]

Patch coming up

Comment 2

[Mike Kaply [:mkaply]]

Attachment: 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 3

[jhp (no longer active)]

Comment on attachment 82031 [details] [diff] [review]
Fix for problem

r=pedemont

Comment 4

[Mike Kaply [:mkaply]]

Comment on attachment 82031 [details] [diff] [review]
Fix for problem

sr=blizzard (platform specific code)

Comment 5

[Mike Kaply [:mkaply]]

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 6

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 82031 [details] [diff] [review]
Fix for problem

a=[e-mail] 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)

Comment 7

[Mike Kaply [:mkaply]]

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.

Comment 8

[Samir Gehani]

-> danm for a look

Comment 9

[Asa Dotzler [:asa]]

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.

Comment 10

[Dan M]

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.

Comment 11

[Mike Kaply [:mkaply]]

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

[Juan José Mata]

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.

Comment 13

[Dan M]

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.

Comment 14

[Mike Kaply [:mkaply]]

Attachment: Better fix

Use the invisible window flag to clean up the patch.

Comment 15

[Mike Kaply [:mkaply]]

there is a way to know a window is the hidden window and I checked this latest
fix into the trunk.

Marking fixed.