172798 - Strange underlining behaviour here in Mozilla

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Shark Daddy (Jonathan L.)]

This was originally reported on MozillaZine by one Quantum Jim, who describes
underlining problems with links and scrolling...please look at the discussion
which is more in-depth:

http://www.mozillazine.org/talkback/read.php?f=2&i=2612&t=2612

This is viewable in all the forum posts.

Anyway, there are a few problems described there whose behaviour suggests that
this is a bug on Mozilla's end. For example, upon highlighting text, it becomes
underlined.

Comment 1

[Shark Daddy (Jonathan L.)]

Hmmm...that's probably the wrong post to link to; the important part about CSS
error handling and highlighting/scrolling (the likely cause of this problem) is
here:

http://www.mozillazine.org/talkback/read.php?f=2&i=2623&t=2612

Comment 2

[Boris Zbarsky [:bzbarsky]]

The site sets:

a:hover { text-decoration: underline }

in the style sheet.  The only real problem with our rendering is that we seem to
not be showing the underline all the times when we should be, as far as I can tell.

This is when we ask for a testcase... also, this may be another
block-inside-inline issue; I'll be able to test that come Thursday, hopefully.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

a:hover does apply to named anchors.  MSIE for Windows's original implementation
of :hover as yet another link pseudoclass was incorrect.  :hover applies to all
elements, not just links.  ":link:hover, :visited:hover" should be preferred for
links.

Comment 4

[Boris Zbarsky [:bzbarsky]]

WEll, my build with the patch to bug 146409 in it seems to be behaving correctly
on this site..

Comment 5

[Shark Daddy (Jonathan L.)]

Any idea on a projected checkin date?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Probably never; we're looking at changing the design of that code to be more
robust rather than spending the rest of our natural lives plugging up buglets
like this one.

In any case, not till the tree reopens for 1.3a.

Comment 7

[Mach]

making test [e-mail]

Comment 8

[Mach]

Attachment: testcase for this bug

Comment 9

[Jim Booth]

The problem here is the <a name="top"> tag near the beginning of the page, where
the corresponding </a> is all the way at the end of the page, with other <a>
elements nested inside it.  The hover style just makes it visible, 

It seems to me Mozilla should interpret an <a> tag as implying the closing of
the previous unclosed <a>.  It appears that this does not happen when the inner
 <a> tags are INSIDE A TABLE.

If you open in Composer and move the link OUTSIDE the table, Composer corrects
the error and places the </a> before the next <a> when you switch to NORMAL
view. (Parser?)

Comment 10

[Boris Zbarsky [:bzbarsky]]

I think the parser does that on purpose because pages rely on being able to do:

<a href="foo">
<table>
</table>
</a>

And have everything in the table be a link.... (and there's no way to close out
the outer <a> once you've opened up the table, really).

Comment 11

[Boris Zbarsky [:bzbarsky]]

fixed by checkin for bug 146409

Comment 12

[Boris Zbarsky [:bzbarsky]]

*** Bug 183680 has been marked as a duplicate of this bug. ***