Last Comment Bug 102695 - [EVENTTARG]Treat some transparent elements as "transparent to events"
: [EVENTTARG]Treat some transparent elements as "transparent to events"
Status: NEW
WONTFIX? (Opera: DSK-127398)
: testcase
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: Trunk
: All All
: P3 normal with 21 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://bot.counter-strike.net/realbot...
: 111881 150375 154781 170973 171115 178569 184928 187556 192010 192201 193516 193648 196366 197459 198042 198070 200624 203828 205502 206238 207474 208800 215160 217314 218007 219775 220447 224387 224874 228544 231516 231706 234986 236275 240319 241792 255716 257137 258807 265275 277356 283386 286863 287851 294699 295295 301953 303685 304120 304564 306051 339352 356157 356875 370529 375620 377054 379980 381813 413570 419412 436108 440600 440976 452209 453848 455933 467049 501757 558275 568811 711812 806574 (view as bug list)
Depends on: 697946
Blocks: 139555 427088 520033 597406 655624 217314 265440 288822 344027 452209 582915
  Show dependency treegraph
 
Reported: 2001-10-02 10:53 PDT by Timon Christl
Modified: 2015-03-05 10:04 PST (History)
113 users (show)
bestt385: wanted‑fennec1.0?
bestt385: in‑testsuite?
bestt385: in‑litmus?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
simplified testcase (588 bytes, text/html)
2001-10-02 13:37 PDT, James Paige
no flags Details
Another simple example (but not of this bug) (1.31 KB, text/html)
2002-01-12 00:23 PST, Stan Lovric
no flags Details
This makes IE do the same as Mozilla. View in IE only. Post number 91. (669 bytes, text/html)
2004-03-23 05:37 PST, Thomas Verelst
no flags Details
testcase (flash ad) (1.71 KB, text/html)
2004-12-19 23:04 PST, Mehmet D. AKIN
no flags Details
sorry, this is the correct testcase (1.73 KB, text/html)
2004-12-19 23:08 PST, Mehmet D. AKIN
no flags Details
Testcase demonstrating comment 87 and showing that comment 111 is wrong (178 bytes, text/html)
2005-08-19 08:53 PDT, Boris Zbarsky [:bz]
no flags Details
possible forms testcase (848 bytes, text/html)
2006-11-29 19:24 PST, Noemi
no flags Details
a simplified float testcase with borders drawn (1.03 KB, text/html)
2007-08-11 12:38 PDT, brewthatistrue
no flags Details
Very simple test case (1.05 KB, text/html)
2009-09-15 07:55 PDT, Ed Burnette
no flags Details

