Open Bug 102695 Opened 23 years ago Updated 2 years ago

[EVENTTARG]Treat some transparent elements as "transparent to events"

Categories

(Core :: Web Painting, defect, P3)

Product:
Core
Component:
Web Painting
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: timonchristl, Unassigned)

References

(Blocks 3 open bugs,
URL
)

Details

(Keywords: testcase, Whiteboard: WONTFIX? (Opera: DSK-127398) [webcompat])

Attachments

(7 files, 2 obsolete files)

simplified testcase
588 bytes, text/html
Details
This makes IE do the same as Mozilla. View in IE only. Post number 91.
669 bytes, text/html
Details
sorry, this is the correct testcase
1.73 KB, text/html
Details
Testcase demonstrating comment 87 and showing that comment 111 is wrong
178 bytes, text/html
Details
possible forms testcase
848 bytes, text/html
Details
a simplified float testcase with borders drawn
1.03 KB, text/html
Details
Very simple test case
1.05 KB, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091311

Most of the links on the page cannot be clicked. Also the cursor shape does not
change into a hand symbol.

It works with Netscape 4.76 and Opera 5 in Linux.


Reproducible: Always
Steps to Reproduce:
1. Go to that URL
2. Click on a link and see


Actual Results:  No page change occurs.

Expected Results:  http://bot.counter-strike.net/realbot/downloads.html should
have been opened.
thats in general very bad code loads of none/wrong closed div/table/font tags,
<meta-http-equiv is totally wrong and could screw up things.
I see the described symptom with build 2001100203 on Windows 95

The page's source si a mess, but it looks like the problem is being caused by a
<div> tag with position:absolute;

I will attach a simplified testcase stripped from
http://bot.counter-strike.net/realbot/index.html
Attached file simplified testcase — 

    
    

    
  
Confirming -> Layout
Assignee: asa → attinasi
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
Keywords: testcase
QA Contact: doronr → petersen
Summary: Links cannot be clicked → Links fail to work in span after abs. positioned div

    
    

    
  
Links do not with N6.2 on WINNT. Setting OS: All
OS: Linux → All
Target Milestone: --- → mozilla1.0.1

    
    

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

    
    

    
  


  
Summary: Links fail to work in span after abs. positioned div → [EVENTTARG]Links fail to work in span after abs. positioned div

    
    

    
  
Attachment 64641 [details] is a duplicate of bug 13213, but attachment 51728 [details] is a request
that we consider transparency in event targetting, since if that absolutely
positioned DIV had a background-color, it would cover up all the links. 
Considering transparency might be good, and we'd have to do it if we stopped the
3-pass floater painting, which will be allowed by future versions of the CSS
spec (which is essentially what MacIE5 does now, except in the presence of
floaters).

    
    

    
  
Actually, though, since that DIV doesn't have a z-index, it wouldn't paint on top.

    
    

    
  
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future

    
    

    
  
ViewManager bug. Reassigning.
Assignee: attinasi → roc+moz
Component: Layout → Views

    
    

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

    
    

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

    
    

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

    
    

    
  
dbaron, tell me what to do here. Considering transparency in event targeting is
probably easy to do, but I'm not completely sure what it means. What exactly
should be considered "transparent" for the purposes of event targeting?

For starters, perhaps the following could be treated as event-transparent:
-- nsBlockFrames with transparent background

hmm ... any others? note that the block frame's inline children would not be
transparent so if the user mouses over/clicks on them, it's OK.

    
    

    
  
Well, the way it would have to be done is changing GetFrameForPoint.  The
problem with doing that is that it would break :hover for things that are
transparent.  Then again, we'd want it to break :hover, since the events
wouldn't go to the element.  But what would happen for mouseout/mouseover?  What
do other browsers do?

    
    

    
  
How about this proposal then:

An event is considered targeted at a block frame only if its position is inside
one of the block's line boxes or the frame's background is not transparent.
Otherwise the event falls through to the next frame in z-order.

    
    

    
  
