Open Bug 202841 Opened 18 years ago Updated 3 years ago
overflow:auto turns onmouseover behaviour odd with the scroll
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030418 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030418 In the given URL, there is a simple menu (the left one). This menu has got an overflow:auto style. As there is too much text a scroll is given to the menu. The transitions between the menu and its scrollbar make the menu disappear. The menu should stay displayed as long as the mouse pointer is inside its area. In addition to this problem there may be another one, with the right menu. In this menu, the area painted with background colour is different from the one considered by the onmouseover. Which one is the good one ? Reproducible: Always Steps to Reproduce: Go to the URL given. Put the mouse pointer on the "Come here" text on the left. A list should appear below this text. Try to go on this list (the overring system is quite basic here, and you may have to try again). When you are on the list, try to show the last item of the list, at its bottom, by sliding the scroll... ...and the list dissapears as soon as the pointer is on the scroll. If you try again by going anew on "Come here", then putting the mouse pointer directly on the scroll, you'll succeed in scrolling the list. Then try to click on one of the fake links and... the list disappears ! On the right, you have the same DIVs, but with overflow set to visible (the default) instead of auto. You can see all the items of the list, you can click on all of them, even those outside the black area. Note that there is no more problem with the basic overring system (no more glitch, no more list that dissapears suddenly), and of course no more problem with the scroll as there's no scroll. Othe user agents (ie and opera) decided to fill the rightmost list entirely in black. Mozilla only fills the area according the its fixed width and height (those of the style applied on the DIV) but considers the whole area defined by the lines of text for the overring. Expected Results: There should be no flickering on the left menu. The left menu should stay open when there is a transition from the scrollbar to the fake links. The right menu area should either be the one limited by the size given in the style of the tag or the one computed according to the real size of the displayed text because overflow is visible.
With the left menu: 1) When I put the mouse pointer over "Venez ici - Come here", the menu appears. If I move the mouse pointer downwards very quickly, the menu disappears (it shouldn't). 2) When I do the same thing very slowly, the menu disappears for a short while, then reappears. In fact, there seems to be one line where the menu doesn't appear. The right menu doesn't have this problem. (Mozilla CVS 2003-04-06, Linux/PPC)
jkeiser, this sounds like your sorta stuff...
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050901 SeaMonkey/1.1a Bug still seen in Mozilla/5.0 (Windows; U; Win98; de-DE; rv:1.7.10) Gecko/20050715 Firefox/1.0.6 tested on testcase attachment 134659 [details] left box Similar: Bug 306823 A div with overflow:auto flickers when its display property becomes "block"
(In reply to comment #4) > > Similar: Bug 306823 > A div with overflow:auto flickers when its display property becomes "block" Given that Bug 306823 has been marked as DUPLICATE of bug 97283 I am wondering if Bug 202841 should also be marked as DUPLICATE of bug 97283
(In reply to comment #5) > Given that Bug 306823 has been marked as DUPLICATE of bug 97283 > I am wondering if Bug 202841 should also be marked as DUPLICATE of bug 97283 I don't know about duplication or not, but what I see is that the bug is now FIXED. Good news !
This is WFM with current trunk build.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
The bug still occurs here with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060110 Debian/1.5.dfsg-4 Firefox/1.5 on the testcase. It is a bit difficult to reproduce it, though. Something like that: press the left mouse button over the scroll bar and move to the left quickly enough (with the button still pressed). The menu often flickers (disappears for a very brief moment) and sometimes just disappears. Another way: click very fast on the scroll bar while moving the mouse pointer to the left; this sometimes makes the menu disappear. This bug should be reopened (possibly downgrading the severity to minor).
Ok, reopening then. It is still WFM on trunk, though. Vincent, could you test again with the latest trunk build?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I hope I can try tomorrow. Also, I've just tried under Mac OS X with: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 and I also get the flicker. Moreover, the scroll bar is always visible.
I could reproduce the bug by clicking several times after 2 seconds with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060118 Firefox/1.6a1
Just to be sure that it is not a platform (mac, linux) dependant problem, I can reproduce a strange behaviour similar to what Vincent described, with Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8) Gecko/20051111 Firefox/1.5 If I click in the scrollbar of the left menu, and keep the left button pressed, and then if I move the pointer outside the window, I consequently have the menu flickering. It is a reproducible behaviour. So it is not FIXED, but a lot of work has been done somewhere which has a very good impact on the initial symptoms. Moreover, the behaviour used to be a real problem to user experience. Now it looks like a minor cosmetic problem to me (for *this* test case).
These old bugs seems to be gone. I guess the ticket can be closed now.
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.