Description Timon Christl 2001-10-02 10:53:57 PDT
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.
Comment 1 Michael Gabriel 2001-10-02 11:03:13 PDT
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.
Comment 2 James Paige 2001-10-02 13:36:26 PDT
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
Comment 3 James Paige 2001-10-02 13:37:32 PDT
Created attachment 51728 [details]
simplified testcase
Comment 4 Christopher Hoess (gone) 2001-10-02 14:12:37 PDT
Confirming -> Layout
Comment 5 Kevin McCluskey (gone) 2001-11-09 13:36:18 PST
Links do not with N6.2 on WINNT. Setting OS: All
Comment 6 Dimitrios 2001-12-22 02:30:03 PST
*** Bug 116516 has been marked as a duplicate of this bug. ***
Comment 7 Stan Lovric 2002-01-12 00:23:26 PST
Created attachment 64641 [details]
Another simple example (but not of this bug)
Comment 8 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-01-12 06:16:38 PST
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).
Comment 9 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-01-12 06:18:37 PST
Actually, though, since that DIV doesn't have a z-index, it wouldn't paint on top.
Comment 10 Marc Attinasi 2002-02-25 15:46:04 PST
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.
Comment 11 Kevin McCluskey (gone) 2002-06-26 16:38:24 PDT
ViewManager bug. Reassigning.
Comment 12 Boris Zbarsky [:bz] 2002-06-28 22:56:21 PDT
*** Bug 111881 has been marked as a duplicate of this bug. ***
Comment 13 Boris Zbarsky [:bz] 2002-06-28 22:56:41 PDT
*** Bug 154781 has been marked as a duplicate of this bug. ***
Comment 14 Boris Zbarsky [:bz] 2002-06-28 22:57:21 PDT
*** Bug 150375 has been marked as a duplicate of this bug. ***
Comment 15 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-08-03 20:40:41 PDT
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.
Comment 16 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-08-03 21:19:19 PDT
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?
Comment 17 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-09-09 12:59:22 PDT
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.
Comment 18 Hixie (not reading bugmail) 2002-09-09 16:07:59 PDT
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.)
Comment 19 Eric A. Meyer (dead account) 2002-09-09 16:15:33 PDT
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.
Comment 20 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-09-09 16:37:46 PDT
We currently consider 'visibility' but not transparency.
Comment 21 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-09-09 20:23:10 PDT
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.
Comment 22 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-09-18 10:28:15 PDT
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
Comment 23 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-09-27 06:46:05 PDT
*** Bug 171115 has been marked as a duplicate of this bug. ***
Comment 24 Boris Zbarsky [:bz] 2002-12-25 16:00:34 PST
*** Bug 184928 has been marked as a duplicate of this bug. ***
Comment 25 Boris Zbarsky [:bz] 2002-12-25 16:00:59 PST
*** Bug 178569 has been marked as a duplicate of this bug. ***
Comment 26 Boris Zbarsky [:bz] 2002-12-26 23:43:40 PST
*** Bug 170973 has been marked as a duplicate of this bug. ***
Comment 27 Max Alekseyev 2003-01-03 03:53:47 PST
*** Bug 187556 has been marked as a duplicate of this bug. ***
Comment 28 David Brittain 2003-01-12 05:41:55 PST
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
Comment 29 Boris Zbarsky [:bz] 2003-01-12 08:18:39 PST
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.
Comment 30 David Brittain 2003-01-12 11:37:39 PST
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.
Comment 31 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-01-14 22:10:26 PST
I wouldn't object to doing this for plugins.
Comment 32 Peter Lubczynski 2003-01-15 10:55:07 PST
for plugins, we get an nsIDOMEvent through nsIMouseListener. How to redispatch
this event to what's underneath us?
Comment 33 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-01-15 15:39:29 PST
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.
Comment 34 Boris Zbarsky [:bz] 2003-02-05 11:07:29 PST
*** Bug 192010 has been marked as a duplicate of this bug. ***
Comment 35 Boris Zbarsky [:bz] 2003-02-06 23:25:16 PST
*** Bug 192201 has been marked as a duplicate of this bug. ***
Comment 36 Boris Zbarsky [:bz] 2003-02-15 17:45:01 PST
*** Bug 193516 has been marked as a duplicate of this bug. ***
Comment 37 Boris Zbarsky [:bz] 2003-02-17 00:21:53 PST
*** Bug 193648 has been marked as a duplicate of this bug. ***
Comment 38 Boris Zbarsky [:bz] 2003-03-14 20:34:13 PST
*** Bug 197459 has been marked as a duplicate of this bug. ***
Comment 39 Boris Zbarsky [:bz] 2003-03-18 11:57:38 PST
*** Bug 198042 has been marked as a duplicate of this bug. ***
Comment 40 Boris Zbarsky [:bz] 2003-03-18 12:32:17 PST
*** Bug 198070 has been marked as a duplicate of this bug. ***
Comment 41 S. Ali Tokmen 2003-03-18 13:00:50 PST
OTHER PROBLEM!!!

The texts in the DIV should have been centered, but they are not!!
Comment 42 S. Ali Tokmen 2003-03-18 13:16:31 PST
(please see bug number 198070 for event and web site details)
Comment 43 Andrew Schultz 2003-04-11 19:28:43 PDT
*** Bug 200624 has been marked as a duplicate of this bug. ***
Comment 44 S. Ali Tokmen 2003-04-17 11:11:18 PDT
Still not fixed, is it????
Comment 45 S. Ali Tokmen 2003-04-17 15:28:51 PDT
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)
Comment 46 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-04-17 15:40:20 PDT
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.
Comment 47 Peter Lubczynski 2003-04-17 17:33:29 PDT
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.
Comment 48 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-04-17 18:33:59 PDT
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.
Comment 49 S. Ali Tokmen 2003-04-22 04:10:05 PDT
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 50 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-04-22 18:12:48 PDT
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.
Comment 51 Boris Zbarsky [:bz] 2003-04-29 12:14:53 PDT
*** Bug 203828 has been marked as a duplicate of this bug. ***
Comment 52 S. Ali Tokmen 2003-05-05 12:22:35 PDT
- 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)
Comment 53 S. Ali Tokmen 2003-05-05 15:14:00 PDT
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"}}
Comment 54 S. Ali Tokmen 2003-05-06 12:12:33 PDT
So I think it seems to be a simple HTML coding problem...