IMHO we shouldn't consider transparency. Anything within the clipping area of an
element should go to that element. Doing anything other than that is opening the
door to a slippery slope to hell. (Just think of an animated semi-transparent
MNG background. Do we let the clicks in while and where the background is
transparent? Think of all the other possible extensions to this. It's insane.)
Whiteboard: WONTFIX?

    
    

    
  
At one point I raised a related question with the CSS WG (the question there was
whether hover events should apply to 'visibility: hidden' elements) and was told
that invisible elements shouldn't respond to events, whereas translucent and
opaque elements should.  Which means, of course, I could set an element to have
an opacity of 0.001% and have it respond to events without being visible to
humans, but there you have it.  If the question hasn't been resolved a different
way in the meantime, it may be worth it to bring the question up somewhere and
try to get a different answer.  Personally I agree: if an element has a clipping
area, then events within it should apply to that element.  But that wasn't the
answer I got.

    
    

    
  
We currently consider 'visibility' but not transparency.

    
    

    
  
I think restricting event hitting to line boxes would deal with the vast
majority of confusing cases without taking more than a little step down the
slippery slope. I've certainly confused myself a few times with explicitly sized
elements that ate up all the events.

On the other hand, I can see that any definition would be contentious, and there
don't seem to be enough dups that this is a big backward compatibility issue.

Thinking a bit further out, it would be nice if there was a way to specify in
CSS that an element should be transparent to events. I don't think there's any
way to achieve this in CSS3 or DOM2.

    
    

    
  
Here's another testcase that shows how this can be difficult to understand. It
wasn't immediately obvious to me why the IFRAME wasn't getting events...

http://bugzilla.mozilla.org/attachment.cgi?id=98941&action=view
Summary: [EVENTTARG]Links fail to work in span after abs. positioned div → [EVENTTARG]Treat some transparent elements as "transparent to events"

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
With windowless plugins the case may be more clear cut. The plugin can process
or ignore the event and indicate this via the return value of NPP_HandleEvent.
If it doesn't process the event then the event could propogate to an underlying
frame. See bug 182299. This covers some of the bugs that have been duped to this
one, e.g. bug 178569

    
    

    
  
David, are windowless plugins guaranteed to process the event if I, say, click
on an opaque part of the plugin?  Because we absolutely do not want to propagate
anything to a part of the page the user cannot see.

    
    

    
  
No, unfortunately they are not guaranteed to do that. Although, given that there
are only a couple of windowless plugins in existence that I know of (viewpoint
and flash) and both are experiencing this problem, we could change the rules and
make it guaranteed.

    
    

    
  
I wouldn't object to doing this for plugins.

    
    

    
  
for plugins, we get an nsIDOMEvent through nsIMouseListener. How to redispatch
this event to what's underneath us?

    
    

    
  
You'll have to set a (new) flag in the DOMEvent to say that this is the wrong
frame for the event. Then the event state manager will have to propagate that
back to the presContext event handling code which can return telling the view
manager that the event should be passed to the next view.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
OTHER PROBLEM!!!

The texts in the DIV should have been centered, but they are not!!

    
    

    
  
(please see bug number 198070 for event and web site details)

    
    

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

    
    

    
  
Still not fixed, is it????

    
    

    
  
Why not to FORCE the renderer to completely IGNORE hidden objects while 
rendering the page?? So for example for the renderer

<div style="position:absolute;top:7;left:9;visibility=hidden>bla bla</div>
<div style="position:absolute;top:17;left:9;visibility=hidden>blah blah</div>
<div style="position:absolute;top:27;left:9;visibility=hidden>blahh blahh</div>
<div style="position:absolute;top:37;left:9;visibility=visible>at last!</div>

would mean the same as (so the first 3 invisible DIVs would be ignored 
completely) (maybe some problems would appear for scripts that are in hidden 
layers or some other similar mess)

<div style="position:absolute;top:37;left:9;visibility=visible>at last!</div>

and probably fix all the "objects 'hidden by superior layers' in superposed 
layers do not reply" problems...

(PS: sorry for the last comment I've sent about the non-fixing of the bug. 
apparently opera is also having the same problem in some cases)

    
    

    
  
We do ignore "visibility:hidden" elements. The problem here is elements that are
"visibility:visible" but don't contain any visible text, images, or styling.

    
    

    
  
I've somewhat got a fix for this in my local tree for plugins. Here's what I do:

After ->HandleEvent is called on the plugin and it returns FALSE for handling
the event, I redispatch the event to the view manager and set a flag on the
object frame that I'm in event re-dispatch. When GetFrameForPoint is called the
second time on my frame and I have this flag set, I return failure which
eventually causes the view manager to try dispatching the event to the next view
in its display list. Since the pres shell mucks with event->point, I also reset
these values to the orrignals in event->refpoint before redispatching.

I've still got to clean up my code a bit and do testing with other plugins
before I can post a patch.


    
    

    
  
We know how to implement a solution. The question is what exactly the policy
should be, if any.

peterl: you shouldn't have to do all that! It is possible to return "not
handled" to the view manager which then tries the next view. Maybe there is a
problem in nsPresShell::HandleEvent that stops your frame from setting that
result correctly, but that's the way to do this.

    
    

    
  
New interesting "problem":

if all the DIVs have a different z-index (just like the last modification on 
www.alishomepage.com 's top menu, if you want just look at the source the DIVs 
are on the end of the page), it just starts working as intended on some builds 
of mozilla... Does it help?

    
    

    
  
Comment 45 and comment 49 are not about *this* bug.  I'm also not really sure
how much comment 47 and comment 48 have to do with it.  Please try to avoid
confusing this bug by adding unrelated comments.

    
    

    
  
*** Bug 203828 has been marked as a duplicate of this bug. ***
Blocks: 139555

    
    

    
  
- WORKAROUND - :D

In fact using "some other HTML coding method" just solved the problem. Here's 
the script:

function find(neyi){
if(document.getElementById&&document.getElementById(neyi)){return 
document.getElementById(neyi).style}
else{if(document.all&&document.all(neyi)){return document.all(neyi).style}
else{if(document.layers&&document.layers[neyi]){return document.layers[neyi]}
else{return false}}}}

function hide(what){
var object=find(what)
if(object){object.visibility="hidden";object.top=-471}}

function show(what,position){
var object=find(what)
if(object){object.visibility="visible";object.top=position}}

Explanations:

- find(a) just finds "the right way" the browser calls the DIV named "a" (so 
this works with "practically every browser on earth")

- hide(a) hides the layer "a" and ALSO moves it somewhere high up above the 
visible limit, so the invisible DIV does NOT interfere with the visible ones

- show(a,pos) will bring back "a" the the "pos" position... Bad part with this 
script: you will have to find the positions of you layers! (if anyone has 
another workaround for that, GO ON AND TELL IT :D)

If you want to see this code "live", you can try www.alishomepage.com

PS: the welcome text of this site has not yet been updated. This will be done 
ASAP :D (as soon as me exams are finished let's say)

    
    

    
  
MORE INTERESTING!!! YOU IN FACT DO NOT EVEN NEED TO MOVE THE DIV!!!!

Don't know why but "calling the DIV the way Mozila prefers it" (using the find
() function) just makes everything work perfectly!!

So the following JavaScript code for changing DIV visibilities works (at least 
has worked in all my test cases)

function find(neyi){
if(document.getElementById&&document.getElementById(neyi)){return 
document.getElementById(neyi).style}
else{if(document.all&&document.all(neyi)){return document.all(neyi).style}
else{if(document.layers&&document.layers[neyi]){return document.layers[neyi]}
else{return false}}}}

function hide(what){
var cisim=find(what)
if(cisim){cisim.visibility="hidden"}}

function show(what){
var cisim=find(what)
if(cisim){cisim.visibility="visible"}}

    
    

    
  
So I think it seems to be a simple HTML coding problem...

Anyone confirming?

    
    

    
  
See comment 50.  It applies to comments 52 through 54.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
*** Bug 219775 has been marked as a duplicate of this bug. ***
QA Contact: petersen → ian

    
    

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

    
    

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

    
    

    
  
*** Bug 224874 has been marked as a duplicate of this bug. ***
Blocks: 217314

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
I think we need to do something about this, but I don't know what we should do.

Has anyone analyzed other browsers and figured out exactly what their policy is?

    
    

    
  
IT HAS BEEN FIXED!!

I am using Mozilla Firebird 0.7 under Windows XP SP1 and the "Another 
simplified testcase" is working perfectly.

I had the same result in Mozilla Firefox 0.8 under Windows NT4 (I do not know 
the SP number, but should be the latest available)

Confirming?

    
    

    
  
It's not fixed, and that testcase is totally unrelated to this bug...

        Attachment #64641 -
        Attachment description: Another simple example → Another simple example (but not of this bug)

        Attachment #64641 -
        Attachment is obsolete: true

    
    

    
  
-> It's not fixed, and that testcase is totally unrelated to this bug...

Can someone give us a testcase, then? All the attachments seem to work 
perfectly, I therefore suppose that the bug has "no examples" !?!?!

    
    

    
  
(In reply to comment #76)
> -> It's not fixed, and that testcase is totally unrelated to this bug...
> Can someone give us a testcase, then? All the attachments seem to work 
> perfectly, I therefore suppose that the bug has "no examples" !?!?!

CORRECTION: No, it's not... The first testcase does not work

WHAT OTHER BROWSERS DO: it WORKS on IE6SP1, and does not work on Opera 7.23

    
    

    
  
Ali, please stop shouting.  And please _read_ this bug.  Had you done that, you
would have seen that the "another simple example" was diagnosed as having
nothing to do with this bug over two years ago.

What's needed here (what roc is asking for) is a clear description of what other
browsers do in a wide range of situations including but not necessarily limited to:

1)  Fully transparent background, no content, size set in CSS.
2)  Background image with some transparent regions, otherwise same as #1.
3)  Clicking between widely spaced lines in a block with no background.
4)  Clicking on the space created by margins between two blocks.
5)  Clicking on an image with some transparent regions.
6)  Clicking on a random chunk of content with "opacity:0.0001" (or the IE
    equivalent with filters).

