30553 - targeted links miss b. haven...

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P2)

Description

[chris hofmann]

win32 3/4 build
go to a page like
http://komodo.mozilla.org/buster/pagelist.html
which has several different sites set up to load
into a second window "test_win" if you click on a link.

<a href="http://www.yahoo.com" TARGET=test_win>click to http://www.yahoo.com 
</a>
<a href="http://www.netscape.com "TARGET=test_win>click to 
http://www.netscape.com </a>

clicking on anyone of this links works the first time,
but following attempts to get one of the next sites to
load into the second window result in just loading 
a blank white page...

we should release note this for beta1 if we can't fix.  help sites,
and sites with lots of indexed content use this 
as a way to keep the index available and allow drilling down
on details.

wondering if this is a hard architecture issue of simple fix?

try travis as a start for assignee..

Comment 1

[chris hofmann]

should review and relnote if nothing else for beta1. added keyword.

Comment 2

[leger]

travis, can you give PDT more info on this bug please?

Comment 3

[Asa Dotzler [:asa]]

Is this really a Browser General Bug.  If not, could one of you re-assign it to
the appropriate component.  Thanks.

Comment 4

[Phil Peterson]

[PDT+] w/b minus on 3/10

Comment 5

[don]

Yep, i can repro this allright.  Travis, is this a webshell bug?  If not, who
should get this?

Comment 6

[travis]

Ok, so here's the deal with this bug.  The window that is created by the uri 
loader when a target is specified is not setting the target name properly on 
the window that is created.  The soon to be attached patch addresses this 
problem.  It however uncovers another problem. URI loader is using the hidden 
window to do the creation of the window.  This is bad because it breaks viewer 
and also ends up with the wrong opener set on the window.  The opener should 
really be the one from which the link was clicked (I think, danm, correct me if 
I am wrong here.)  Because hidden window is the one doing the creation, it is 
the one that the size is based on.  So applying this patch, you will find it 
does indeed work, but comes up in a very very small window.  I'm reassigning to 
mscott so he can change the browser instance ContentHandler to take the 
windowContext that started the load and also review and apply my patch.

Comment 7

[travis]

Attachment: Fixing the open to properly set the windowName

Comment 8

[Scott MacGregor]

Travis, I'm not quite sure how your patch works. You take away the specification
of which chrome url to run.

If this content handler was invoked because you clicked on a url in the mail
window, how will we create the correct browser window with your changes? There's
no mention of the browser chrome url anymore in the JS arguments we package up
after your changes.

Comment 9

[Scott MacGregor]

I believe i have a fix for my part of this bug where the content handler needs
to create the new window using the dom window from the window that originated
the url request. I'm testing that out right now.

Comment 10

[Scott MacGregor]

Okay I have a fix for this ready to go. Reviewed by travis. I just need to get
PDT approval.

Comment 11

[Scott MacGregor]

One negative side effect of this patch is if you click on a url in the mail
window and it requires us to create a browser window, the browser window
inherits the dimensions of the mail window.

This looks weird (at least on my machine) because my mail window is usally wide
and short. Where a browser window is usually long and more narrow due to the
nature of the UIs.

Before my changes for this bug we would have gotten the dimensions from the
hidden window which for some reason looked more normal.

Comment 12

[Scott MacGregor]

Attachment: Includes my part of the fix and Travis's fix.

Comment 13

[travis]

Actually, we were getting the size from the intrinsic sizing of the 
navigator.xul file, not the hidden window.

Comment 14

[Scott MacGregor]

Ahhh that explains why it looked better before our changes than after when
creating a browser window from mail.

Comment 15

[Scott MacGregor]

Attachment: Travis's additional patch for the window size problem I mentioned.

Comment 16

[Scott MacGregor]

Okay Travis just gave me a patch for the global window which fixes the window
size problem the first patch would have introduced. new windows are now coming
up with the appropriate window sizes. Now we are really good to go.

Comment 17

[Scott MacGregor]

Fix checked in. Chofmann, run your buster page!!! =)

Comment 18

[chris hofmann]

you folks rock!

Comment 19

[travis]

Do we get donuts?

Comment 20

[chris hofmann]

you can hope.  watch under your christmas tree in the morning..

Comment 21

[Scott MacGregor]

Sweetnes...thanks chofmann. anytime you have a special bug you need fixed, just
let us know =). The doughnuts are quite tasty...

Comment 22

[leger]

Looks great with 2000-03-08-13-M15 build.  Marking Verified