355657 - window.open()ed links fail in a new tab, same window

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Summary: window.open()ed links fail in a new tab, same window

Build: The morning trunk build from the 4th of October works, but 2006-10-05-08 fails.

Steps to Reproduce:

1. Have links set up to open in a new tab in the same window
2. Load http://squeedlyspooch.com/blog/free-toshok.html
3. Click on any of the image links, which do window.open()
4. Close the newly opened window
5. Click on another link

Expected Results:
New tab opens from that window.open() call

Actual Results:
The pointer does the busy cursor for a little bit, then goes back to being a pointer, but the new tab doesn't load

WORKAROUND: Switching between tabs and then coming back seems to help

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061005 Minefield/3.0a1
WFM with default settings + browser.link.open_newwindow.restriction to 0

Comment 2

[Peter Van der Beken [:peterv]]

Stephend: could you explain why you put this on the dependency list of bug 349465? That patch didn't change anything for regular web pages.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #2)
> Stephend: could you explain why you put this on the dependency list of bug
> 349465? That patch didn't change anything for regular web pages.

Sure, smaug asked me to. 

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #3)
> Sure, smaug asked me to. 
> 
I asked to do that if bug 349465 actually caused this ;)
(I thought you tested it.)

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #4)
> (In reply to comment #3)
> > Sure, smaug asked me to. 
> > 
> I asked to do that if bug 349465 actually caused this ;)
> (I thought you tested it.)

All I can confirm is the regression time frame; I'm happy not to have this on a dependency list, I thought you were more sure of this than I am/was.  Feel free to remove it. 

Comment 6

[[e-mail] (:bhearsum)]

I cannot reproduce this using 2006-10-06-03-mozilla1.8 win32.

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK, this regressed between 2006-09-29-01 and 2006-09-30-01.  Looks like bug 350416 to me.

Comment 8

[Boris Zbarsky [:bzbarsky]]

So the basic problem is that this is a named window.  The patch in bug 350416 leaves it invisible, but still findable in the docshell tree, looks like, so the new loads go into the invisible window.

Comment 9

[Boris Zbarsky [:bzbarsky]]

So the point is you probably want to change the browser type or something.  Not sure what.  The idea is that you do NOT want the content tree owner finding that browser.

Comment 10

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #9)
> So the point is you probably want to change the browser type or something.  Not
> sure what.  The idea is that you do NOT want the content tree owner finding
> that browser.
> 

content-targetable? content-primary? just unset it?

Comment 11

[Boris Zbarsky [:bzbarsky]]

No, neither of those will work.  If you want to do the type thing you need a new type and hacking in the nsContentTreeOwner.

biesi suggested maybe resetting the name to "" and then back.  You might be able to do that... for now.

Comment 12

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: untested patch

Can't test this.  tabbrowser.xml changes don't get picked up in my build.

Comment 13

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

bz, at this point it doesn't look like undo close tab is going on branch.

Comment 14

[[e-mail]]

(In reply to comment #11)
>(In reply to comment #10)
>>content-targetable? content-primary? just unset it?
>No, neither of those will work.
On the other hand plain type="content" seems to work fine.

Comment 15

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: tested patch

Neil seemed to think this might be a better way to do it.  This works, and does reasonable things even after undoing the close.

Comment 16

[[e-mail]]

Comment on attachment 241641 [details] [diff] [review]
tested patch

As per IRC comments.

Comment 17

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: address review comments

Comment 18

[[e-mail]]

Comment on attachment 242120 [details] [diff] [review]
address review comments

I'd prefer if the lines didn't move.

Comment 19

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Landed with the new lines where the old lines were.

Comment 20

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED for me using build 2006-10-14-13 of SeaMonkey trunk under Windows XP.