All of these should be tested with overlap caused by at least the following:

A)  Absolute positioning.
B)  Fixed positioning.
C)  Relative positioning.
D)  Negative margins.

So first someone needs to write testcases for the things we need to test
(testing what I've mentioned so far requires 24 testcases, but there may also be
other situations we need to test).  Then people need to report what other
browsers do on every single one of those testcases.
Keywords: qawanted

    
    

    
  
(In reply to comment #78)
> 1)  Fully transparent background, no content, size set in CSS.

Seems not to work in Mozilla or Opera, works in IE

> 2)  Background image with some transparent regions, otherwise same as #1.

IE and Opera consider that transparent images are still images, so transparent 
resions are not significant. On the other hand, since Mozilla considers 
the "top" regions of a transparent image as transparent, if the first case 
gets fixed than the second will get as well...

> 3)  Clicking between widely spaced lines in a block with no background.

Does not change anything in Opera or Mozilla's behaviour. In IE, the region 
hidden with spaces will get inoperational (since space also counts as a text, 
so hides things)

> 4)  Clicking on the space created by margins between two blocks.

Space created by margins is clickable in Opera, Mozilla and IE.

> 5)  Clicking on an image with some transparent regions.

[see (2)]

> 6)  Clicking on a random chunk of content with "opacity:0.0001" (or the IE
>     equivalent with filters).

