80901 - Contents of DHTML layer overlaps onMouseOver

Status: CLOSED INVALID

(Core :: DOM: Events, defect)

Description

[Anders Sjölander]

When using onMouseOver on a DHTML layer, the contents of the layer seems to
trigger the onMouseOut event.

I have a set of DHTML menus on http://zoomon.com/. They use DynAPI. On MouseOver
on the menuitems (DHTML layers with <a href="blah">link</a> in them), the
background color should change. And they do. But when the mouse is over the
CONTENTS of the layer, the onMouseOver event triggers (in this case, the
background color changes back again).

I hope you understand what I mean. If not, the problem is pretty obvious on the
website.

Comment 1

[Vladimir Ermakov]

I am not sure what you mean... could you create a small testcase eliminating 
everything but the problem? I see several problems, all of them having to do 
with not dismissing a menu or an object once the mouse moves out, like the 
search field, or the pull down menues. The behaviour for IE is completely 
different and it has the background change but no menu pop up, so I cant easily 
check if the code itself contains errors.

Comment 2

[Anders Sjölander]

Well, I'll try to explain.

In IE and NS4.x, the pull-down menus work like intended, that is, when
onMouseOver, the background color of the menu item layers changes to #ffffff and
back to #cccccc when the layer is onMouseOut:ed. But in Mozilla and NS6, the
background color changes back to #cccccc (as if the the mouse moved off the
layer) when you move the mouse over the CONTENTS of the layer. When browsing
other bugs, I have come across bugs very similar to this one, but they described
the same erro0r but on inline DIVs with the :hover pseudo-class set in the
stylesheet (see http://bugzilla.mozilla.org/show_bug.cgi?id=5693 ). 

Since I use an external DHTML API (DynAPI from http://dynapi.sourceforge.net ),
I cannot guarantee that the JavaScript code is bug-free. Allthough, as I wrote,
it works fine NS4 and IE. 

I can produce a test case tomorrow (it's late in Sweden). Here is a test case
from the above mentioned bug:
http://www.people.fas.harvard.edu/~dbaron/css/test/sec051103b

The other layer-related problems (except the search field, that one is my fault
:) is some error in rendering layers I have seen on many websites using NS6 and
Mozilla. I haven't studied them enough to submit a bug (it could be sloppy
Javascripts). Maybe I will, though.

Comment 3

[Anders Sjölander]

Attachment: Simplified testcase.

Comment 4

[Anders Sjölander]

I attached the testcase you wanted. It creates an error message in the
Javascript console, but don't think that has something to do with the bug, since
it doesn't appear on the original website. It could be because of the <script
src=""> links to an external website (the error appears in the DHTML library).

Comment 5

[basic]

I used the property tree bookmarklet (
http://www.squarefree.com/bookmarklets/pagedata.html#property_tree ) on the
attached testcase. I found that each link seems to be wrapped by a <DIV>, could
the mouseover be working on the <DIV> and not the <a href="">?

using the property tree bookmarklet on the attached testcase:
1) enter opener.productsMenu.item[1].elm.tagName in the textbox. See that it is
a DIV element
2) enter opener.productsMenu.item[1].elm.childNodes.item('a') in the textbox.
See the string http://bugzilla.mozilla.org/products/28.html

Comment 6

[basic]

another method is to use
opener.productsMenu.item[0].getOuterHTML(opener.productsMenu.item[0]) in the
textbox. This will be displayed:

 <div id="JSDynLayer0" style=" left:11px; top:191px; width:200px; height:25px;
clip:rect(0px 200px 25px 0px); background:#cccccc; position:absolute;"><a
href="/products/">See how</a></div>

Comment 7

[basic]

With bugs like this, how I wish the document inspector is revived.

Well here are the actual element objects that are involved in the mouseover menu

the elements have these ids: "JSDynLayer0", "JSDynLayer1", "JSDynLayer2",
"JSDynLayer3", "JSDynLayer4", "JSDynLayer5", "JSDynLayer6", "JSDynLayer7",
"JSDynLayer8".

They all have

ondblclick
onclick
onmouseout
onmouseover
onmouseup
onmousedown

set to this function

function (e) {
var dyndoc = this.lyrobj.dyndoc;
if (is.ie) {
var e = dyndoc.elm.event;
e.cancelBubble = true;
if (e.type === "click" && DynAPI.wasDragging) {
DynAPI.wasDragging = false;
return true;
}
if (e.type === "mouseout" && this.contains(e.toElement)) {
return true;
}
if (e.type === "mouseover" && this.contains(e.fromElement)) {
return true;
}
}
var realsrc = is.ie ? e.srcElement : e.target;
for (; is.ie && !realsrc.lyrobj && realsrc.parentElement &&
realsrc.parentElement !== realsrc; realsrc = realsrc.parentElement) {
}
var src = realsrc.lyrobj || dyndoc;
if (!src) {
return true;
}
var evt = dyndoc._e;
evt.setEvent(src, e);
var type = evt.type;
src.invokeEvent(type, evt);
if (is.ns && (e.type === "mouseover" || e.type === "mouseout")) {
return false;
}
evt.bubbleEvent();
return evt.browserReturn;
}

If more information is needed get the property tree bookmarklet from
http://www.squarefree.com/bookmarklets/pagedata.html#property_tree

use it on the testcase

and type opener.document.getElementById("JSDynLayer0")

Comment 8

[Vladimir Ermakov]

[e-mail] (Anders Sjölander), It looks like the problem is 
with the DynAPI library. It does something to intercept events and creates its 
own event object. In IE and Nav4 the target attribute tells the information 
about the tharget that event is at, but in Netscape 6 target tells the 
information about that target that event is headed towards. In your testcase its 
ultimately headed towards the text in the menu when you mouseover the inline 
text, and target is pointing to that text, and tries to change its background, 
but since text isnt even an html element the color doesnt change.
  The equivalent of target in IE and Nav4 is currentTarget, and this is a 
standards compliant way to detect on which object the eventhandler was fired. 
You will have to modify the getTarget() method of the DynAPI to something like 
this

function getTarget()
{ 
   if(this.currentTarget)
        return this.currentTarget;
   return this.target;
}

Marking the bug invalid

Comment 9

[basic]

umm shouldn't this go to evangelism? Shouldn't the DynAPI author be notified?

Comment 10

[basic]

reporter are you using the latest DynAPI?

Comment 11

[Anders Sjölander]

Yes, I'll report this to the DynAPI crew. I hope they start moving towards 
Mozilla compatibility soon. Thank you so much for your help!

Comment 12

[Vladimir Ermakov]

Actually I visited their site and it says they've fixed some mozilla
incopatability bugs recently, in particular event bugs

Comment 13

[Vladimir Ermakov]

closing