96832 - [EVENTTARG]Elements with negative z-index steal events (links not clickable)

Status: VERIFIED FIXED

(Core :: Web Painting, defect)

Description

[Markus Hübner]

When trying to click on a link on the left side (the red ones) clicking on them 
doesn't do anything at all.
The code is usual HTML:
<a href="living.asp" class="gnorm2">Wohnen im Central</a>

Using build 2001082303

Comment 1

[Markus Hübner]

adding keywords

Comment 2

[Ryan Pertusio]

Windows 2000
Build: 20010824

I am having no trouble loading the pages. 
  I doubt the latest build will mak a difference (only one day apart from the
one I tested on)..  but you can try.

Is it possible that you were not "online"clicked to go "offline" by accident? 
(I would doubt you did this, because you could still post the bug)

Are there any other pages or websites that do not seem to load besides the ones
listed with the url you provide?

Comment 3

[Mats Palmgren (inactive)]

WFM, build 2001-08-23-08 on Linux (SuSE 7.1)

Comment 4

[Henrik Gemal]

wfw2
build 20010824

always try to reproduce bugs with a fresh profile first. So before filling the
bug, create a new profile and see if you can reproduce..

Comment 5

[Markus Hübner]

Henrik, why should I try with a new profile when using an existing profile is 
the situation that will be used out there?!
when reporting bugs we should use the most common settings.

Comment 6

[Markus Hübner]

Still see this with build 2001082508

Comment 7

[Markus Hübner]

btw: also created a new profile and the problem is still there.

Comment 8

[Ryan Pertusio]

Could you tell us more details of what is happening?  Examples include:

(1) Does hovering over a link change the pointer to a "hand" cursor (or whatever
you have set as default)

(2)Do the links "underline" when you hover over them?

(3) When you click on them, what browser activity is there?  Does Mozilla even
attempt to load the pages, or show any indication that you've clicked?

(4) Are the links the only thing you notice failing?  Does the rest of Mozilla
and the website seem to work as you expect?

Also, What might be helpful is a testcase.  A testcase would be very helpful in
narrowing down the problem for those of us who do not seem to have the same
difficulties.
  Did you try a 'fresh' install of mozilla?  is it possible that there were
corrupted data files somewhere?  You'd have to delete (or rename) the "Mozilla"
folder in your Application Data folder, and also run Mozilla from a newly
downloaded binary.  (I have the same computer configuration as you report the
problem on, and I don't see anything in the Windows 2000 architecture that would
cause this problem when I look at the page source.)
  Another thing to try..  remove all of your plugins, and see if any of those
have caused a problem.  (Actually, you may want to try this first.)

Comment 9

[Markus Hübner]

Thanks Ryan for your feedback.

(1) Rovering over a link doesn't change the pointer.

(2) The links also don't underline when hovering over them.

(3) When clicking on them nothing happens at all. No activity from Mozilla.

(4) There is also another strange thing. The headline "Sie kennen das:" as well 
as the first words "... den ganzen Tag" cannot be marked. The rest works fine.

I'm trying to provide a more simple testcase.

As usually I am trying a fresh installation of mozilla, deleting all previous 
files and directories (I am using the latest ZIP file).

I haven't installed any additional plugins.

Comment 10

[karnaze (gone)]

Reassigning to pierre.

Comment 11

[Markus Hübner]

build 2001083003 still has the problem.

Comment 12

[Markus Hübner]

A smaller testcase is available at
http://www.world-direct.com/central/moztest.htm

Comment 13

[Pierre Saslawsky]

I tried on Mac and Win98 and like 3 other persons already reported, it works for 
me too.

Markus: can you reproduce the bug on other machines?  If yes, please try to 
simplify the testcase even more.

Comment 14

