Closed Bug 8470 Opened 26 years ago Closed 25 years ago

[Webshell] [beta] Fix resolving of frame targets

Categories

(Core Graveyard :: Tracking, defect, P2)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 17468

People

(Reporter: csbooton, Assigned: travis)

References

()

Details

On this section of one of my sites I have a whole bunch of pictures. To make the viewing of the pictures easier, I have used a <base href="new"> so thjat when clicking on the image thumbnails, the full sized image will open in a new window. But since it doesent work (the new window never openes) I cannot view the image. This works in 4.5 and in IE 5 (which I only use for testing purposes. So I'm not a traitor). I called it a blocker as this error blocks a major part of viewing my site. I made it so that pictures open in new window to make naviagtion of the pictures area easier and more efficient.
cool site ;-) I just tried clicking on several tumbnails of daisy using the 990616 build on win95 and it they all seem to work ok. which build are you using?
I'm using the 1999061709 build under win98
Component: other → Apprunner
QA Contact: leger → claudius
claudius - can you reproduce on Win98? if a good bug, don who gets it?
... Possibly related to Bug 7839, as a generalization.
more likely nisheeth or rickg.
It seems to be working now in build 1999061808. But it openes in the samw window instead of a new window, but the same happenes in 4.5 and IE , so I think that somehow xoom's server is messing things up.
Cancel that, when I went to the version on my hard drive and clicked on the pictures nothing happened. On 4.5 it will open the picture in a new window.
I just took a look and these pages work fine for me on the 1999061908 Win98 build. Yes, they open into the smae window but I believe that is a seperate, known, issue. A little later I'll take the pages down and try them locally to see if it makes a difference.
Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.
I was in ring managment for a webring I run and when in queue managment if you click on a link to go to a site that anting to join your ring the link will open in a window (or at least if it works it will), anyway trying to do it in the 1999062208 build causes this error in apprunner to be displayed: nsDocumentBindInfo::OnStopBinding: Load of URL 'http://www.flex.net/~lonestar/st ripedskunk.htm' failed. Error code: 1 as a result of this the site never opens.
I checked the URL (http://www.flex.net/~lonestar/stripedskunk.htm) and it works out fine, so were not dealing with a 404 type error or an invalid site error. Just thought I'd let you know, also to add to this a little bit after trying the link and failing several times, apprunner crashed with raptorhtml.dll , I think it was a GPF or IPF , since I did not get a talkback I wasent sure, I would have coppied the crash message but could not as I already has the apprunner error message in the clipboard.
Assignee: chofmann → nisheeth
nisheeth, do you know if <base href="new"> is supported yet?
I have something to add; When I do click on a link that should load in a new window and it does not and as a result nothing happenes, If I look at my DUN status window at this point , it seems to indicate that the page is loading but has no where to be displayed.
It's looks as if my bug may be invalid as I just read that <target="new"> is illegal in html 4.0 and they say to use <target="_blank"> instead, so if this is the reason for a new window not opening then the bug is invalid. Apparently the correct behavior would be to open it in the same window. When viewing it locally it will open it in a new window which is apparently not correct as per html 4.0. However if I use as started above <base target="_blank"> then the links that use this will open in a new window.
I checked it with <base target="_blank"> and it opens each one in a new window, even the ones where I say target="_top">, however on IE 5.0 and NN 4.5 , it will load the links where I say target=_top in the same window but ones without it in a new window, which seems to be correct.
Status: NEW → ASSIGNED
Summary: <base target=> tag does not work → Fix resolving of frame targets
Target Milestone: M11
http://www.w3.org/TR/REC-html40/present/frames.html#h-16.3.2 outlines the semantics of the target attribute. Based on that description, I think that the the presence of <BASE target="new"> in a window titled "foo", should force the first link click in "foo" to load the linked resource into a new window titled "new". All subsequent link clicks in "foo" should load the resource into "new". Setting target milestone to M11 for this.
Severity: blocker → critical
per the new strategy since this bug does not block the current milestone and is slated to be fixed M11 I am backing the severity down to critical.
Summary: Fix resolving of frame targets → [Webshell] Fix resolving of frame targets
Bul re-assigning webshell bugs to the new webshell owner, Scott Collins. Scott, please adjust the target milestone assignments as you see fit. Thanks.
Priority: P3 → P2
Summary: [Webshell] Fix resolving of frame targets → [Webshell] [beta] Fix resolving of frame targets
Target Milestone: M11 → M12
many web sites will not work correctly with this bug. marked [beta], set milestone, priority and severity. There may be quirks vs. standards issues involved here. backwards compatibility for quirks mode is critical for beta.
Blocks: 14469
Blocks: 15160
No longer blocks: 14469
(Mass-) Re-assigning [Webshell] bugs to travis, on the advice of dp, et al. Many of these may be invalid in the new world of the re-written webshell, but he certainly needs to be aware of these issues. Hope this helps you, travis.
Status: NEW → ASSIGNED
Depends on: 13374
*** Bug 18465 has been marked as a duplicate of this bug. ***
Is this the same as bug 17468 (which has a fix attached to it)?
Move to M13 and re-assess once basic Webshell re-design is complete.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
dbaron, yes, it its a dup of 17468. *** This bug has been marked as a duplicate of 17468 ***
Status: RESOLVED → VERIFIED
Verified this is a dupe of dup of 17468. Both bugs are frame targeting bugs for creating a new window. The summary for 17468 is [WebShell] links w/target attribute do not create new window when clicked the related description is also the same. Marking verified Dupe.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.