Anyone confirming?
Comment 55 Boris Zbarsky [:bz] 2003-05-06 12:43:41 PDT
See comment 50.  It applies to comments 52 through 54.
Comment 56 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-05-13 10:33:51 PDT
*** Bug 205502 has been marked as a duplicate of this bug. ***
Comment 57 Olivier Cahagne 2003-05-19 05:50:12 PDT
*** Bug 206238 has been marked as a duplicate of this bug. ***
Comment 58 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-05-29 11:05:19 PDT
*** Bug 207474 has been marked as a duplicate of this bug. ***
Comment 59 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-06-09 13:42:22 PDT
*** Bug 208800 has been marked as a duplicate of this bug. ***
Comment 60 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-08-05 12:22:36 PDT
*** Bug 215160 has been marked as a duplicate of this bug. ***
Comment 61 Mats Palmgren (:mats) 2003-09-01 16:18:57 PDT
*** Bug 218007 has been marked as a duplicate of this bug. ***
Comment 62 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-20 09:41:15 PDT
*** Bug 219775 has been marked as a duplicate of this bug. ***
Comment 63 Boris Zbarsky [:bz] 2003-09-27 10:30:42 PDT
*** Bug 220447 has been marked as a duplicate of this bug. ***
Comment 64 Boris Zbarsky [:bz] 2003-11-03 16:45:08 PST
*** Bug 224387 has been marked as a duplicate of this bug. ***
Comment 65 Boris Zbarsky [:bz] 2003-11-06 08:31:39 PST
*** Bug 224874 has been marked as a duplicate of this bug. ***
Comment 66 Simon Paquet [:sipaq] 2003-12-17 10:29:39 PST
*** Bug 196366 has been marked as a duplicate of this bug. ***
Comment 67 Boris Zbarsky [:bz] 2003-12-26 22:17:05 PST
*** Bug 228544 has been marked as a duplicate of this bug. ***
Comment 68 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-01-19 16:12:00 PST
*** Bug 231516 has been marked as a duplicate of this bug. ***
Comment 69 Boris Zbarsky [:bz] 2004-01-21 19:09:45 PST
*** Bug 231706 has been marked as a duplicate of this bug. ***
Comment 70 Henrik Skupin (:whimboo) 2004-01-26 14:24:16 PST
*** Bug 206238 has been marked as a duplicate of this bug. ***
Comment 71 Boris Zbarsky [:bz] 2004-02-19 22:42:10 PST
*** Bug 234986 has been marked as a duplicate of this bug. ***
Comment 72 Boris Zbarsky [:bz] 2004-02-24 17:07:47 PST
*** Bug 217314 has been marked as a duplicate of this bug. ***
Comment 73 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-03-06 16:33:11 PST
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?
Comment 74 S. Ali Tokmen 2004-03-06 23:18:50 PST
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?
Comment 75 Boris Zbarsky [:bz] 2004-03-06 23:43:08 PST
It's not fixed, and that testcase is totally unrelated to this bug...
Comment 76 S. Ali Tokmen 2004-03-07 00:01:21 PST
-> 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" !?!?!
Comment 77 S. Ali Tokmen 2004-03-07 00:03:38 PST
(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
Comment 78 Boris Zbarsky [:bz] 2004-03-07 00:19:21 PST
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.
Comment 79 S. Ali Tokmen 2004-03-07 00:51:51 PST
(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)
Comment 80 Boris Zbarsky [:bz] 2004-03-07 08:40:29 PST
> 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.
Comment 81 Andrew Schultz 2004-03-07 21:35:31 PST
(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.
Comment 82 Boris Zbarsky [:bz] 2004-03-07 22:55:03 PST
Yeah, that's exactly what I had in mind!  So what's IE's behavior?  
Comment 83 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-03-08 06:52:25 PST
A table of the results on various browsers would be nice :-)
Comment 84 Andrew Schultz 2004-03-08 07:35:08 PST
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.
Comment 85 Boris Zbarsky [:bz] 2004-03-08 08:42:57 PST
> and Mozilla and IE now have differences

And those are?

Comment 86 Andrew Schultz 2004-03-08 17:39:06 PST
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.
Comment 87 Boris Zbarsky [:bz] 2004-03-08 18:40:00 PST
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?
Comment 88 Andrew Schultz 2004-03-08 20:10:26 PST
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).
Comment 89 Boris Zbarsky [:bz] 2004-03-08 20:43:24 PST
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?
Comment 90 Andrew Schultz 2004-03-12 19:50:36 PST
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/
Comment 91 Thomas Verelst 2004-03-23 05:32:14 PST
(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).
Comment 92 Thomas Verelst 2004-03-23 05:37:18 PST
Created attachment 144569 [details]
This makes IE do the same as Mozilla. View in IE only. Post number 91.
Comment 93 Boris Zbarsky [:bz] 2004-03-28 21:14:42 PST
Yes, but what if that background is made transparent?
Comment 94 Thomas Verelst 2004-04-01 09:45:57 PST
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.
Comment 95 Boris Zbarsky [:bz] 2004-04-01 10:32:43 PST
> Should that make a difference? 