What's that !?!? (sorry)

    
    

    
  
> In IE, the region hidden with spaces

Not with spaces.  With inter-line spacing.  Eg:

<div style="font-size: 10px; line-height: 100px">
Text<br>
More text
</div>

I'm not sure what your comments about mozilla and partially-transparent
background images mean.

    
    

    
  
(In reply to comment #78)
> So first someone needs to write testcases for the things we need to test

I created testcases for the 6x4 scenarios you mentioned.  They're a bit hackish,
but seem to work (work==provide info) with Mozilla and IE6.
http://ajschult.home.mindspring.com/102695/

I actually made a single page with all 24 testcases, but it only worked in
Mozilla.  :/

Let me know if I misunderstood what you were looking for on any (or all :)) of
the testcases.

    
    

    
  
Yeah, that's exactly what I had in mind!  So what's IE's behavior?  
Whiteboard: WONTFIX? → WONTFIX? (o138037)

    
    

    
  
A table of the results on various browsers would be nice :-)

    
    

    
  
Well, IE6 and Mozilla are idistinguishable.
tests 1-4, clicking within the DIV flashes the DIV and clicking outside cycles.
test 5, same as 1-4 except clicking on the image does nothing (IMG gets the event).
test 6, same as 1-4 except clicking on the text does nothing (P gets the event).

However, the idea here was to identify the differences between Mozilla and IE
(which was what made me suspicious of my testscases before).  I added an IMG
with a link before the DIVs and Mozilla and IE now have differences on a few of
the tests.  The new tests are at:
http://ajschult.home.mindspring.com/102695a/

Also (so far) I have not noticed any differences due to positioning, except that
IE screws up "fixed".  Also, test4 in the new tests isn't useful in IE yet
because the IMG and DIV placements are so bad.

    
    

    
  
> and Mozilla and IE now have differences

And those are?



    
    

    
  
I made a table of results here:
http://ajschult.home.mindspring.com/102695a/
the differences between IE and Mozilla exist in tests 1 and 3, where IE sends
the event to the IMG with the href="#", while Mozilla sends the event to the
positioned DIV.

    
    

    
  
So if I understand correctly, the IE behavior in particular includes the following:

When clicking on an empty div, if there is a linked image under the click point
send click event to that.  In the same situation if the only thing under the
click point is the <body>, send event do the div.

