42356 - [EVENTTARG]clicks do not pass through visibility:

Status: VERIFIED FIXED

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

Description

[Shashi Narain]

View the attached test case and you will see that <a href="xxx" target="new">
works fine. But when the same <a> tag is used at the supplied URL, it does not work.


Could this be a possible effect of an earlier bug I reported (#42032)???

Comment 1

[Shashi Narain]

Attachment: Test Case

Comment 2

[Chris Petersen]

Based on the information provided, I'm not able to reproduce. Using the sample 
test case, the link opens a new window which loads mozilla.org. The links on this 
page function and load the source into the existing window.Tested with the June 
9th build. Let me know if there is something that I missed here.

Comment 3

[Asa Dotzler [:asa]]

this worksforme with 061308 build under NT and Mac9

Comment 4

[Shashi Narain]

Let me see if I can explain the situation a little better. For reference, I am
using the June 12 build (Linux and Windows).

As you personally saw through the attached test case, target="new" works the way
it should. Now head over to http://www.narain.com/gecko/ After the DHTML
routines are completed, click the icon containing the Mona Lisa. A "window" will
appear within the page containing links to some of the exhibits. When these
links are clicked, you will see that nothing happens. Since the links in the URL
are structed in the same way as in the test case, I find it strange that
target="new" works in one instance but not another.

The key question for now is...are the exhibits at the URL opening in a separate
Moz window for you??? On my PC, using two separate platforms, nothing happens
when the links are clicked.

Comment 5

[Shashi Narain]

Just as I posted my comments, I had a mid-air collision with Asa so I doubt he
has seen my latest comments yet.

Asa, could you please read my comments from a few minutes ago and see if the
exhibits are opening in a separate window in NT and Mac. In Win98 and Linux,
they are not opening.

In the meantime, I am re-opening this bug until someone I can get full
confirmation.

Comment 6

[Chris Petersen]

Ok, I see the problem you describe. Clicking on these links will not open the 
source referenced. Since we know simple HTML A elements work with target, we need 
a simplified version of the URL that demonstrates the root of the problem. I 
noticed that you are using A:Hover for the links. This may or may not be causing 
this problem. Could I use your help further on this issue ?

Comment 7

[Shashi Narain]

Chris,

I am working on some test cases right now to see if I can figure out where this 
problem is coming from. You will hear from me again within the next couple of 
hours.

Comment 8

[Shashi Narain]

I've created two testcases that may help illuminate what could be causing this 
strange behaviour. 

The first testcase can be found at http://www.narain.com/gecko/bug42356a.html 
This page is identical to /gecko/index.html but with one slight modification. In 
index.html, the graphic containing the navigator wheel is wrapped around
<a href="http://www.narain.com/">....in the testcase I have added target="new". 
If you click this graphic you will see that a separate Moz window opens. This 
tells me that something is happening inside those tables of mine that is causing 
target="new" not to function correctly. Why should it work in one instance and 
not another all within the *SAME* page???

Which brings me to the second testcase that can be found at 
http://www.narain.com/gecko/bug42356a.html This page is a very simplified 
version of index.html It contains only one, single table which is the exact 
duplicate of one found in index.html I have retained all the relevent style 
properties on the suggestion that A:hover may be the problem. As you can see, a 
new Moz window will open when a link is clicked.

This clearly shows that A:hover is not the problem. So what could be cauing this 
bug??? I have a strong feeling that this is related to bug #42032. This earlier 
bug is causing all kinds of havoc with Gecko and I believe that what we are 
witnessing here with target="new" is just another manifestation of #42032. It 
seems to me that when clip is dynamically used on a layer containing links, some 
of the HTML gets gets "blown away" and thus un-usable.

Comment 9

[Shashi Narain]

The URL I provided to the second testcase in my previous comment is incorrect. 
The correct URL is http://www.narain.com/gecko/bug42356b.html

Comment 10

[Chris Petersen]

I think you right on the money. I see that the two bug reports are related.

Comment 11

[Shashi Narain]

Since this bug is one of the effects of bug #42032, I have gone ahead and marked 
this bug as a dependent of #42032. When #42032 get fixed, I will check to see 
whether this bug fixes itself or requires further work.

Comment 12

[karnaze (gone)]

Pierre, please triage these from Clayton's list.

Comment 13

[Hixie (not reading bugmail)]

This is INVALID unless I missed something. Certainly 
   http://www.narain.com/gecko/bug42356b.html
...works fine for me.

Note that target="new" does not mean "open new window". That would be 
target="_blank" (IIRC). target=new means the same as target=foobar, namely,
put this link in the frame or window named "new" (or "foobar", respectively).

Is that what is causing the confusion?

Comment 14

[Shashi Narain]

Ian, did you read through all the previous comments, especially those made by 
me, before posting your latest comment??? It seems to me that you have 
completely missed the point of this bug. Let me give you the gist of what is 
going on without having to repeat myself.

First of all, target="new" is a completely valid HTML attribute for the <a> tag 
which tells the browser to spawn a new window (this attribute is universally 
supported by all major browsers). As you clearly saw with the testcases I 
supplied, target="new" is working the way it should (ie. a new Moz window does 
open).

When target="new" is applied to a link residing within a *static* layer, 
everything works perfectly. If the layer just so happens to have DHTML done to 
it (in my case the dynamic use of the clip property), then target="new" becomes 
non-functional and the reason why I filed this bug.

As you can see from this bug report, I have made this bug a dependent of #42032. 
The reason is because ever since the switch-over to the "new" CSS2 clip 
definition, all sorts of strange things are happening.

On a slight tangent...you probably know about or maybe have even visited my 
Mozilla demo site, Gecko's Realm. This site makes very heavy use of clip (for 
which I have been using since the first day it became functional within Moz last 
summer). When Moz starts behaving strangely at my site, it is a sure bet that a 
bug has been uncovered and I will know about it.

