Closed Bug 236275 Opened 20 years ago Closed 20 years ago

Hover area for some links in absolute-positioned areas is decreased

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED DUPLICATE of bug 102695

People

(Reporter: justin-mozilla, Unassigned)

References

(
URL
)

Details

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

When approaching the Wikipedia text link from the top, the cursor doesn't change
to the hand/hover until it points nearly halfway down the font area.  This could
be due to the use of <label> which encloses "Wikipedia", or it could be due
solely to the fact that both "Wikipedia" and "Google News" are
absolute-positioned and are (too) close together.  Or it could be some other
weird issue, but those are the two causes I've thought of.

This bug is reported from Mozilla 1.6/20040113, but also occurs under Firefox
with Gecko 20040302 (today's snapshot)

This may be related to bug 65691; that's the most similar bug I could find. 
Maybe I missed one.

Reproducible: Always
Steps to Reproduce:
1. At the URL given, approach the "Wikipedia" link (in the top form textbox
grouping) from the top and the cursor doesn't change to a hand until it's
significantly below the top of the text.  It's off by at least 4-5 pixels.
2. This only happens with the Wikipedia link; Google News and Thomas (LOC) are okay.
Actual Results:  
Cursor doesn't change to hand/hover when it's over the top few pixels of the
text of the link.

Expected Results:  
Cursor should change to hand/hover when it's over the text of a link.
I'm also getting behaviour like this, in Firefox 0.9.3, with links inside an
area that uses position: absolute.  The actual clickable area of a link is the
intersection of its physical location and some other similar sized box, offset
by a few pixels.  The result is that some links are only clickable when you
hover over the top half of their text, others are not clickable at all.  They're
still in the tab order, so you can select them the old fashioned way with Tab
and Enter.  If I find out more I'll post it here; when I get a chance I'll post
a minimal test case.
Okay, I finally got un-lazy and tried to create a minimal html page that
demonstrates this.

The problem seems to be that padding area that intersects links in other
absolute-positioned divs prevents the cursor from changing.  I suppose it's
possible to argue that this is an html coding bug, but I think links should be
accessible even through other elements' padding.

The problem only occurs for links specified before the div with the padding.  I
assume, then, that the manifestation would be sensitive to z values.

<head><title>Bad CSS hover</title></head>
<body>
<div style="position: absolute; top: 20px; left: 10px; padding: 5px; border: 0;">
  <a href="http://www.whitehouse.gov">Whitehouse Home Page</a>
</div>
<div style="position: absolute; top: 35px; left: 10px; padding: 10px; border: 0;">
  <a href="http://www.senate.gov">Senate Home Page</a>
</div>
</body>
</html>
I can confirm that this was caused, in my case, by one block's padding
overlaying an earlier block's links.  So it's not a bug related to absolute
positioning per se, but rather a bug in my HTML where I wasn't being careful
enough.  The penny dropped for me when I realised that I could affect the bug by
moving my absolutely positioned footer up or down.

Moral of the story: set backgrounds on all your divs when testing; discover
bizarre coding artefacts you thought you'd deleted weeks ago!

I'd mark this closed, personally.  Nothing the Moz team can do about this,
unless there's some support for the possibility that links should "show through
" the padding of other blocks, which I think is a finicky point.  (Though IE
does let them show through.  Maybe that's a reason to work on it?)

*** This bug has been marked as a duplicate of 102695 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.