Closed Bug 7842 Opened 26 years ago Closed 25 years ago

[4.xP] Links not functional

Categories

(Core :: DOM: HTML Parser, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED DUPLICATE of bug 7839

People

(Reporter: Crysgem, Assigned: rickg)

References

()

Details

Apprunner Build ID: 1999060808 The external links nearer to the end of the page are not translated by the beast, which has refused to do so for some time (I cannot recall an era in which it did). Is the "Target=New" attribute of <A HRef> implemented?
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
According to the description the problem is target="_new" Marking as dup. *** This bug has been marked as a duplicate of 7839 ***
In your judgment, hyp-x@inf.bme.hu, is the "_Blank" attribute of Target so tautological to "_New" that this bug should be marked Duplicate? I know not enough to render cusp; my knowledge of HTML is too limited. Certainly "_Blank" seems functionally equivalent to "_New". It is the "_Blank" tags which Mozilla does not interpret.
Sorry If my comments and markings wasn't clear. This mignt happened partly because I read the bugs in the order in which they was entered. I read your case reported as bug #7839 and I was trying to make a simpler testcase. I realized that the while the document had <base target="_new"> as you kindly pointed out, only one of the links was non-functional. So the base tag was not the only reason. Other links did function because they had a target=... attribute which overrided the target attribute given by "base". So the only link that did not function was because it inherited the target="_new" attribute. I made a modified document to test if the link non-functioning is caused by the target attribute. I finally came up with the simplest testcase I could made, and I posted it to that bug. target="_new" should not load the page in the current window, but should open a new one. I think that functionality is yet to arrive in mozilla, so I thought this is more of a missing feature, than a bug in the parser. (But I leave this to the engineers to decide.) So only after that I came to this bug, and realised that in practice this is the same problem with target. If I read both bug before commenting, I would have posted a remark to bug 7839 about the inherited target attribute and would have marked that bug a duplicate of this one. But it didn't happened that way. I'm sorry that created confusion. Notice however that bugzilla has a verification system. If someone wildly goes and resolves a bug, it's up to the QA or the reporter to verify whether the resolution is in fact correct. If it's not the bug can be reopened. I'm sorry for the spam, but I wanted to clear up the matter.
Status: RESOLVED → VERIFIED
Verified 1999-06-15-16-M7
You need to log in before you can comment on or make changes to this bug.