Apparently in IE it does.  That's what this bug is about.
Comment 96 S. Ali Tokmen 2004-04-01 10:40:32 PST
(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!!
Comment 97 Boris Zbarsky [:bz] 2004-04-12 14:02:55 PDT
*** Bug 240319 has been marked as a duplicate of this bug. ***
Comment 98 Boris Zbarsky [:bz] 2004-04-12 14:03:55 PDT
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.
Comment 99 Boris Zbarsky [:bz] 2004-04-26 14:49:59 PDT
*** Bug 241792 has been marked as a duplicate of this bug. ***
Comment 100 Jim 2004-08-18 21:16:24 PDT
*** Bug 255716 has been marked as a duplicate of this bug. ***
Comment 101 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-25 10:27:11 PDT
*** Bug 236275 has been marked as a duplicate of this bug. ***
Comment 102 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-27 14:31:08 PDT
*** Bug 257137 has been marked as a duplicate of this bug. ***
Comment 103 Mehmet D. AKIN 2004-12-19 23:04:13 PST
Created attachment 169165 [details]
testcase (flash ad)

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)
Comment 104 Mehmet D. AKIN 2004-12-19 23:08:26 PST
Created attachment 169167 [details]
sorry, this is the correct testcase

Corrected testcase.
Comment 105 Bob Bruce 2005-01-08 16:48:31 PST
*** Bug 277356 has been marked as a duplicate of this bug. ***
Comment 106 José Jeria 2005-03-20 05:20:53 PST
*** Bug 286863 has been marked as a duplicate of this bug. ***
Comment 107 José Jeria 2005-03-26 16:55:39 PST
*** Bug 287851 has been marked as a duplicate of this bug. ***
Comment 108 Nickolay_Ponomarev 2005-04-09 18:35:38 PDT
*** Bug 265275 has been marked as a duplicate of this bug. ***
Comment 109 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-04-19 16:34:44 PDT
*** Bug 258807 has been marked as a duplicate of this bug. ***
Comment 110 José Jeria 2005-04-23 01:56:52 PDT
*** Bug 283386 has been marked as a duplicate of this bug. ***
Comment 111 Hixie (not reading bugmail) 2005-07-21 06:24:35 PDT
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'.)
Comment 112 Boris Zbarsky [:bz] 2005-07-21 08:27:54 PDT
> 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?
Comment 113 Dave Townsend [:mossop] 2005-07-24 14:30:03 PDT
*** Bug 301953 has been marked as a duplicate of this bug. ***
Comment 114 Hixie (not reading bugmail) 2005-07-26 16:54:34 PDT
> > 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.
Comment 115 Boris Zbarsky [:bz] 2005-07-26 17:48:01 PDT
> 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.

