7842 - [4.xP] Links not functional

Status: VERIFIED DUPLICATE of bug 7839

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

Description

[Crysgem]

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?

Comment 1

[Péter Bajusz]

According to the description the problem is target="_new"
Marking as dup.

*** This bug has been marked as a duplicate of 7839 ***

Comment 2

[Crysgem]

In your judgment, [e-mail], 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.

Comment 3

[Péter Bajusz]

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.

Comment 4

[Jan Carpenter]

Verified 1999-06-15-16-M7