I am re-opening this bug since it is completely valid and has been confirmed by 
other individuals.

Comment 15

[Shashi Narain]

A thought occurred to me soon after posting my last comment. It is Ian's 
contention that my use of target="new" was incorrect and that I should use 
target="_blank". I have created a testcase that puts this contention to the 
test. You can find the testcase at http://www.narain.com/gecko/bug42356c.html

This testcase is *IDENTICAL" to the original index.html but with two minor 
changes. The top-most graphic contains the following link...<a 
href="http://www.narain.com" target="_blank">. When this graphic is clicked, a 
new Moz window opens up just like target="new".

The second change was this...click the Mona Lisa icon. The "Turning On The 
Style" table will appear. Inside this table is a link to the "Footworld World" 
exhibit. This link contains the same target="_blank" attribute. As you will see 
from clicking the link itself, nothing happens.

This testcase clearly shows that it does not matter what I put inside the target 
attribute because the moment dynamic clip is applied to it, target= gets 
completely "blown away" and un-usable.

On a complete tangent...I don't want to make a big deal out of this but feel 
that I need to make this point. I feel it was very wrong of Ian to mark this bug 
as "RESOLVED INVALID" when he did not have a complete understanding of what was 
going on here. It is a complete waste of everyone's time (most especially mine), 
when I have to re-prove my point for the benefit of one person when my prevous 
comments and testcases make it very clear that I do have a valid bug.

Comment 16

[Hixie (not reading bugmail)]

I am terribly sorry if you feel I wasted any of your time. That was not my 
intent. To try to make this up to you, I have worked on minimising the test
case. From the original 22kb page, I have made a 500 byte test case which 
demonstrates the root cause of the problem.

   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/link-layers.html

It has nothing to do with 'clip()', it has nothing to do with DHTML, it has 
nothing to do with 'target'. It is in fact a problem of event bubbling. There
are two visibility:hidden absolutely positioned DIVs (more than two in fact in
the original page) over the top of each other, and what is happening is that the
:hover and :active events are being passed to the one that is visible, but the
actual click is being dropped.

Reassigning to Event Handling. cc'ing David for comments if he has any. This may
be a dup. Removing dependency (clip is not involved).

Incidentally, my point about target="new" not being magic as you suggest still
stands. See HTML4, section 6.16. Legacy browsers do _not_ treat it in any way
differently to target="foo"; for proof, try clicking on the first icon of your
first test case multiple times: only one window appears, and it is then reused.

Comment 17

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

The event targetting code should be ignoring elements with visibility: hidden.  
However, I've seen another weird bug like this, where the target is found right, 
and then something strange happens.

Changing 'layers' to 'elements' in title.  If you meant 'absolutely positioned 
elements' or 'relatively positioned elements' or 'positioned elements', please 
say so.  The term 'layer' means a bunch of different things, all of which have 
other words, so I prefer not to use it at all.

Comment 18

[Shashi Narain]

Ian ---

As I said before I don't want to make a biggie of this...my point was that 
something strange was definitely going on with this bug. I believed that this 
bug had something to do with clip because I had seen similar bugs like this when 
clip first got implemented into Moz last summer. Considering that the "new" CSS2 
definition of clip got introduced only recently, you can't fault my logic for 
thinking that the two were related...I am going with past experience.

After viewing your testcase, I have to agree with you that my original belief 
about the root of this bug is incorrect. Your test shows the essence...

David ---

What you are describing, and what I am experiencing, sounds like a bug that 
appeared around 6 months ago. I don't remember the bug number but I do remember 
it causing a similar problem. Specifically...links, within a visible abs pos 
element, would become "invisible" (like it was not even there) coupled with 
links from hidden elements "bleeding" through to the visible elements.

Could this earlier bug have found it's way back into Moz or are we dealing with 
something completely new???

Comment 19

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

This is a newer and stranger bug, unless someone messed up my fixes to 
GetFrameForPoint.  Is this similar to bug 40584?

Comment 20

[joki (gone)]

Okay.  So I've found the issue.  When we first check the non-visible div we 
don't find anything but we still attempt to process the click through 
nsEventStateManager::PreHandleEvent.  The net result is that we process the 
mousedown twice, once incorrectly, and the mouseup twice, once incorrectly.  
Since the correct version never occur one after another we never create and 
dispatch the click event.

So I could attempt to stop calling PreHandleEvent when we haven't found a good 
target frame but I'm not sure what that'll cause offhand.  It'll fix this, its 
true, but I need to look into the other effects.

Comment 21

[joki (gone)]

Okay, i've got a fix for this now.  Won't be checked in for a while yet.

Comment 22

[joki (gone)]

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

Comment 23

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

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

Comment 24

[Johnny Stenback (:jst)]

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

Comment 25

[Stephen Walker]

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

Comment 26

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 27

[Bob Kanefsky]

Changing platform to All; I stumbled across the problem under MacOS 9 
and eventually isolated it to the same bug described here.

Workaround for sites that want to support Netscape PR1 and PR2 is to 
put the hidden element at a lower "layer" using z-index.

Comment 28

[Bob Kanefsky]

Attachment: Workaround test case (remove z-index to reproduce bug)

Comment 29

[Nisheeth Ranjan]

Marking nsbeta3+...

Comment 30

[Nisheeth Ranjan]

Joki's fixes have been checked in by saari.  Marking fixed.

Comment 31

[ckritzer (gone)]

Marking VERIFIED FIXED on:
- LinuxRH62 2000-09-08-08-M18 Commercial
- Win98     2000-09-08-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial