Closed Bug 188153 Opened 22 years ago Closed 21 years ago

onmouseover not working

Categories

(Core :: DOM: CSS Object Model, defect)

Product:
Core
Component:
DOM: CSS Object Model
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mehturt, Assigned: bernd_mozilla)

References

(
URL
)

Details

(Keywords: regression, topembed, Whiteboard: [adt2]) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20030107 Phoenix/0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20030107 Phoenix/0.5

Onmouseover doesn't work on the www.nvidia.com web page, I recall they were
working sometimes in December.. According to people on Mozillazine, it is
working in Windows versions of Phoenix, but not in Linux.
Moving mouse over the top menu on nvidia.com displays only thin black line below
the menu, but not the menu itself - using 20030107 nightly.  With 20030106
nightly the menu was displayed but could not be pointed on (disappears when
trying to point on it).

Reproducible: Always

Steps to Reproduce:
1.open www.nvidia.com
2.try to open the upper menu
3.

Actual Results:  
the menu contents are not displayed

Expected Results:  
the menu contents should be displayed
changed Product to Phoenix
Component: Browser-General → General
Product: Browser → Phoenix
Version: Trunk → unspecified
I think this is a duplicate of bug 166658.

I'm seeing the same problems with www.nvidia.com that this bug describes, but I
am using the configuration used in bug 166658.

I'm using the following:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20030107 Phoenix/0.5


Have you tried with Mozilla? I can confirm it with Phoenix but given that it is
a rendering problem there's a good chance it's Mozilla regression (I can still
mouseover with the Debian release of Mozilla from late December).
this bug doesn't exist with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a)
Gecko/20021212
a follow-up to my comment #2...

according to the submitter of this bug, multiple monitors are not in use.  see
here in the phoenix forums:

http://www.mozillazine.org/forums/viewtopic.php?t=4011

Weird... for some reason I have not received any alerting emails until today
when someone added himself to the CC: list, an event which I shouldn't see! bah.
Bugzilla's email filters are a little wonky I guess.

Anyway...

-->New
-->All OS

I have the sneaking suspiscion that some patch applied to Mozilla was only
partially adopted by Phoenix.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
I can recreate this bug in "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b)
Gecko/20030115", and in "Mozilla/5.0 (Windows; U; Win98; rv:1.3b)
Gecko/20030114", so I don't think it's specific to Phoenix, although I can see
it in "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20030116
Phoenix/0.5" too.

I'm having similar problems with <http://www.vicorepharma.com/> and
<http://www.cellnetwork.com/>. Are they related?

In Linux, I can force an onmouseover event by right-clicking on the hot spot,
but that doesn't work in Windows.
Component: General → Browser-General
Product: Phoenix → Browser
Version: unspecified → Trunk
Component: Browser-General → Event Handling
I am also seeing the problem that the menu appears but as soon as I try to move
the mouse over the menu it disappears. Worked fine in 1.0.2, this 1.3b on Win2k
seems to have this problem (but like the original reporter showed this bug
appeared earlier).
To refresh the info - the bug still persists with both Phoenix and Mozilla:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030209 Phoenix/0.5
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030205

I can confirm Heikki's report with 1.3b milestone win2k. The amazing thing is
that the buttons at the top of the window now are perfectly aligned, but the
menus don't work (they disappear), but in 1.3a milestone the buttons were not
aligned at all, but the menus *DID* work! 
Also see bug 193339 on the same site, same issue. There is some analysis
there, plus a reduced testcase there that will help anyone investigating
this issue. We might want to dupe this bug forward to that one -
In the meantime, reassigning to DOM Style for parity -
Assignee: asa → jst
Component: Event Handling → DOM Style
QA Contact: asa → ian
I'm just trying out Opera 7.0 preview for Linux and it has the same problem.. therefore 
- could this be the nvidia's site bug rather than browser bug?

related: bug 190677
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
adt: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
ADT: Nominating topembed
Keywords: topembed
pschwartau, Can you review this bug and determine whether thisa is a general
failure or site specific?
It looks like a general bug. The best analysis so far is by jkeiser.
His reduced testcase in bug 193339 comment 12 shows that the problem
of the disappearing submenu is caused by mouseouts firing too early.
The content model of the testcase (derived from nVIDIA) is as follows:


<div id="outer_div"
     style="border: 1px solid black; padding: 5px; position: absolute;" 
      <table id="table">
           <tr id="tr">
               <td id="td">
                   <div id="popup" class="otherfly">
                       <div id="popupinner" class="glbflypos">
                           <a id="anchor" href="http://www.google.com">
                              Download Drivers
                           </a>
                        </div>
                   </div>
               Drop Me Down
               </td>
           </tr>
      </table>
</div>


where the |class| attributes are defined in-line as:


<style>
.glbflypos {
	position:absolute; 
	top:20px; 
	background-color:#000000;
}
.otherfly {
	position:relative; 
	visibility:hidden;
}
</style>


By running the testcase, we can see that mouseout events fire
inappropriately as we mouseover the outer div. The code at the 
nVIDIA site sets visibility to 'hidden' on mouseout events.

That is what the site should do. But because Mozilla fires mouseouts
while the use is still over the parent menu div, the user can never
get to the submenu. John analyzed the issue as follows:


------- Additional Comment_ #12 From John Keiser  2003-02-17 17:34 -------
[In the testcase], I have to have an absolutely-positioned element outside,
with a table inside, with the menu inside.

The problem (which you can see with the border set) is that if you are no
longer over the absolute-positioned element (parent div) but are over the
popup -- a relative positioned element -- mouseout gets fired and mouseover
is no longer fired.


I see two bugs:

- There is a bug with the mouseout being fired too early.  We fire mouseout
for the anchor as soon as you cross the boundary from the absolutely-positioned
element even if you are over the anchor.

- (Probably) for some reason we can't find the relative-positioned element
if it is hidden and this set of parents is around.  Dunno why that is.
There is probably a more minimal testcase for this particular bug.
---------------------------------------------------------------------------
Note, users of the nVIDIA site have reported, either in this bug
or in one of the duplicate reports, two different behaviors:

BAD:
When we mouseover a parent menu div, the submenu div appears,
but we can't reach it (analyzed in the comment above)

VERY BAD: 
When we mouseover the parent div, the submenu div doesn't even appear.


I am using today's Mozilla trunk binary 2003051214 (1.4b) on WinNT.
When I try the nVIDIA site in this build, I am seeing the "very bad"
behavior. Never mind reaching the submenus; they don't even appear.

We can see an indication of the problem by loading the site and entering
these javascript:URLs to toggle the visibility of the "Products" submenu:

        javascript: MM_showHideLayers('ID03', '', 'show');
        javascript: MM_showHideLayers('ID03', '', 'hide');

In IE6, this works perfectly. However, in my current Mozilla binary
on WinNT, the 'show' doesn't work until I *CLICK* in the URL bar 
after hitting <Enter>. By contrast, the 'hide' works as soon as I
hit <Enter>. That can't be right!!!

For more detail of the MM_showHideLayers() function, see bug 193339.
Note: there is altogether more information about this bug there than here.
Perhaps the duping should have been done the other way around, even though
it is numerically after this one -
Another URL -- works in IE:
http://tutor.lscf.ucsb.edu/mcdb108a/tw-lig/how-slide-rule-works.htm

Does nothing in 2003051508 win32 build.

Thinking about that analysis, I think both problems (not the new one you are
seeing, which I am seeing too) are one and the same: we fire onmouseout because
the browser does not and cannot realize that the mouse is over the relative
positioned element, probably because it is not looking at the overflow area of
the table.  This indicates a problem in GetFrameForPoint.

The problem of which you speak sounds like somewhat an invalidation problem.
Note the following bugs. Perhaps they are relevant?

bug 197581 
"Need to recover overflow area properly during incremental reflow"


which is mentioned in bug 205165 comment 23:

------- Additional Comment_ #23 From Robert O'Callahan 2003-05-15 21:10 ------- 
[It looks like bug 197581 is the cause]

Without actually digging, here's my *guess* as to what's happening:
The absolute DIV does have its own view and that view should have the right
position and size. However, since the overflow for the relative DIV is
incorrect, the view for the relative DIV is incorrectly sized (to 0,0 probably).

This violates the view system invariant that views contain their children,
and this violation means that the view system will not paint or send events
to the absolute DIV.
Oh!  That would explain why the table is necessary!  Yes, this is precisely the
same problem, and now it makes sense.  The overflow area isn't getting set so
the view doesn't know there are children in that area.  Very good catch.
Depends on: 197581
this is fixed in *my* CVS build with patch for bug 173277
Depends on: 173277
*** Bug 206940 has been marked as a duplicate of this bug. ***
Reassigning to Bernd since he has the fix.
Assignee: dom_bugs → bernd_mozilla
Flags: blocking1.4?
*** Bug 190677 has been marked as a duplicate of this bug. ***
*** Bug 209451 has been marked as a duplicate of this bug. ***
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4?
Now that bug 173277 is fixed, this works fine in  Gecko/20030914 Firebird/0.6.1+
Menus at http://www.nvidia.com now works (2003-09-14-05 trunk Linux).
Both URLs mentioned in comment 7 works fine.
Testcase in dupe bug 193339 works fine.
The URL mentioned in comment 21 has JS that only works in IE (filed bug 219223).
All (3) duplicates have the same URL.

FIXED by bug 173277
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.