Comment 116 Mats Palmgren (:mats) 2005-08-06 16:00:06 PDT
*** Bug 303685 has been marked as a duplicate of this bug. ***
Comment 117 Erik Fabert 2005-08-10 03:05:10 PDT
*** Bug 304120 has been marked as a duplicate of this bug. ***
Comment 118 splash 2005-08-10 03:32:05 PDT
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
Comment 119 Dave Townsend [:mossop] 2005-08-13 13:54:14 PDT
*** Bug 304564 has been marked as a duplicate of this bug. ***
Comment 120 Hixie (not reading bugmail) 2005-08-19 05:54:32 PDT
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.
Comment 121 Boris Zbarsky [:bz] 2005-08-19 08:53:38 PDT
Created attachment 193170 [details]
Testcase demonstrating comment 87 and showing that comment 111 is wrong

Uses IE's event.srcElement, so the handler only really works in IE.
Comment 122 Mihai Blotor 2005-08-20 03:51:57 PDT
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.
Comment 123 Hixie (not reading bugmail) 2005-08-23 05:48:32 PDT
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.
Comment 124 Dave Townsend [:mossop] 2005-08-26 08:14:15 PDT
*** Bug 306051 has been marked as a duplicate of this bug. ***
Comment 125 Phil Ringnalda (:philor) 2005-09-13 07:28:05 PDT
*** Bug 295295 has been marked as a duplicate of this bug. ***
Comment 126 Daniel Wang 2005-10-07 18:50:45 PDT
*** Bug 294699 has been marked as a duplicate of this bug. ***
Comment 127 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-05-04 20:29:18 PDT
http://my.opera.com/hallvors/blog/show.dml/16391
Comment 128 nrlz 2006-06-19 23:09:01 PDT
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.
Comment 129 Dave Townsend [:mossop] 2006-06-24 09:14:40 PDT
*** Bug 339352 has been marked as a duplicate of this bug. ***
Comment 130 Andrew Abyzov 2006-10-06 05:53:22 PDT
*** Bug 355210 has been marked as a duplicate of this bug. ***
Comment 131 Mats Palmgren (:mats) 2006-10-10 07:53:09 PDT
*** Bug 356157 has been marked as a duplicate of this bug. ***
Comment 132 Dave Townsend [:mossop] 2006-10-16 14:10:07 PDT
*** Bug 356875 has been marked as a duplicate of this bug. ***
Comment 133 Noemi 2006-11-29 19:24:21 PST
Created attachment 247029 [details]
possible forms testcase

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).
Comment 134 Phil Ringnalda (:philor) 2007-02-15 23:56:45 PST
*** Bug 370529 has been marked as a duplicate of this bug. ***
Comment 135 Berke Rahmi Baydu 2007-04-10 13:31:41 PDT
*** Bug 377054 has been marked as a duplicate of this bug. ***
Comment 136 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-05-09 09:53:28 PDT
*** Bug 379980 has been marked as a duplicate of this bug. ***
Comment 137 hanskrentel 2007-05-11 06:16:47 PDT
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?
Comment 138 William Price 2007-05-16 01:54:03 PDT
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?
Comment 139 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-05-16 02:39:18 PDT
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.
Comment 140 R.K.Aa. 2007-06-16 17:02:20 PDT
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..
Comment 141 brewthatistrue 2007-08-11 12:35:08 PDT
*** Bug 381813 has been marked as a duplicate of this bug. ***
Comment 142 brewthatistrue 2007-08-11 12:38:27 PDT
Created attachment 276278 [details]
a simplified float testcase with borders drawn

