305258 - Other firefox window disappears from task bar

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Peter van der Woude [:Peter6]]

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

Comment 1

[Peter van der Woude [:Peter6]]

this:
works in 20050809 0845pdt build
fails in 20050809 0942pdt build

regressionwindow:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-09+08%3A15%3A00&maxdate=2005-08-09+09%3A15%3A00&cvsroot=%2Fcvsroot

regressor bug 303995 ?
cc DougT

Comment 2

[Doug Turner (:dougt)]

peter did this work a month ago?

This is a pretty odd case -- you are opening up a window from a modal dialog.  

Comment 3

[Martijn Wargers (dead)]

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). 

Comment 4

[Peter van der Woude [:Peter6]]

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)

Comment 5

[Martijn Wargers (dead)]

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

Comment 6

[Doug Turner (:dougt)]

the branch and the trunk should share the same window flags.

Comment 7

[Peter van der Woude [:Peter6]]

(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.

Comment 8

[Doug Turner (:dougt)]

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.

Comment 9

[Dave Townsend [:mossop]]

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.

Comment 10

[Martijn Wargers (dead)]

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.

Comment 11

[Martijn Wargers (dead)]

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.

Comment 12

[Peter van der Woude [:Peter6]]

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.

Comment 13

[Martijn Wargers (dead)]

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?

Comment 14

[[e-mail]]

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.

Comment 15

[Martijn Wargers (dead)]

Attachment: patch

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 16

[[e-mail]]

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.

Comment 17

[Martijn Wargers (dead)]

Attachment: patch2

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)

Comment 18

[Martijn Wargers (dead)]

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.

Comment 19

[[e-mail]]

Comment on attachment 193511 [details] [diff] [review]
patch2

I can't test this for at least two reasons, sorry.

Comment 20

[Mike Connor [:mconnor]]

Comment on attachment 193511 [details] [diff] [review]
patch2

Please get some testing on trunk before landing on branch, but this should work
fine.

Comment 21

[Mike Schroepfer]

Martijin - just assigning to you to track that someone is one it.  Thnx!

Comment 22

[:Gavin Sharp [email: [e-mail]]]

Checking in text.xml;
/cvsroot/mozilla/toolkit/content/widgets/text.xml,v  <--  text.xml
new revision: 1.19; previous revision: 1.18
done

Comment 23

[Martijn Wargers (dead)]

Comment on attachment 193511 [details] [diff] [review]
patch2

I think this is safe.

Comment 24

[Asaf Romano (gone)]

Comment on attachment 193511 [details] [diff] [review]
patch2

better to get this done by b4.

Comment 25

[Asa Dotzler [:asa]]

we need to get this verified on the trunk before we can consider it for the branch.

Comment 26

[Peter van der Woude [:Peter6]]

(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.

Comment 27

[Dave Townsend [:mossop]]

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

Comment 28

[Robert Strong (they/them - no direct email)]

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

Comment 29

[Asa Dotzler [:asa]]

after this is verified on the trunk, we'll consider for branch approval.

Comment 30

[Peter van der Woude [:Peter6]]

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

Comment 31

[Asaf Romano (gone)]

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

Comment 32

[Martijn Wargers (dead)]

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?

Comment 33

[Tracy Walker [:tracy]]

verified on Firefox 1.4 -mozilla1.8 branch- Windows : 2005-09-07

Comment 34

[Martijn Wargers (dead)]

(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.

Comment 35

[Martijn Wargers (dead)]

The issue mentioned in comment 13 is filed as bug 312452.