Closed Bug 305258 Opened 17 years ago Closed 17 years ago

Other firefox window disappears from task bar

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
1.5.0.x Branch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: Peter6, Assigned: martijn.martijn)

Details

(Keywords: regression, verified1.8)

Attachments

(1 file, 1 obsolete file)

patch2
1.05 KB, patch
mconnor
: review+
asa
: approval1.8b4+
Details | Diff | Splinter Review 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050819
Firefox/1.0+ ID:2005081913

repro:
1.Open Firefox with 1 window and multiple tabs 
2.Open Options
3.Go to Advanced -> Update and Press [check now] for installed extensions and themes
3.The extension manager opens.
... so far so good
4.Rightclick on an extension and select "visit homepage"
5.A window opens with the requested homepage
but....
6.It has replaced the window from point 1. on the task bar
7.Both EM and Options window have also disappeared

8.Now try to open Options in this window
9.It won't work

Solution, close the window with the extension homepage and you'll see the lost
window , EM and options again
Flags: blocking1.8b4?
Summary: Other firefox windows disappear from task bar → Other firefox window disappears from task bar
peter did this work a month ago?

This is a pretty odd case -- you are opening up a window from a modal dialog.  
Yes this did work with a 2005-07-18 build and with a 2005-07-19 build (in that
build, bug 303995 can't even be seen when trying to reproduce this bug (I can
reproduce this bug in current build). 
I open Options , which is Modal (=correct)
From Options I open Extension manager , which shows up as Modal(should be global)
From Extension manager I open Extension Homepage which opens in a Modal Window
(should be global)

If I open EM from menu it opens Global, and so does the ext. homepage

