Open
Bug 202841
Opened 22 years ago
Updated 2 years ago
overflow:auto turns onmouseover behaviour odd with the scroll
Categories
(Core :: Layout, defect, P3)
Tracking
()
REOPENED
People
(Reporter: stan, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(1 file)
4.00 KB,
text/html
|
Details |
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.
Comment 1•22 years ago
|
||
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)
Comment 2•22 years ago
|
||
jkeiser, this sounds like your sorta stuff...
Comment 3•21 years ago
|
||
Updated•21 years ago
|
Priority: -- → P2
Comment 4•19 years ago
|
||
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"
Comment 5•19 years ago
|
||
(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 !
Comment 7•19 years ago
|
||
This is WFM with current trunk build.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Comment 8•19 years ago
|
||
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).
Comment 9•19 years ago
|
||
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 → ---
Comment 10•19 years ago
|
||
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.
Comment 11•19 years ago
|
||
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
Reporter | ||
Comment 12•19 years ago
|
||
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).
Updated•15 years ago
|
Assignee: layout → nobody
QA Contact: ian → layout
Reporter | ||
Comment 13•9 years ago
|
||
These old bugs seems to be gone. I guess the ticket can be closed now.
Comment 14•6 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•