Is that right?  Does that behavior depend on whether the <body> has a background
set?

    
    

    
  
correct.

Adding a body background does not change the results of either test (with or
without a big image).

I also retested without a link on the big image, and it does not make a
difference (although it makes it easier to tell what IE is doing).

    
    

    
  
What about putting another div under there instead of an image?  Is it just
ancestors that don't steal the event from the div, or do "just a box" siblings
also not do it?

    
    

    
  
A div, a div with a background image and a linked div (<a...><div></div></a>) do
not change the behavior of the testcases in IE (or Mozilla) I decsribed in
comment 81.
I posted the testcases with a div with a background image here:
http://ajschult.home.mindspring.com/102695b/

    
    

    
  
(In reply to comment #87)

Not so.

This is very weird.  I've read through the comments and nobody seems to see 
what's really going on.

IE doesn't support setting all four offsets of a positioned DIV; combine that 
with the fact that the DIV in the testcase provided is empty and you get a DIV 
that doesn't expand (in IE), therefore doesn't overlap other parts of the page.  
Just remove the "right" and "bottom" offset specifications and Mozilla (and 
Opera) will show you what IE is doing.

If I am able to, I'll attach a testcase that will make IE do the same as Mozilla 
(only to be viewed in IE).

Since IE doesn't support this, its only "legitimate" use is on sites that are 
targeted at Mozilla (and/or Opera).  If you find it on a site targeted at IE, 
it's either due to negligence (copy-paste & don't care) or purposefully 
"blocking" users of Mozilla (and Opera).

The solutions proposed here seem to be quite drastic in that web authors who do 
use it legitimately may find themselves with a limitation.

To sum up my point of view:
I think Mozilla (and Opera) are applying the CSS rules correctly.&nbsp; If a web 
page author makes abuse of them by finding combinations that screw up the 
rendering then THEY are the problem, not Mozilla (or Opera).

    
    

    
  
Yes, but what if that background is made transparent?

    
    

    
  
Should that make a difference?  The DIV is still overlapping the majority of the 
page, and transparency only concerns what you see.

Elements with "position: fixed" or "position: absolute" get priority in the 
stacking of layers, so, unless the author specified "z-index: -1", those 
elements are expected to be rendered on top.

    
    

    
  
> Should that make a difference? 

Apparently in IE it does.  That's what this bug is about.

    
    

    
  