[Daniel Mario Vega (Restore MNG Support --> #18574)]

I see this problem when using my home banking account. I'll upload a simplified
testcase

Comment 15

[Daniel Mario Vega (Restore MNG Support --> #18574)]

Attachment: Simplified Testcase

Comment 16

[Markus Hübner]

seeing this too with build 2001090503

Comment 17

[Michael Hendy (Hendikins)]

wfm with 090408/NT4

Comment 18

[WD]

WinMe and Linux also show the strange behavior w/ the testcase

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

Link worksforme build 2001083103

Testcase: seeing behavious as described in HTML Comment

Comment 20

[Markus Hübner]

seems things are quite strange here 8-)
hope we can get closer to it and know what is the cause for this behaviour.

Comment 21

[Pierre Saslawsky]

The "Simplified Testcase" from Daniel Mario Vega is invalid, it is a dup of bug 
95176.

Markus: so far you are the only one to see the problem with the page at the URL 
above or at http://www.world-direct.com/central/moztest.htm (Daniel, WD and 
Christian refered to the "Simplified Testcase").  Could you simplify 
"moztest.html" as much as possible and attach it to the bug report? Please make 
sure that the bug can be reproduced with the testcase after you attach it, and 
try on different platforms. Thanks.

Comment 22

[Markus Hübner]

I discovered what causes this behaviour!
Its just one single line:
<div id="babe" style="position: absolute; top: 0px; left: 324px; width: 266px; 
height: 290px; z-index: -1;"><img src="imgs/babe.gif"></div>

A more (not working) testcase is at
http://www.world-direct.com/central/moztest2.htm

And a working testcase with the "bad line" removed is at
http://www.world-direct.com/central/moztest3.htm

Using build 2001090703

Comment 23

[Markus Hübner]

just discovered that when the window is not full-size it's working.
if full-size not working as mentioned

Comment 24

[basic]

I think the problem in attachment 48421 [details] is a similar problem to this bug as when
I comment out:

        <div style="position:absolute;left:395px; top:12px">
            <table>
            <tr>
			   <td>&nbsp;</td>
            </tr>
            </table>
        </div>

the problem goes away. It is not a dup of bug 95176. This bug seems like yet
another inheritance problem caused by absolute positioning? (indirectly maybe?)

Comment 25

[Markus Hübner]

I think the problem is the positioning of the div element.
Although in the file moztest2.htm it has a z-index of -1 and isn't displayed
at all it is exactly positioned over the links, hence the
links are not clickable.

Another testcase at http://www.world-direct.com/central/moztest4.htm
shows the problem clearly.
When the window size is that width that the image is over the links they are 
not clickable anymore. That's what is happening in the moztest2.htm

Comment 26

[Markus Hübner]

just to explain why not everyone is seeing this problem in the first run:
When having a screen resolution of 1280x1024 the picture is positioned excatly 
over the links and the bugs occurs.
The layout is designed that the picture is always positioned exactly where the 
links are ... it's using absolute values in this example - these should normaly 
be used dynamically so that on changing the window with the picture is 
positioned correctly.

So just use http://www.world-direct.com/central/moztest4.htm and expand your 
window with so that the picture is positioned over the links. Then you can go to
http://www.world-direct.com/central/moztest2.htm and the links won't work.

Maybe we should change the bug summary?

Comment 27

[Daniel Mario Vega (Restore MNG Support --> #18574)]

Markus,

I can reproduce the problem as you describe in your last comment. Increasing the
width of Mozilla to 1280 the links are not functional.

Build ID: 2001090609 - OS: Linux

Comment 28

[Markus Hübner]

updating keywords

Comment 29

[basic]

Daniel: your home banking testcase is an evang problem (meaning its just a case
of bad website coding)

I'll attach a modified version of your testcase that demonstrates this bug

Comment 30

[basic]

Attachment: a better testcase

Comment 31

[chris hofmann]

any chance of a low risk fix for this in the next few days?

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think the problem here is that nsView::HandleEvent checks all children before
checking the parent, which doesn't correspond to the way we paint.

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

roc:  Are there cases with the new view manager where we paint one view "in the
middle" of another?  If so, that would make fixing this hard.

Comment 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The problem is very simple: currently, view manager event handling completely
ignores z-index.

To fix this the view manager should use nsViewManager::CreateDisplayList to
figure out the order to process views.

This is equivalent to one of the bugs on my list, buf 49175.

Comment 35

[Pierre Saslawsky]

Reassigned to Views.

Kevin, to reproduce:
- load attachment 49014 [details]
- click "Set z-index of div to -1"
- move the cursor at the location of the red div (ie. above the "ABOU" of "ABOUT 
MOZILLA")
===> Bug: you can't click on that part of the link.

Also check with roc for bug 49175.

Comment 36

[Cindy Roberts]

There aren't any comments on this bug since the 18th of Sept.  Can QA regess
against the Netscape commercial builds and determine if this is still a valid
bug?  Please mark as nsbranch+ which will get this on the PDT radar if you think
this is critical and can give us an ETA for the fix. Else, mark is as nsbranch-.
Also, can someone comment in the bug how serious you think this is?  PDT is only
accepting "stop ship" bugs at this point such as data loss, loss of major
functionality, regressions and bugs to the eMojo "stop ship" features.

Comment 37

[Markus Hübner]

Being not able to click on links is a loss of major functionality.
Should try to get this in to avoid further inconveniences - especially for
the commercial build!

Comment 38

[Daniel Mario Vega (Restore MNG Support --> #18574)]

I see this problem in my home banking account

Bank of Boston: http://www.bostonaccess.com.ar/

I can use the service with no problems, but I can not click the "exit" link to
logoff. I have found that I can navigate links using the "TAB" key and then hit
"Enter".

Comment 39

[Kevin McCluskey (gone)]

Marking nsbranch-

Comment 40

[Kevin McCluskey (gone)]

Moving to Mozilla0.9.6

Comment 41

[Markus Hübner]

regarding the latest comment shouldn't the target milestone be 0.9.6 ?!
Think this is really important to have included in the next release.

Comment 42

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I have the fix.

Comment 43

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: View manager changes to account for z-index etc in event handling

This patch reorganizes view system event handling. Event handling is moved from
nsView into nsViewManager (except that we leave a hook in for native scrollbars
in nsScrollingView, grr!). The view manager handles an event by creating a
display list for a 1x1 rectangle at the event target point, and then
dispatching the event to the elements of the display list. Using the same
display list code as the paint path ensures event handling matches what is
being rendered, including correct handling of z-index. It also gets rid of the
O(n^2) problems that nsView used to have in a nice clean way, and doesn't crash
when views are deleted. Best of all, sharing the display list code path ensures
that event handling and painting will stay in sync during future changes.

The main possible downside (apart from the potential regressions anytime anyone
 touches this core code) is performance. The display list path is definitely
higher overhead than the old code, and it dynamically allocates some objects. I
haven't worried about this so far, since I suspect events don't arrive
frequently enough for this code to get onto the performance radar.

If possible I'd like to get this checked in ASAP since we're still early in the
milestone.

Comment 44

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 45

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Revised patch

This patch is the previous patch with only one change: at the beginning of
nsViewManager::BuildEventTargetList I added a check to see if we're currently
painting. No-one should be dispatching events during paint, but other people's
bugs could cause it to happen; if it does, we'll just drop the event. This
prevents the event handling code from trying to reuse mDisplayList, which could
cause a crash when we return to the painting code.

Note that this code works just fine with painting while an event is being
handled, or even with nested event handling, because it copies the display list
to a local buffer and relinquishes mDisplayList before it actually processes
the event.

Comment 46

[Kevin McCluskey (gone)]

Comment on attachment 67823 [details] [diff] [review]
Revised patch

I ran with the patch installed for a few days, and I didn't notice any
regressions or performance issues.  I also inspected the patch and stepped
through the code in the debugger on WIN32. The code looks straightforward and
solid.

r=[e-mail]

Comment 47

[Kevin McCluskey (gone)]

CC'ing saari and joki.

Comment 48

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What's the status on this? Are joki and saari looking at it?

Comment 49

[Kevin McCluskey (gone)]

I just thought they might be interested in knowing about this change. They are
not reviewing the change AFAIK.

Comment 50

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It seems both attinasi and waterson are on vacation or something, so CC'ing
brendan for super-review.

Comment 51

[Brendan Eich [:brendan]]

Comment on attachment 67823 [details] [diff] [review]
Revised patch

sr=[e-mail], the code looks good and I trust you.

/be

Comment 52

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Thanks.

You probably shouldn't trust me, I'm averaging one regression per fix checked
in. Although I'm also averaging under 24 hours for fixing the regression :-).

Comment 53

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Checked in.

Comment 54

[Chris Petersen]

Marking verified in the OS X trunk (2002-04-12-03) and Windows ME Builds
(2002-04-12-06).