42175 - non-working link shown if "=" missing between HREF and value

Status: RESOLVED WONTFIX

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

Description

[Sean Richardson]

Overview:
Links coded with no "=" between HREF and its value (the result of a typo or a 
momentary lapse of concentration) are displayed as links even though they are
inoperable.

Steps to reproduce:
1. View the testcase (to follow)
2. Click on link (2).
      Actual Result: throbber activates, nothing else happens
      Expected Result: (2) is not a link, displayed like (6)
3. Hover over link (2).
      Actual Result: the status bar displays the URL of the testcase,
          not the URL of the value
      Expected Result: the status bar is quiescent as (2) is not a link
4. Copy the word "anchor" to the clipboard.
5. Right-click on link (2), select "Copy Link Location".
      Actual Result: no selection is made (paste to verify)
      Expected Result: "Copy Link Location" does not appear on the context menu.
6. View Source for the testcase:
      Actual Result: code for link (2) appears as:
          2. <A HREF"http://www.mozilla.org/"> ...
      Expected Result: code for link (2):
          is highlighted in some way to show syntax problem   ...or...
          does not show a value for the HREF ...or...
          is fixed up with "=" to make the attribute functional.

Tested with:
2000-06-08-15-M16 nightly binary on WinNT
NN 4.7 on WinNT (gives expected results)

Additional Information:
Here is another case where the user will expect Mozilla to protect him or her
from bad page authoring. A user's naive reasoning  -- "if it looks like a link, 
it ought to work, and contrariwise, if the link won't work it shouldn't appear 
as a link" -- is unlikely to be amenable to arguments, excuses, or buck-passing,
however much the bad code is Sombebody Else's Problem.

The ideal solution from the user's point of view would be to link the 
value immediately following the HREF attribute name to it in the DOM 
as if "=" had appeared, but if that isn't practical, the <A> should not 
appear to be a link.

Note also that links defined as "<A HREF="">", "<A HREF=>", or "<A HREF>"
(links (3), (4), and (5)) also appear to be links. Any of these might be 
assigned a value by DOM manipulation later, but as they stand they will not be 
operable from the user's point of view. This isn't a parser problem though;
filing another bug for that.

Charles, step 3 appears to be another way to trigger bug 40197, "Named anchor 
node is returning bogus "href" value", which is otherwise fixed. It probably
makes sense to fix this bug, though, rather than reopen bug 40197 to handle
this edge (this should never happen) case.

Comment 1

[Sean Richardson]

Attachment: A HREF with badly specified or no attribute value

Comment 2

[rickg]

I'm not inclined to fix this problem. I'll check the spec to see what it says, 
but in the absence of a strong requirement, I'm planning to leave this behavior 
as is.

Comment 3

[rickg]

This bug has been marked "future" because the original netscape engineer 
working on this is over-burdened. If you feel this is an error, that you or 
another known resource will be working on this bug,or if it blocks your work 
in some way -- please attach your concern to the bug for reconsideration. 

Comment 4

[Jesse Ruderman]

I don't think "missing equals sign between href and url" should be special-
cased.  It should be treated the same way as missing href, or href="", or 
whatever it would normally end up being treated as.  (This bug might be a 
duplicate of another bug about what happens when an A tag has a missing or 
empty href.)

Comment 5

[rickg]

Marking won't fix. The fact is that it IS an anchor, and layout is free to treat 
it as it see's fix. Fixing up the broken HTML attribute would not be advised, as 
it can't be differentiated from an attribute without a value.

Comment 6

[bsharma]

updated qa contact.