Open
Bug 45497
Opened 25 years ago
Updated 2 years ago
Tooltip should disappear when parent item disappears
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
NEW
Future
People
(Reporter: bdwheele, Unassigned)
References
()
Details
Prior to clicking on a link a tooltip will appear. When the new page is loaded, the tooltip remains, until after the mouse is moved.
Comment 1•25 years ago
|
||
I am not sure who this should go to, starting with you peter. reasigning
Assignee: rods → trudelle
Comment 2•25 years ago
|
||
resolving as wontfix, may be invalid
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
I strongly disagree - this can't possibly be an invalid bug. Taking the liberty of reopening this one. ALL tooltips need a timeout! Check out what happens at http://www.macromedia.com/software/flash/ for instance: On pages with TABLE SUMMARY tags, there is no way to currently avoid that tooltip display on page at all times. It vanish for a brief sec while cursor moves, then returns - and remains. Till next time cursor is moved. When i've seen its content once - i've seen it. No need to display the same information 100 more times while i move cursor around to make tooltip go away so i can read what it covered? In NC a tooltip displays for a certain amount of time, and then automatically "turns off". You have to deliberatly move over that object once again to trigger the tooltip to display again. This is the way Mozilla should also respond to user input. Anything else will rapidly become an annoyance.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
sorry - it can't possibly be a "wontfix" i mean? There are currently tooltips just about everywhere, and they don't go away. This is ruining the user experience and i fail to see how persistant tooltips are of any informational value. I'd like a second opinion here.
Adding to CC. I also believe severity is too low for this one. Adding "needs timeout" to summary.
Summary: Tool Tips remain after loading new page → Tool Tips remain after loading new page - needs timeout
There are a couple of separate issues here. One issue is that tooltips (well, XUL popups in general) don't go away in all cases when the mouse leaves the element. In particular, if the element is deleted, I think the popup should go away ... but it doesn't. This is the real issue for this bug, and is why I am confirming the bug. Another issue is whether tooltips should time out or go away in some other fashion before the mouse has actually moved out of the element. This could be useful if the element is large. It could be done on a timeout, but I think it would be better done in response to a certain amount of mouse movement. This is more like a feature request and probably deserves a bug of its own.
Status: UNCONFIRMED → NEW
Ever confirmed: true
oh well - removing "needs timeout" from summary again and filing that as a separate bug.
Summary: Tool Tips remain after loading new page - needs timeout → Tool Tips remain after loading new page
Comment 9•25 years ago
|
||
I will take this bug to refer to the one tooltip that appears on the main body of the page given in the URL above. Any other problems with tooltips, such not going away on mouseOut, should be reported as a separate defect. accepting for future. If someone is really bothered by this behavior, either fix it, convince another mozilla developer to fix it, or nominate it for nsbeta3.
Status: NEW → ASSIGNED
QA Contact: ckritzer
Target Milestone: --- → Future
Comment 10•25 years ago
|
||
CC: Self I agree the severity is a little too low. It probably should be normal.
Updated•25 years ago
|
QA Contact: jrgm
Comment 11•25 years ago
|
||
Any tooltip should be dependent on the item which it is, uh, tooltipping. When the item disappears (as it does, in this case, as soon as the next page starts rendering), the tooltip should disappear at exactly the same time. Resummarizing.
Severity: trivial → minor
Summary: Tool Tips remain after loading new page → Tooltip should disappear when parent item disappears
Comment 12•24 years ago
|
||
->pinkerton, although this seems to have morphed into something I can't repro.
Assignee: trudelle → pinkerton
Status: ASSIGNED → NEW
Comment 13•24 years ago
|
||
May be related to bug 50511, "scrolling/app switching under mouse should cause mousemove".
Updated•15 years ago
|
QA Contact: jrgmorrison → layout.form-controls
Updated•3 years ago
|
Assignee: mikepinkerton → nobody
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•