I was led to this bug after researching the cause of some link spam.
The link was visible, but not clickable (or right-clickable).
Comment 143 Phil Ringnalda (:philor) 2008-01-22 16:35:34 PST
*** Bug 413570 has been marked as a duplicate of this bug. ***
Comment 144 Aaron P 2008-02-18 11:32:11 PST
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.
Comment 145 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2008-02-18 11:49:52 PST
No need for a -moz-* property; see comment 139.
Comment 146 Aaron P 2008-02-19 07:03:51 PST
Are you implying that the property would be usable in a non-SVG context?
Comment 147 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-02-19 12:31:28 PST
Yes.
Comment 148 Mats Palmgren (:mats) 2008-05-26 17:02:24 PDT
*** Bug 419412 has been marked as a duplicate of this bug. ***
Comment 149 Mats Palmgren (:mats) 2008-05-28 09:14:28 PDT
*** Bug 436108 has been marked as a duplicate of this bug. ***
Comment 150 Aron Siemieniuk 2008-06-17 08:07:27 PDT
Will events be passed throu layer that has transparent background image like png or gif? It would be a huge advantage... cheers
Comment 151 Mats Palmgren (:mats) 2008-06-21 09:03:24 PDT
*** Bug 440976 has been marked as a duplicate of this bug. ***
Comment 152 Hans-Georg Michna 2008-06-21 09:31:11 PDT
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.
Comment 153 Boris Zbarsky [:bz] 2008-06-21 10:04:56 PDT
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.
Comment 154 Mats Palmgren (:mats) 2008-06-22 19:01:41 PDT
*** Bug 440600 has been marked as a duplicate of this bug. ***
Comment 155 Dave Townsend [:mossop] 2008-08-27 01:26:14 PDT
*** Bug 452209 has been marked as a duplicate of this bug. ***
Comment 156 Mats Palmgren (:mats) 2008-09-05 13:51:25 PDT
*** Bug 453848 has been marked as a duplicate of this bug. ***
Comment 157 Dave Townsend [:mossop] 2008-09-18 13:01:56 PDT
*** Bug 455933 has been marked as a duplicate of this bug. ***
Comment 158 philippe (part-time) 2008-11-27 20:43:05 PST
*** Bug 467049 has been marked as a duplicate of this bug. ***
Comment 159 Daniel.S 2008-12-28 10:16:18 PST
*** Bug 375620 has been marked as a duplicate of this bug. ***
Comment 160 philippe (part-time) 2009-07-01 20:36:24 PDT
*** Bug 501757 has been marked as a duplicate of this bug. ***
Comment 161 Jeremy 2009-07-21 12:40:03 PDT
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.
Comment 162 Hans-Georg Michna 2009-07-21 12:46:30 PDT
Hear, hear!
Comment 163 Jason Bassford 2009-07-21 12:49:04 PDT
> it isn't very complicated

Excellent.  We'll look forward to your patch.
Comment 164 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-07-21 13:06:30 PDT
I think our current plan is to leave our default behavior as-is but allow authors to change it when they want (bug 380573).
Comment 165 Ed Burnette 2009-09-15 07:55:22 PDT
Created attachment 400763 [details]
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.
Comment 166 Mike Calmus 2009-09-15 17:56:30 PDT
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.
Comment 167 Hermann Schwab 2009-12-09 10:16:45 PST
(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.
Comment 168 Boris Zbarsky [:bz] 2010-04-09 12:27:00 PDT
*** Bug 558275 has been marked as a duplicate of this bug. ***
Comment 169 Matthias Versen [:Matti] 2010-05-28 15:45:40 PDT
*** Bug 568811 has been marked as a duplicate of this bug. ***
Comment 171 Daniel Cater 2010-07-29 10:55:47 PDT
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.
Comment 172 vijay 2010-12-15 19:42:47 PST
;p-;=;
Comment 173 Boris Zbarsky [:bz] 2011-12-18 12:59:41 PST
*** Bug 711812 has been marked as a duplicate of this bug. ***
Comment 174 Mats Palmgren (:mats) 2012-10-29 17:20:14 PDT
*** Bug 806574 has been marked as a duplicate of this bug. ***
Comment 175 mjh563 2012-10-30 16:57:05 PDT
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.
Comment 176 Paul Silaghi, QA [:pauly] 2013-08-21 06:49:52 PDT
Is this still an issue now-a-days ?
Comment 177 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2013-08-21 08:05:03 PDT
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.
Comment 178 Paul Silaghi, QA [:pauly] 2013-08-21 08:10:23 PDT
Dropping qawanted until new directions.
Comment 179 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2013-08-21 09:15:44 PDT
Well, the qawanted was about gathering the information we'd need to develop that standard...
Comment 180 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2014-03-18 22:17:47 PDT
(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|?
Comment 181 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2014-03-19 20:01:06 PDT
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.
Comment 182 albonettidenise 2015-02-28 05:00:29 PST Comment hidden (spam)

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