290577 - using css positioning removes link functionality from text link

Status: VERIFIED INVALID

(Firefox :: General, defect)

Description

[greg brant]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

using css positioning to place a link in a page results in the link not  working
in firefox. however the same link will work in IE.

if the style is applied using a class and an external style sheet or placed in
the style attribute of the <a> tag or a sorrounding <div> the link ceases to work.

here is an example

<div style="top:15px; left:400px; position:relative;">
<a href="http://www.google.com">go to google</a>
</div>

or another

<a href="http://www.google.com"  style="top:15px; left:400px;
position:relative;">go to google</a>


however if any of the three css attributes are ommited for example 
 style="top:15px; left:400px;"
or
 style="top:15px; position:relative;"
or 
 style="left:400px; position:relative;"

the link works.

it seems that this combination results in the link not working.

Reproducible: Always

Steps to Reproduce:
1.create a html page with a link with css as described above
2.
3.

Actual Results:  
the link didnt work :)

Expected Results:  
made a link to google :)

i am using firefox 1.0.3 which i just  upgraded too, but iwas also using 1.0.2
about 10 mins ago and the problem was the same there


---------- current build info------------
this build is the one i downloaded from the mozilla website

about:buildconfig

Build platform
target
i686-pc-cygwin

Build tools
Compiler 	Version 	Compiler flags
$(CYGWIN_WRAPPER) cl 	12.00.8804 	-TC -nologo -W3 -nologo -Gy -Fd$(PDBFILE)
$(CYGWIN_WRAPPER) cl 	12.00.8804 	-TP -nologo -W3 -nologo -Gy -Fd$(PDBFILE)

Configure arguments
--disable-ldap --disable-mailnews
--enable-extensions=cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,webservices,inspector,gnomevfs,negotiateauth
--enable-crypto --disable-composer --enable-single-profile
--disable-profilesharing --enable-optimize --disable-debug --disable-tests
--enable-static --disable-shared --enable-official-branding

Comment 1

[Ben Fowler]

Attachment: Testcase (not showing defect)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050416
Firefox/1.0+

I cannot see the problem you describe.

Comment 2

[Matthias Versen [:Matti]]

wfm with Mozilla/5.0 (Windows; U; Windows NT 5.2; de-DE; rv:1.8b2) Gecko/20050414

Comment 3

[Steve England [:stevee]]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050416
Firefox/1.0+

Comment 4

[greg brant]

take a look at this page
http://student1.lincoln.ac.uk/gregs-working/paper.php?pid=1&show0=true#0

the links in question are the links bottom under the comentaries heading.
the links are labeled 'show' and 'hide'


(In reply to comment #1)
> WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414
> Firefox/1.0.3
> WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050416
> Firefox/1.0+

Comment 5

[Ben Fowler]

Attachment: Testcase (with defect)

I attach a shorter version of your page which still shows the problem. You have

the pageTitle <div> stacked over the <a> element, and as expected, the content 

lower in the page is higher on the stack.

The report is probably INVALID - by design.

Comment 6

[Brad Miller]

I've run into similar problems at this page:
http://www.spelledmelk.com/archives/2005/05/bathroom_lights.html
Specifically, I'm referring to the comments section near the bottom of the page.  

For each comment, there's a white box in the upper-left corner.  This box is a
DIV element, which uses RELATIVE CSS positioning to move it slightly outside the
physical borders of its container DIV (the grey box with the actual comment).

In the white box, the commenter's name (and avatar, when applicable) should be a
clickable link.  However, where the RELATIVE-repositioned DIV intersects the
container grey-box DIV, the link is not clickable.  Only in the section of the
white-box DIV that falls outside the container DIV is the link clickable.

Specifically...  In comments where there is no avatar, only the TOP-HALF of the
commenter's name is a clickable link.  When there is an avatar, only a few
pixels on the top and left edges of the photo are clickable, since this is the
section which falls outside the container DIV.

Odd behavior.. and not reproducible in IE.

Comment 7

[Ben Fowler]

(In reply to comment #6)
> ... 
> 
> In the white box, the commenter's name (and avatar, when applicable) should 
> be a clickable link.  However, where the RELATIVE-repositioned DIV 
> intersects the container grey-box DIV, the link is not clickable.  Only in 
> the section of the white-box DIV that falls outside the container DIV is 
> the link clickable.
> 
> ...
> 
> Odd behavior.. and not reproducible in IE.

This is outside the mission of Bugzilla, and you will find more info in other
bugs and in mozillazine.

You slightly understate the case when you speak of 'intersect' and 'outside'.

Your <div> is on top of the buttons and absorbs the clicks. In the physical 
world, if you put a transparent guard over a set of controls, the
latter are visible but cannot be used.

Whilst there is a case for saying that elements that are transparent to view
should also be transparent to interaction, on balance the notion of 'stacking
order' seems to be a better one. It is possible that the standard is not
clear on this, and if you are unhappy with (or merely suprised by) Firefox's 
behaviour, you might want to check the standards and perhaps contribute to
them. What would you do with <div>s that were 0.001 transparent (or 0.999)?
What would you do with a <div> whose transparency varied over time or over 
short distances? What about plug-ins?

Firefox's view is that a <div> which overlies also absorbs.

Comment 8

[Gabriel Sjoberg]

I agree with Ben on this one.  The CSS 2.1 spec is clear on the issue of
stacking[1] and provides a mechanism for specifying how elements are to be
stacked[2].  I'm marking this bug as INVALID.

[1] http://www.w3.org/TR/CSS21/zindex.html
[2] http://www.w3.org/TR/CSS21/visuren.html#propdef-z-index

Comment 9

[Greg K.]

Verified invalid.