Closed Bug 30553 Opened 20 years ago Closed 20 years ago

targeted links miss b. haven...


(SeaMonkey :: General, defect, P2)

Windows 95


(Not tracked)



(Reporter: chofmann, Assigned: mscott)




(Whiteboard: [PDT+] w/b minus on 3/10)


(3 files)

win32 3/4 build
go to a page like
which has several different sites set up to load
into a second window "test_win" if you click on a link.

<a href="" TARGET=test_win>click to 
<a href=" "TARGET=test_win>click to </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..
should review and relnote if nothing else for beta1. added keyword.
Keywords: beta1
Summary: targeted links miss b. haven.. → targeted links miss b. haven...
travis, can you give PDT more info on this bug please?
Whiteboard: [NEED INFO]
Is this really a Browser General Bug.  If not, could one of you re-assign it to
the appropriate component.  Thanks.
[PDT+] w/b minus on 3/10
Whiteboard: [NEED INFO] → [PDT+] w/b minus on 3/10
Yep, i can repro this allright.  Travis, is this a webshell bug?  If not, who
should get this?
Priority: P3 → P2
Target Milestone: M14
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.
Assignee: travis → mscott
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.
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.

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

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.
Actually, we were getting the size from the intrinsic sizing of the 
navigator.xul file, not the hidden window.
Ahhh that explains why it looked better before our changes than after when
creating a browser window from mail.
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.
Fix checked in. Chofmann, run your buster page!!! =)

Closed: 20 years ago
Resolution: --- → FIXED
you folks rock!
Do we get donuts?
you can hope.  watch under your christmas tree in the morning..
Sweetnes...thanks chofmann. anytime you have a special bug you need fixed, just
let us know =). The doughnuts are quite tasty...
Looks great with 2000-03-08-13-M15 build.  Marking Verified
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.