mouse over fires twice

[ShadowMage]

Hey guys,I have a situation. I'm not sure how I can explain this and it's difficult for me to post the code because it's generated by PHP and rather complex. Here goes nothing:I have a table:

<table id='tblBreakdown'>	<tr>		<th colspan='8' style='border-style: none; border-bottom: groove #A0A0A0; font-size: 16px;'>Breakdown</th>	</tr>	<tr>		<th style='width: 20%;'>Type</th>		<th>Glazing</th>		<th>Finish</th>		<th>Pnl Qty</th>		<th>Sq Feet</th>		<th>Eng Hrs</th>		<th>Value</th>		<th>Profit</th>	</tr>	<tr id='WPnls_1_row'>		<td class='costHeader'>			<a class='linkItem' href="java script:openSkylightDtl('WPnls',0,1);"  onmouseover='console.log("Firing onmouseover..."); showDtlTip(this);' onmouseout='hideDtlTip(this);'>Wall Panel</a>		</td>		<td class='center'>Guardian 275™</td>		<td class='center'>215-R1</td>		<td class='center'>xx</td>		<td class='rightAlign'>xxx.x</td>		<td class='center'>xx</td>		<td class='rightAlign'><span style='float: left;'>$</span>xxx</td>		<td class='center bd_ProfitClass'>xx.x%</td>	</tr></table>

(This is all generated by PHP)My issue is with the mouse overs. Whenever one of the links is near the bottom of the page, the onmouseover fires twice. If I scroll the page so the link is more than about two lines (of text) away from the bottom of the visible screen (browser window) then the event only fires once. I placed the console.log() function in the mouse over to verify this behavior. If I change console.log to alert, it only fires once...(I only get one alert)This happens in FF 4. It doesn't happen with IE 8. I haven't tested any other browsers.Anybody have any insight into why this might be happening. If there's anything else you want me to post, just ask.Thanks.

[jeffman]

Is it possible that showDtlTip repositions page elements in such a way that a mouseout event fires, which in turn repositions things so that the mouseover event fires again? It would all happen very quickly. Try logging what happens in the mouseout.

[ShadowMage]

Nothing is being repositioned except for the popup tip. ...And the popup tip doesn't have any events attached to it.But then again, maybe when it displays the first time it's being displayed over the top of the anchor...? Shouldn't be, though, because the tip is repositioned before it's made visible.....Do elements with visibility: hidden; block other elements? I mean can they be hovered or clicked? I don't think they can be.

[jeffman]

Elements with visibility:hidden take up the same space they would if they were visible. I'm not about responding to events. It would seem dumb if they do.Did you see if a mouseout fires before the second mouseover?

[ShadowMage]

Elements with visibility:hidden take up the same space they would if they were visible. I'm not about responding to events. It would seem dumb if they do.

Agreed. Which is why I asked. I don't recall them ever responding to events before, but I thought maybe I was just lucky before...

Did you see if a mouseout fires before the second mouseover?

Indeed I have. I've added a few more log statements to the code and this is what I came up with for a single hover:

Firing onmouseover...Firing tip_show...Curr position: x -> ; y ->New position: x -> ; y -> 282pxFiring onmouseout...Hiding tip: WPnls_2_tipFiring onmouseover...Firing tip_show...Curr position: x -> ; y -> 282pxNew position: x -> ; y -> 282px

The mouse over fires. That function runs a few small tasks and then calls the function that actually shows the popup (tip_show). The tip_show function calls two functions that reposition the popup if it would go out of the viewing area (one for x and one for y) and then sets the visibility to visible. The mouse out fires, which runs a few small tasks and then calls the tip_hide function. The only statement in the tip_hide function sets the visibility to hidden. Then the mouse over is fired again...

[jeffman]

A little checking in FF confirms that mouse events don't fire when visibility is hidden.So the question is why does the mouseout fire? If any part of the popup appears under the pointer, that would do it. This includes margins or padding you might not be thinking about.Post code/link?

[ShadowMage]

I can't post a link because this is an intranet application. I'll try to extract relevant portions of code.This is the code for one of the popups:

<div class='tip' style='width: 675px;' id='WPnls_1_tip'>	<div class='tip_title'>Wall Panel Systems</div>	<div class='tip_body' style='overflow: auto; padding: 10px;'>		<div style='width: 650px;'>			...popup content...		</div>	</div></div>

This is the CSS as shown by FireBug:

element.style {	top: 264px;	visibility: hidden;	width: 675px;}div.tip {	background-color: #333399;	border-color: #DDDDEE #333366 #333366 #DDDDEE;	border-style: solid;	border-width: 1px;	display: block;	font-family: Arial,sans-serif;	left: 0;	padding: 2px;	position: absolute;	/*top: 0;*/	/*visibility: hidden;*/	z-index: 20;}* {	margin: 0;	/*padding: 0;*/}

(The commented portions indicate properties that have been overwritten, and have been struck through in FireBug)EDIT:If margins or padding (or anything causing an overlap) were the issue would it not create an infinite "loop" causing the tip to continually flicker? The popup doesn't reposition itself between the first time and second time it's shown, it just flickers.

[jeffman]

I don't think that's enough code to help me duplicate it. You could message me the generated source if you want, all of it I mean, scripts etc.I'm sure I was wrong about margins, BTW, though padding would count.Normally, what I'm thinking of would cause an infinite flicker, yeah. But since it only occurs at the bottom of the window, I was thinking that if the document's scrollheight is changing, the popup would have an effect on the pointer's position relative to . . . something.What happens if you just toggle the visibility without repositioning the popup?Have you tried toggling display instead of visibility? If the thing is positioned absolutely, the effect might look the same.

[ShadowMage]

I don't think that's enough code to help me duplicate it. You could message me the generated source if you want, all of it I mean, scripts etc.

Ok, I'll try piecing things together to try to get something to replicate this effect.

What happens if you just toggle the visibility without repositioning the popup?Have you tried toggling display instead of visibility? If the thing is positioned absolutely, the effect might look the same.

I'll try commenting out the newx/newy functions to see what happens.The popup tip script is part of an old library of scripts that is used on a great number of intranet pages here. It isn't really written the greatest, but up until now it's worked perfectly fine, so I never dug into it. I'm not sure how much of the script is actually kept separate and how much is kept in each document/page (if you understand what I mean... ) but I'll try to see if I can switch it to display instead of visibility. (It is positioned absolutely, BTW)

[ShadowMage]

I'll try commenting out the newx/newy functions to see what happens.

Still fires twice.

The popup tip script is part of an old library of scripts that is used on a great number of intranet pages here. It isn't really written the greatest, but up until now it's worked perfectly fine, so I never dug into it. I'm not sure how much of the script is actually kept separate and how much is kept in each document/page (if you understand what I mean... ) but I'll try to see if I can switch it to display instead of visibility. (It is positioned absolutely, BTW)

This was actually easier than I thought, but still no dice.

[ShadowMage]

Hmm....interestingly, changing the anchor to a span seems to have fixed it. Any thoughts on this?

[jeffman]

Yes I have thoughts. I THINK you've found a genuine bug. I first duplicated the problem on my PC, which is the computer I don't use often. Something kept nagging me in the corner of my eye. You know how FF4 has adopted a little popup status-widget in place of the old status bar? What I noticed was that whenever your popup appears twice, the widget appears in the right corner in the window space. When your popup appears only once, the widget appears in the left corner, just below it. As you noticed, the problem occurs when the link is at the bottom of the window. The widget moves in the same circumstance. Cause and effect? The reason I even thought of this is that on my main computer, a Mac, I installed the status-4-evar AddOn, which replicates the old status bar. So on that FF, the problem did not occur. Just to be certain, I disabled and re-enabled the AddOn several times.It is indeed the new widget somehow fooling the browser into thinking a mouseout has occurred.What you discovered pretty much confirms the matter. No <a> element means no status text on hover. I'm glad you thought to try that, because I was so focused on finding out what the problem was, I didn't try to think of a solution.Anyway, now you know why, and you can sleep easy knowing it's not your fault.

[ShadowMage]

Yes I have thoughts. I THINK you've found a genuine bug. I first duplicated the problem on my PC, which is the computer I don't use often. Something kept nagging me in the corner of my eye. You know how FF4 has adopted a little popup status-widget in place of the old status bar? What I noticed was that whenever your popup appears twice, the widget appears in the right corner in the window space. When your popup appears only once, the widget appears in the left corner, just below it. As you noticed, the problem occurs when the link is at the bottom of the window. The widget moves in the same circumstance. Cause and effect? The reason I even thought of this is that on my main computer, a Mac, I installed the status-4-evar AddOn, which replicates the old status bar. So on that FF, the problem did not occur. Just to be certain, I disabled and re-enabled the AddOn several times.It is indeed the new widget somehow fooling the browser into thinking a mouseout has occurred.What you discovered pretty much confirms the matter. No <a> element means no status text on hover. I'm glad you thought to try that, because I was so focused on finding out what the problem was, I didn't try to think of a solution.Anyway, now you know why, and you can sleep easy knowing it's not your fault.

Indeed I can sleep easy. I didn't think of that either, but it makes sense. Mystery solved! :)Thanks, DD!I think I might submit this to the Mozilla team...

[jeffman]

Before you submit it, try to recreate it as bare-bones as possible.

[ShadowMage]

Before you submit it, try to recreate it as bare-bones as possible.

Yep, I did. I created a document with a little bit of dummy content (to create some scrolling) and one link (well, actually two, because I also tested the CSS :hover, which also flickers) and bare bones CSS styles and two JS functions with one line a piece to set display to none/block.