Closed Bug 97459 Opened 24 years ago Closed 21 years ago

window-target http header is ignored

Categories

(Core :: Networking: HTTP, enhancement)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: mozbugs, Unassigned)

References

Details

(Keywords: compat, helpwanted)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010827 BuildID: 2001082708 If I access a CGI whose output contains a "Window-target: " header, this is ignored and its output goes to the active browser window. Reproducible: Always Steps to Reproduce: Put this (nph) script in a web server's CGI directory and access it: #!/usr/bin/perl -w use strict; print "HTTP/1.0 200 OK Content-Type: text/html Window-target: _foo <HTML> <HEAD> <TITLE>This should appear in a new window</TITLE> </HEAD> <BODY> Hello World! </BODY> </HTML> "; Actual Results: "Hello World" appeared in current window Expected Results: "Hello World" should appear in a new window
over to networking:http for now
Assignee: pchen → neeti
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: XP Apps → Networking: HTTP
Ever confirmed: true
QA Contact: sairuh → tever
That seems a rather disgusting use of an HTTP header, but... whatever. Just make sure it obeys browser.target_new_blocked if you implement it, please.
Um, what? I've never heard of this header, and it would be non-trivial to implement I suspect. Does ns4 support this? Recommend WONTFIX - darin?
Window-target is supposed to be supported... see nsHTMLContentSink.cpp:4649
OK. I still say that this header is yuck, but... Anyway, the mozilla code appears to set the target for any links in this new document, not for the actual document itsself. I can't test this at the moment - does that work? I'd still like to see some form of spec for this, but I guess that that is just wishful thinking.
i think you can find a reference for it on developer.netscape.com (at least i recall once seeing a spec for it).
Target Milestone: --- → mozilla1.0
Target-Window: -header is mentioned on http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/target.html (also bug 111577)
*** Bug 111577 has been marked as a duplicate of this bug. ***
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Note that what the HTML content sink does is completely incorrect. "Window-target: whatever" does not do the same thing as <base target="whatever">. Instead it retargets the _current_ load the the window named "whatever". See bug 117948.
Note that this is a non-standard header. I'd rather see it disappear entirely, but it's not my decision...
Keywords: compat
OS: Linux → All
This enhancement has been targeted for release 1.0.1 which will probably not happen until May. I'm currently working on a project where we initially started development against Netscape using this functionality and it worked really well. We have now moved to Mozilla and this enhancement would help our development a great deal. Would it be possible to add this feature to release 1.0?
If someone has the time to do it.....
Keywords: helpwanted
Target Milestone: mozilla1.0.1 → Future
We are rolling 1.0.1 or 1.1 as our company browser, but this bug is an impediment because a number of existing pages used this functionality in Netscape 4.x and IE still supports it. Will someone be taking it up before 1.1 branches? The fix seems to be languishing.
David, there is no fix that is languishing, since there is no fix... doing this would require some interesting architecture work on the load targeting code; I can pretty much guarantee that it's not happening for 1.1 (unless someone who really needs this actually _does_ it). Note the "helpwanted" keyword....
About comment 14: does this work in internet Explorer? I've tested right now in IE5.5 and I've been unable to make it work.
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
I'd very much like to see this bug fixed.
(In reply to comment #18) > I'd very much like to see this bug fixed. I would really love to as well. Unfortunately there is a lot of documentation online that has this as a possible fix (actually listed as the preferred way) to get your page "unframed." This should be similar to whatever code works for the form tag with a target specified. This would be handy to see once more. It looks like it used to work well, and then browsers stopped supporting it. I can not get this to work either as an actual ASP header, or as an equiv tag in IE 6, FireFox 1PR, or Opera 7.6. Does anyone know when it stopped being supported?
It's never been supported in the Mozilla codebase, as far as I can tell. So it stopped being supported with Netscape 4. Given that neither IE nor opera support this, there is no compat issue either. Wontfix.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
V/wontfix.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.