This problem does NOT occur on trunk, just on branch (via IRC)
Well, I'm seeing the bug with a trunk build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050819
Firefox/1.6a1
the branch and the trunk should share the same window flags.
(In reply to comment #5)
> Well, I'm seeing the bug with a trunk build:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050819
> Firefox/1.6a1

That report came from Mossop, he didn't see it.


so, reverting my check will not fix the true problem -- it just trades this
problem for another.  I am wondering at some point neither bug existed and when
was it.
I didnt see it because I had instantApply set to true, which makes the options
window non-modal. Changing that and its in trunk too.

The point that neither bug existed is the 2005-07-18 build.
After that you get bug 303995. The fix for that bug was checked in at 2005-08-09
09:00 PDT and made this bug visible (but isn't the root cause of this bug, if I
understand correctly). 
So between 2005-07-18 and 2005-08-09 09:00 PDT, some checkin could have caused
this bug.
Actually, this didn't work well before 2005-08-09. In builds before that, you
get the separate window, but there is no way to get to the first window. Trying
to focus the first window, always results in a focusing of the second window.
umm, might this simply be an error in options ?
when pressing the help button in Options, the help window does open Global.
So opening a global window from Options is possible.

That's opened with this function:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/widgets/preferences.xml#860
So that is opened in a different way.

xul labels with an href attribute are opened this way:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/widgets/text.xml#421
Via that, I found bug 280065, comment 31:
"As I recall, modal dialogs can only open modal dialogs"
That would make the behavior, mentioned in comment 11, correct (although not
desired).
But the window should still create a separate item in the task bar. But that
should probably be a different bug, I guess.

So, I think the label xbl binding should probably be changed to do 'the right
thing' when a label is clicked from within a dialog, not?
You could, although you'd have to be careful to fall back to using open if you
wanted the binding to remain usable from content.

Note: You should specify a particular revision in bonsai URLs.
Otherwise you might as well use LXR.
Attached patch patch (obsolete) — — Splinter Review 
I don't know if this is the solution, but it fixes this bug.
Only script code loaded from chrome can open dialogs. You an't see the use of
dialogs in regular web pages.
So the only situation, where I can see this patch go wrong is when chrome code
is opening a dialog from a non-chrome location (and the page from that location
uses the <label href="etc"/> construct).
Comment on attachment 193508 [details] [diff] [review]
patch

Quickly glanced at this but I should really be asleep...

>+          if (window instanceof ChromeWindow) {
Apparently there's a bug in instanceof ChromeWindow, but instanceof
Components.interfaces.nsIDOMChromeWindow works OK (even from content).

>+            while (win.opener) 
Need to check that !win.opener.closed too, because win.opener is also set for
top-level windows opened from other top-level windows.
Attached patch patch2 — — Splinter Review 
Addressing Neil's comments. I haven't tested this patch yet (I need some sleep
too)

(In reply to comment #16)
> Apparently there's a bug in instanceof ChromeWindow, but instanceof
You mean bug 295460, right? (It seemed to work fine for me, though, but I used
window, not content)
Attachment #193508 - Attachment is obsolete: true
Comment on attachment 193511 [details] [diff] [review]
patch2

Ok, I've tested patch2, and it seems to work fine.
Might as well ask for review, then.
Attachment #193511 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 193511 [details] [diff] [review]
patch2

I can't test this for at least two reasons, sorry.
Attachment #193511 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #193511 - Flags: review?(mconnor)
Flags: blocking1.8b4? → blocking1.8b4+
Whiteboard: [needs review mconnor]
Comment on attachment 193511 [details] [diff] [review]
patch2

Please get some testing on trunk before landing on branch, but this should work
fine.
Attachment #193511 - Flags: review?(mconnor) → review+
Whiteboard: [needs review mconnor]
Martijin - just assigning to you to track that someone is one it.  Thnx!
Assignee: nobody → martijn.martijn
Checking in text.xml;
/cvsroot/mozilla/toolkit/content/widgets/text.xml,v  <--  text.xml
new revision: 1.19; previous revision: 1.18
done
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment on attachment 193511 [details] [diff] [review]
patch2

I think this is safe.
Attachment #193511 - Flags: approval1.8b5?
Comment on attachment 193511 [details] [diff] [review]
patch2

better to get this done by b4.
Attachment #193511 - Flags: approval1.8b4?
we need to get this verified on the trunk before we can consider it for the branch.
(In reply to comment #25)
> we need to get this verified on the trunk before we can consider it for the
branch.

Impossible Asa,
There is no check update button anymore (was removed) so no one can verify.
Making this absolete for the moment.


Followed these steps to reproduce:

Open extension manager (non modal)
View options of an extension (modal)
Click the extension homepage which opens a new window (non modal).

This seems to work for me, I end up with the original firefox window, the
extensions manager and the new firefox window in the task bar.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050901
Firefox/1.6a1 ID:2005090107
To reproduce this on the branch.
open -> extension manager
open DOMi's about dialog (an extension that doesn't provide a custom about
dialog is required)
click on visit home page
after this is verified on the trunk, we'll consider for branch approval.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050828
Firefox/1.6a1 ID:2005082807

Confirming -> opens global from EM about
Attachment #193511 - Flags: approval1.8b4?
Attachment #193511 - Flags: approval1.8b5? → approval1.8b4?
Status: RESOLVED → VERIFIED
Attachment #193511 - Flags: approval1.8b4? → approval1.8b4+
Checking in text.xml;
/cvsroot/mozilla/toolkit/content/widgets/text.xml,v  <--  text.xml
new revision: 1.18.2.1; previous revision: 1.18
done
Keywords: fixed1.8
Doug Turner,
This is fixed now, but there is still the issue of "you are opening up a window
from a modal dialog." and what should happen with it (I have no idea), not?
verified on Firefox 1.4 -mozilla1.8 branch- Windows : 2005-09-07
Keywords: fixed1.8 → verified1.8
Blocks: 308026
No longer blocks: 308026
(In reply to comment #32)
> Doug Turner,
> This is fixed now, but there is still the issue of "you are opening up a window
> from a modal dialog." and what should happen with it (I have no idea), not?
Basically this is bug 256555.


The issue mentioned in comment 13 is filed as bug 312452.
You need to log in before you can comment on or make changes to this bug.