(In reply to comment #92)
> Created an attachment (id=144569)
> This makes IE do the same as Mozilla. View in IE only. Post number 91.

This is not the subject - actually the DIV you've put "over" the underlying 
text is not transparent!!

    
    

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

    
    

    
  
So if IE does what I described in comment 87, that's _really_ wacky.... and if
we want to try and do it we need a spec of what elements are "magic" to IE like
that.

    
    

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

    
    

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

    
    

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

    
    

    
  
*** Bug 257137 has been marked as a duplicate of this bug. ***
Blocks: 265440

    
    

    
  

      
      
      
      

        Attached file
          
        testcase (flash ad) (obsolete)
        — 
      

    


  
Major Turkish newspapers and Sites seems to use this problematic transparent
div's for flash ads a lot . Many users reporting problems and accusing firefox
for this.

I've atatched an example simplified HTML code, from a major news site
(http://www.milliyet.com.tr)

    
    

    
  


  
Corrected testcase.

    
    

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

    
    

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

    
    

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

    
    

    
  
*** Bug 265275 has been marked as a duplicate of this bug. ***
Blocks: 288822

    
    

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

    
    

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

    
    

    
  
So we did some investigation at Opera, and our conclusion was that in IE6, an 
element is transparent to hit testing for mouse events simply if it is a block-
level element whose background-image computes to 'none' and whose background-
color computes to 'transparent' and if there is another box below it.

Can anyone prove this wrong?

Is that easily implementable? (Note that the definition is exact; e.g. 
"background: url(bogus)" is enough to block this transparency, because there the 
value doesn't compute to 'none'.)

    
    

    
  
> and if there is another box below it.

Meaning what?  For example, the <body> box is below the <div> in the tests
talked about in comment 81 through comment 87, but the <div> is transparent to
hit testing.  Also, what about comment 90?

    
    

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

    
    

    
  
> > and if there is another box below it.
> Meaning what?

Meaning that if the box is the bottom box (in terms of z-index) then it will
never be considered transparent to events. Not sure how that contradicts your
<div> example, though.

I didn't follow comment 90 or its testcase so I don't know what to say about
that one, sorry.

    
    

    
  
> Not sure how that contradicts your <div> example, though.

In my <div> example the <div> is not transparent to events, even though there is
a <body> box below it.



    
    

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

    
    

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

    
    

    
  
Just swapping the place of both div's "mainblok_initial_text_content" 
and "mainblok_content" fixed this issue in the webpage reported by Bug 304120

    
    

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

    
    

    
  
Sorry bz I'm confused, could you give a URI to the testcase in which there is a 
transparent <div> that isn't transparent to events despite there being a <body> 
below it? (You once said that it was transparent to hit testing and then said it 
wasn't transparent to events so I'm confused.)

Basically, can you give a URI to a simple file showing the contradiction of what 
I described? Thanks. :-)

Looking forward to making a decision on this.

    
    

    
  


  
Uses IE's event.srcElement, so the handler only really works in IE.

    
    

    
  
URI for Ian:
http://www.agnetheln.ro/arhiva.php

It's not a <div> tag, but a <h1>, to allow PNG transparency under IE.
Links beneath the transparent PNG image contained in the <h1> tag do not work.
In IE they do.

    
    

    
  
Thanks. I have forwarded those links to the people at Opera who did the testing.

Personally I'd still like to WONTFIX this bug, especially if nobody can work out
exactly what IE is doing. But I agree that what IE is doing has its benefits.

    
    

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

    
    

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

    
    

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

    
  

        Attachment #169165 -
        Attachment is obsolete: true

    
    

    
  
What are the implications of this when coding stuff like navigation menus? In a typical design, the menuitems have transparent backgrounds (with the navigation menu itself colored and styled). The user may have coded it to rely on mouseovers to determine the current moused-over menuitem. If onmouseover does not fire over the menuitem, but instead directly to the parent menu, then no position information can be obtained.

(In reply to comment #111)
> So we did some investigation at Opera, and our conclusion was that in IE6, an 
> element is transparent to hit testing for mouse events simply if it is a block-
> level element whose background-image computes to 'none' and whose background-
> color computes to 'transparent' and if there is another box below it.

    
    

    
  
*** Bug 339352 has been marked as a duplicate of this bug. ***
Blocks: 344027

    
    

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

    
    

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

    
    

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

    
    

    
  


  
I've run into a bug that I think is this one - but I'm not sure (it seems to be an instance of Bug 241792, which was marked as a dupe of this).  I've uploaded the simplest testcase I could get to reproduce the problem (reproducible on Camino 1.0.3 and Firefox 2.0 on OS X v10.4.8).  

Interestingly, even though the ".formfield2" div contains only the button, it seems to have expanded to encompass the textarea as well, thereby blocking it from being selected (if you give that div a solid background, it covers the entire form).

    
    

    
  
After reading all down to here I can simly say what my problem is and that it might be related to this Bug and if it would be posted seperatly it might be soon marked as a duplicate. So I post it here even if it's only a minor facet of what it's written down here all the long page. I guess no-one afterall knows what this Bug finally is even thos who mark duplicates all the time.

An absolutely positioned <div> over an <a> makes the <a> unclickable even if you can see it, tab onto it and use it by the enter key. the <a> is unclickable even if the <div> has no background (a transparent background, lookup your dictionary what transparent means). since <div> is a blockelement which should affect the flow only not the events (and an absolute positioned <div> even is already outside the flow) it should pass in any event over after it recieved it. but in mozilla it does not. other browsers like IE and beloved Opera do the job just fine.

I have not taken a look into the sourcecode why gecko engine is taking the click into the div and not passing it down afterall.

If this bug posting here exists so long I raise the question why does not anyone takes care of such bogus behaviour? What's the deal? What's so hard? What is the  problem to pass the mouse event down-lo if the background is transparent? hello? clicking is by seeing, so what is the deal? Do I miss here something or is this bug posting a simple "hey hey ho ho we can write down a lot until we change a thing" afterall? What is the problem to fix this after so long time?

    
    

    
  
I recently hit this limitation in a design I'm working on, and it's really the only issue that prevents the layout from working exactly how I want (even in IE7!).  What if "event transparency" was determined as follows:

1. Assumption: we completely ignore boxes that are "display: none;"

2. A box is *completely* transparent to events if any of the following hold:
      [ from comment #19 ]
      a. visibility: hidden;
      b. opacity: 0.0;

   Such boxes will defer event handling to the next-lower layer in z-index
   order.  Otherwise, a box *will handle* events if "visibility: visible;"
   AND opacity is positive, non-zero (e.g. "opacity: 0.0001;").

3. A box that handles events first checks to see if the event hits any of its
   contents (e.g. line boxes for text, contained divs, etc.).  If any of the
   box's contents handle the event, end.

4. If the event remains unhandled, defer the event to the next-lower layer
   in z-index order IF AND ONLY IF:

      ( background-color: transparent; AND background-image: none; )

      OR

      NOT ( opacity: 1.0; )

   Otherwise, end.


My reasoning is this:
    If a box's opacity is < 1.0 then any boxes below it that could also handle
    events will (by previous definition) have an opacity > 0.0 *relative to
    the box in question*.  If you interpret this in the context of comment #19,
    then these lower boxes should be capable of receiving events.

I don't know the internal Gecko rendering model very well, so I'll leave it to others to specify how easy this would be or any holes in my understanding.  But I can see the following advantages:

1. The above algorithm is rather simple.

2. It does not need to calculate the transparency of a given pixel or take
   into account the content of a background image itself (just whether one
   is defined).

3. Within the existing DOM and CSS specs, you get event transparency control
   via CSS.  Setting the opacity to 0.9999 will be visually indistinguishable
   from an opacity of 1.0 and has a similar behavioral consequence (in terms
   of event transparency) as the difference between opacities of 0.0001 and
   0.0, respectively.

Thoughts?

    
    

    
  
In bug 380573 there's a suggestion (which I like) to implement SVG's pointer-events CSS property:
http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
for all elements.

That would allow authors to address some of the needs here.

    
    

    
  
http://kart.finn.no/
worked in 1.0.*, now broken. Works in IE7.
ajschult made a testcase and referred to this bug and the fix that broke it, bug 317375
http://rheneas.eng.buffalo.edu/~andrew/test.html
I'd really like that map to work..

    
    

    
  


  
I was led to this bug after researching the cause of some link spam.
The link was visible, but not clickable (or right-clickable).

    
    

    
  
Given that it has been difficult to decipher the intricacies of the IE event transparency model, I suggest a "-moz" property be added as an interim solution. So, any element with a property of e.g. "-moz-transparent-event" would automatically have all events pass through it to/from the covered element. Any web developers wanting to use this feature would be allowed to do so, using the specified property.

If, sometime in the future, more specific criteria can be agreed upon, then the bug can be revisited -- or even standardized as a valid CSS style.

    
    

    
  
No need for a -moz-* property; see comment 139.
Hardware: PC → All

    
    

    
  
Are you implying that the property would be usable in a non-SVG context?

Blocks: 427088

    
    

    
  
Will events be passed throu layer that has transparent background image like png or gif? It would be a huge advantage... cheers

    
    

    
  
I'd say, if the user clearly sees a link and hovers or clicks on it, then the link should work, no matter what. Simple enough, isn't it? No standards are needed to understand it. It is just common sense.

Let Firefox get as close as possible to this simple ideal.

    
    

    
  
The problem is that "clearly sees a link" is a subjective judgement, and there are identical-looking situations in some of which the link really should trigger and in others of which it really shouldn't.

    
    

    
  
Submitted Oct 2001 and the status is still 'NEW'?

It seems that instead of determining 'how' to modify the browser to provide additional functionality to we developers, the tone of this thread has been to ask 'why'? With all the examples already given over the past 8 years, I won't pile on.

As a developer I simply cannot understand 'why' this hasn't been corrected. Start at the top layer, check pixel transparency, move to next layer and repeat until you get a hit (ie. non-transparent pixel). Fire the event to all layers from the top down to the hit (weeding out nested elements, and thus duplication). It might be a lot of work to code - although not 8 years worth - but it isn't very complicated.

Suffice it to say that if this issue continues to be 'NOTFIXED' or becomes a 'WONTFIX', ff will become a 'DONTUSE' on my sites. :( And that would be a shame, because as far as I'm concerned, Microsoft has stolen a lot of ideas from here.

    
    

    
  
Hear, hear!

    
    

    
  
> it isn't very complicated

Excellent.  We'll look forward to your patch.

    
    

    
  
I think our current plan is to leave our default behavior as-is but allow authors to change it when they want (bug 380573).
QA Contact: ian → layout.view-rendering

    
    

    
  

      
      
      
      

        Attached file
          
        Very simple test case
        — 
      

    


  
I ran into this problem on an intranet page, and boiled it down to the simple test case attached here. There are no plug-ins, just a ul with position:relative and a floating table with unclickable links in it. Chrome 4.0.206.1 and Safari 4.0.3 agree with FF 3.5.3's behavior. I think IE8 is putting the floating table at a higher z-order so they are clickable there.

    
    

    
  
For what it's worth, the attachment in comment #165  works differently in FF 3.6 Namoroka than in other browser releases. The table with links never overlaps the other table as it does with other browsers. Not sure what happens with other test cases.

    
  
Blocks: 520033

    
    

    
  
(In reply to comment #166)
> For what it's worth, the attachment in comment #165  works differently in FF
> 3.6 Namoroka than in other browser releases. The table with links never
> overlaps the other table as it does with other browsers. Not sure what happens
> with other test cases.


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b6pre) Gecko/20091209 Namoroka/3.6b6pre

Namoroka works same as Seamonkey, Gran Paradiso and Minefield, top two links don't work, table overlaps, as can be seen if you edit the testcase to show a border.
Blocks: 582915

    
    

    
  
This is what YouTube uses as a basic prevention of right-click -> Save Video As... on WebM videos.

Removing the div with class="video-blocker" works fine.

The div has the following CSS:

.video-blocker {
  display: block;
  position: absolute;
  z-index: 1010;
  top: 0;
  bottom: 31px;
  left: 0;
  right: 0
}

#video-player * {
  -webkit-user-select: none;
  -moz-user-select: none;
  cursor: default
}

div {
  background-color: transparent;
}

I also think the video is a bit smoother once I remove the transparent div but that's a different bug.
Blocks: 597406

    
  
Flags: wanted-fennec1.0?
Flags: in-testsuite?
Flags: in-litmus?

    
    

    
  
;p-;=;
Blocks: 655624
Depends on: 697946

    
  
Whiteboard: WONTFIX? (o138037) → WONTFIX? (Opera: DSK-127398)

    
    

    
  
I think this bug should be WONTFIX'd. 

A transparent background is still a background, but it just means that you can see through it. Logically, there's no reason for it to let events through.

It's a bit like a pane of glass. You can see through it to what's on the other side, but that doesn't mean you should be able to walk through it. It's still there in the way, even though you can't see it.

I appreciate that users may get confused if they come across an unclickable link that's behind a transparent div, but I would consider that to be a problem caused by the page designer, not the browser.

    
    

    
  
Is this still an issue now-a-days ?

    
    

    
  
Yes, though I'm also still inclined towards WONTFIX at least until we agree on a standard that says how this should work (which then might or might not agree with the WONTFIX).  But we should probably leave it open until we have that standard.

    
    

    
  
Dropping qawanted until new directions.
Keywords: qawanted

    
    

    
  
Well, the qawanted was about gathering the information we'd need to develop that standard...

    
    

    
  
(In reply to David Baron [:dbaron] (needinfo? me) (UTC+8, but slow response this week) from comment #177)
> Yes, though I'm also still inclined towards WONTFIX at least until we agree
> on a standard that says how this should work (which then might or might not
> agree with the WONTFIX).  But we should probably leave it open until we have
> that standard.

Why is that, given |pointer-events:none|?
Flags: needinfo?(dbaron)

    
    

    
  
Why is it that we need more of a standard?

While pointer-events:none says that things are transparent to events, we're still missing a definition for when (given other values of pointer-events) precisely when elements *do* receive events.  Given that browsers disagree on that (although less than they used to), it would help to have a specification define when elements receive events.
Flags: needinfo?(dbaron)

    
    

    
      
  
tracking-fennec: ? → ---

          relnote-firefox:
          ? → ---

          relnote-b2g:
          ? → ---

    
  
See Also:  → https://webcompat.com/issues/10127
Whiteboard: WONTFIX? (Opera: DSK-127398) → WONTFIX? (Opera: DSK-127398) [webcompat]
Component: Layout: View Rendering → Layout: Web Painting

    
    

    
  
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.


Webcompat Priority: --- → ?

    
    

    
  
See bug 1547409. Migrating whiteboard priority tags to program flags.


Webcompat Priority: ? → ---

    
  
Severity: normal → S3

    
    

    
  
The severity field for this bug is relatively low, S3. However, the bug has 74 duplicates, 22 votes and 117 CCs.

:tnikkel, could you consider increasing the bug severity?


For more information, please visit auto_nag documentation.


Flags: needinfo?(tnikkel)

    
    

    
  
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.


Flags: needinfo?(tnikkel)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: