The default bug view has changed. See this FAQ.

Style "a:hover text-decoration:underline' works intermittently

ASSIGNED
Assigned to

Status

()

Core
Layout
P3
major
ASSIGNED
16 years ago
8 years ago

People

(Reporter: Travis Saling, Assigned: dbaron)

Tracking

({css2})

Trunk
Future
Other
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [CSS1-2.1][CSS1-5.4.3], URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
The URL I gave is for demo purposes - I've seen this happen on other pages as
well (note that the navigation links on the left side aren't supposed to "hover
underline", but the other links on the page are).

When you have a style that indicates a link you're hovering over should be
underlined, Mozilla does not always render it - sometimes the underline appears,
and sometimes it doesn't. It does consistently reflect the color attribute
correctly though, so it's recognizing the hover state.

I've tried it with both 0.9.4 and 0.9.5 and gotten the same result. The pages
work correctly in Internet Explorer, so I'm sure the CSS is coded correctly.
(Assignee)

Comment 1

16 years ago
Don't be so sure the CSS is coded correctly.  IE has a bug where it gives :hover
a higher specificity than other pseudo-classes, or something like that.  See
http://www.people.fas.harvard.edu/~dbaron/css/1999/09/links .  Is that the
problem here?
(Assignee)

Comment 2

16 years ago
Or could the problem be that the line below is obscuring part of the underline?
 (Although the problem that I can think of that would have caused that would
have been fixed before 0.9.5, and I think also before 0.9.4, although I'm less
sure of that).

I don't see any problems on a current Linux build. 
(Reporter)

Comment 3

16 years ago
> ------- Additional Comments From dbaron@fas.harvard.edu  2001-11-08 16:59
> Don't be so sure the CSS is coded correctly.  IE has a bug where it gives :hover
> a higher specificity than other pseudo-classes, or something like that.  See
> http://www.people.fas.harvard.edu/~dbaron/css/1999/09/links .  Is that the
> problem here?

I'll try not to take it personally, since I wrote the styles on that
page I used for a demo.  ;-)  Hey it's possible, I'll admit I'm not
perfect...

But I think there's a few problems with this.  First, I believe this
USED to work correctly in Mozilla on Linux. Second, it works correctly
in Opera on Linux, and it works as expected in Netscape 6 on Windows (I
have mozilla 0.9.5/Windows at home, and I'll check that ASAP). Third, on
a link that wraps over several lines (on that page I originally gave, there's
one link whose text reads "Where are the leaders in the post-PC revolution?"),
some parts of that single link get underlined and some parts don't. The style
doesn't vary within a single link, obviously.
(Assignee)

Comment 4

16 years ago
Could you attach a screenshot of the problem?
(Reporter)

Comment 5

16 years ago
Created attachment 57161 [details]
screenshot of the problem

Unfortunately the mouse doesn't appear in the screenshot, but you'll see the
effect I'm talking about in the lower right section ("where are the
leaders...").
(Assignee)

Comment 6

16 years ago
Do you know what font that text gets displayed in?  (TrueType, bitmap,
Postscript, etc.?)
(Reporter)

Comment 7

16 years ago
The font is "Lucida".  The style declaration I'm using is

font-family: Lucida, Helvetica, Arial, sans-serif;

But I don't really know enough about how Red Hat 7.2 manages fonts to tell you
whether it's using True-Type, Type 1 or whatever, because I don't see a likely
file in any of my font directories - unless it's one of Abiword's
cryptically-named font files.

Anyway, Lucida seems to be the issue. I set up a test page whose only difference
is the removal of the Lucida font-family style entry, and the problem disappears:

http://www.ee.washington.edu/index-test.shtml

Since Windows browsers don't seem to be using Lucida anyway, I'm moving the
"problem" page that uses Lucida (just in case you need to check this) to

http://www.ee.washington.edu/index-lucida.shtml

I'm going to pull Lucida out of my default style sheet, so the original URL I
gave in the opening report will soon not reflect the problem anymore.

BTW this does seem to be a Linux-only issue, probably because of the font. On
Mozilla 0.9.5/Windows this problem doesn't occur.

Travis





Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 8

16 years ago
Does the problem get better if you somehow obscure the window and cause it to
repaint while keeping the link in the :hover state?  (Maybe an easier thing to
test would be if the underlines show up properly if they're the non-:hover style.)
(Assignee)

Updated

15 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
(Assignee)

Comment 9

15 years ago
This wasn't the bug I meant to accept.
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.9 → ---
Whiteboard: [CSS1-2.1][CSS1-5.4.3]
(Assignee)

Comment 10

15 years ago
I suspect this could be an invalidation problem when the underline is outside
the bounds of the text frame.  I see a similar problem for the edge of the "r"
in attachment 1810 [details] (on bug 5693, with my fix for bug 5693).
In which case the fix for this might be similar to the fix for 'outline'.
(Assignee)

Comment 12

15 years ago
Bug 136935 is about a similar problem on windows (a regression due to recent
changes), although the fix for that is likely not to be useful here.  I never
know, though.  (This, in fact, could be a regression from my font metrics
changes that prevented text frames from overflowing their containers, bug 91794.)
(Assignee)

Updated

15 years ago
Severity: normal → major
Status: NEW → ASSIGNED
Component: Style System → Layout
Priority: -- → P3
Target Milestone: --- → Future
am I to stupid to see it? ;)

Linux, 2002070508 and no problem!
(Assignee)

Comment 14

15 years ago
This is expected to be unreproducable on most machines.
It's happening to me in build 2003082704, on windows 2000. The css i'm using is:

a:link {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: 10pt;
	color: #FFFFFF;
	text-decoration: none;
}
a:visited {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: 10pt;
	color: #FFFFFF;
	text-decoration: none;
}
a:hover {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: 10pt;
	color: #FFFFFF;
	text-decoration: none;
}
a:visited:hover {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: 10pt;
	color: #FFFFFF;
	text-decoration: underline;
}
a:active {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: 10pt;
	color: #FFFFFF;
	text-decoration: none;
}

Then i've a page with the following code:

<a href="link1.html">link1</a>
<a href="link2.html">link2</a>

Of notice, the link1.html exists in the same directory as the page that contains
the html. link2.html doesn't exist at all.

What i've observed is that the first link will appear underlined when the mouse
overs it. BUT link 2 will stay in normal (no underline at all).

The last comment is almost certainly caused by the fact that the style rules ask
for underlining only when the link is visited.

Comment 17

14 years ago
Is this still a problem?

Comment 18

13 years ago
(Win2k, Firefox 0.8) - I get this problem too when I use a font-size of 75% with
a padding-top value of less than 1em or a line-height value of less than 1.5em.
At larger font sizes (16px) a short underline may appear on wrapped lines. It
doesn't happen on every line and if you change em values from say .8 to .99 the
affected lines may change.

I can't see any obvious relationship to the shape of the font (e.g. descenders),
but it only happens with my monospaced font ("Courier New").
is bug 249402 a dupe of this?

Comment 20

13 years ago
*** Bug 270961 has been marked as a duplicate of this bug. ***

Comment 21

13 years ago
Testcase from the bug that was duped to this one:
https://bugzilla.mozilla.org/attachment.cgi?id=166572&action=view

Updated

12 years ago
Keywords: css1
(Assignee)

Updated

12 years ago
Keywords: css1 → css2
Is this still an issue now on trunk?
(Reporter)

Comment 23

10 years ago
I don't think it's been a problem for a while, even though it doesn't appear anyone worked on it directly. I can't see the problem on the original test page: 

http://www.ee.washington.edu/index.html-lucida
Yeah, unfortunately that happens. Bugs that get worksforme without any developer working on it.
Anyone else who saw the bug, can he also test?
QA Contact: ian → layout

Comment 25

8 years ago
I think we can close this one. It appears to be working correctly for me too, with Firefox 3.5.3 on Mac.
You need to log in before you can comment on or make changes to this bug.