Editor underlines named anchors but browser doesn't when anchor is not terminated




19 years ago
19 years ago


(Reporter: jruderman, Assigned: attinasi)


Windows 98

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2+][Fix In Hand], URL)


(1 attachment)



19 years ago
The editor underlines text inside <a name=> tags, but the browser doesn't.  I 
think not underlining is the correct behavior but I'm not sure.

See http://bugzilla.mozilla.org/showattachment.cgi?attach_id=6464 for an 

Other bugs that use the same testcase:
Bug 31592, named anchor image on each line and overlaps text
Bug 31588, text inside named anchor functions as link to anchor.

Comment 1

19 years ago
reassign to cmanske
Assignee: brade → cmanske
Target Milestone: M17


19 years ago
Ever confirmed: true
Summary: Editor underines named anchors but browser doesn't → Editor underines named anchors but browser doesn't when anchor is not terminated

Comment 2

19 years ago
*** Bug 31588 has been marked as a duplicate of this bug. ***

Comment 3

19 years ago
The test case is definitely incorrect HTML. The correct HTML syntax for named 
anchor should always have </a> immediatley following the <a>. 
Thus the "bug" is in the behavior of the parser, which should fixup bad HTML.
The parser should automatically "insert" the </a> when it detects a <a name=...>
tag that isn't terminated.
It isn't clear why there is a difference between the browser and editor.
Assignee: cmanske → rickg


19 years ago
Component: Editor → Parser


19 years ago
Blocks: 31592

Comment 4

19 years ago
This doesnt make sense to me. The parser does close the <a> when the document 
ends (it would do so earlier if it needed to). Named anchors don't get 
underlined -- so there's no bug here. Back to charlie for me info or to close.
Assignee: rickg → cmanske

Comment 5

19 years ago
But shouldn't named anchors get closed immediately, and NOT at the end of 
the document as a <a href=...> (i.e., link) should?
The real mystery to me is why it doesn't look underlined in browser, but it
does in editor. We are using the same layout!
If you load the page in Composer, then use Debug | Dump Content tree, you will
see that the <a> is closed just before the table, then redistributed around
the lines after the table. That is the behavior I would expect for auto-closing
a link. Note that this content tree is exactly what we receive from the parser,
right, Akkana? Do you have an equivalent way of seeing the content from
the browser so we can see if the content tree is the same there?

Comment 6

19 years ago
The full browser has no equivalent way AFAIK, but viewer has a debug menu to
dump the content tree.  Try viewer.

Comment 7

19 years ago
This is a parser or layout problem. Don't have time to play with it now.
Target Milestone: M17 → M20

Comment 8

19 years ago
just filed a related bug, 40078.

perhaps the test case there might be helpful here, it's much more minimal...


Comment 9

19 years ago
There is one very simple solution, in my opinion: The parser should immediately 
terminated the <a> node (effective "inserting </a> " when content is written 
out) after encountering <a name="foo"> if there is no "href" attribute (a dual 
anchor/link which is a silly thing to do, but I suppose is legal.) 

Comment 10

19 years ago
Charles, the spec is clear: <a> can contain inline elements in html4.0, and 
navigator even allows <a> to contain certain block-level elements. The parser is   
performing correctly. Your proposal would violate the spec and backward 
compatibility behavior.

Comment 11

19 years ago
Rick: I realize that now. So do you have any idea why the content in the named
anchor is underlined as if it were a link *only* in Composer?
If you click on the "Edit Preview" button at the bottom of Composer's content
window (you will have to uncollapse the toolbar to display those buttons),
you are in a mode where there is no extra style except for this (from
/* Override the browser's pointer cursor over links */
a:link, a:visited, a:active, a:out-of-date {
  cursor: text;

/* We want the default arrow when hover over the 
   various objects, such as the image that 
   represents the named anchor
a:link img, a:visited img, a:active img,
a:out-of-date img, img[usemap], 
a[name] {
  cursor: default;
And I even tried deleting those styles just to be sure, and we still get the
underlining of content even though there's no "href" set.
So it's probably not a parser or editor bug, but something in layout/CSS.
Reassigning to Rick to find the right engineer.
Assignee: cmanske → rickg

Comment 12

19 years ago
Thanks for CC'ing me. Rick will probably appreciate that I am taking this one - 
it sure smells like a style issue.
Assignee: rickg → attinasi

Comment 13

19 years ago
This is a bug in the SelectorMatches function. We test for the link to have an 
HREF but when it does not have one we end up considering it as non-visited!

The change is extremely simple - we need to check the result before going out 
to the link handler... I'll attach the patch.

Comment 14

19 years ago
Created attachment 9390 [details] [diff] [review]
Patch to fox the bug: it looks big but it is just a new if(){}

Comment 15

19 years ago
I'm nominating this for nsbeta2 because the fix is extremely simple (check for 
error where it shuld have been all along) and the editor will benefit greatly 
from this (it looks silly to underline named anchors with no href...).
Keywords: nsbeta2
Whiteboard: [Fix In Hand]
Target Milestone: M20 → M16
Summary: Editor underines named anchors but browser doesn't when anchor is not terminated → Editor underlines named anchors but browser doesn't when anchor is not terminated

Comment 16

19 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [Fix In Hand] → [nsbeta2+][Fix In Hand]

Comment 17

19 years ago
Fixed. (nsCSSStyleSheet.cpp)
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 18

19 years ago
this is a parser/layout problem...qa_contact assign to gerardo for his group...
QA Contact: sujay → gerardok


19 years ago
QA Contact: gerardok → petersen

Comment 19

19 years ago
Fixed in the June 09 M17 build (2000060908).
You need to log in before you can comment on or make changes to this bug.