Closed
Bug 494139
Opened 16 years ago
Closed 8 years ago
tooltip disappears on any keystroke which make screenshots impossible
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: christian.hoegl, Unassigned)
References
(Blocks 1 open bug)
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10
If you hover over a link with a title tag, its text is shown in a yellow tooltip box for a few seconds. But if you press any key it instantly disappears. This is not good if you want to make a screenshot with the tooltip still showing. But to invoke a screenshot you have to press command+3 (or whatever capture utility and key combination applies). Making screenshots of the mouse pointer hovering over menubuttons with the tooltip showing is a very useful and frequently used practice in providing help to novice users etc.
I think there has been a change of behaviour in one of the last updates, because this has worked before.
Reproducible: Always
Steps to Reproduce:
1. Hover over a link with a title tag
2. Wait for the yellow tooltip box to appear
3. Press SHIFT, ALT or any other key
Actual Results:
the tooltip disappears instantly
Expected Results:
the tooltip should have not been affected by a keystroke
If this behaviour was introduced on purpose it would be nice to be able to turn it off.
Comment 1•16 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090519
With prt sc no problem in any case.
Comment 2•14 years ago
|
||
This is a mass search for bugs which are in the Firefox General component, are
UNCO, have not been changed for 500 days and have an unspecified version.
Reporter, can you please update to Firefox 3.6.10 or later, create a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you still see the issue, please update this bug. If the issue is gone, please set the status to RESOLVED > WORKSFORME.
Whiteboard: [CLOSEME 2010-11-01]
Comment 3•14 years ago
|
||
No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
This is still a problem in Firefox 9, tested on Win XP.
Status: RESOLVED → REOPENED
Component: General → Event Handling
Ever confirmed: true
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → events
Hardware: x86 → All
Resolution: INCOMPLETE → ---
Whiteboard: [CLOSEME 2010-11-01]
Version: unspecified → 9 Branch
Comment 5•13 years ago
|
||
I can repeat it on Firefox 7, Windows 7.
But wouldn't consider this a bug. In windows 7 after a key stroke tooltip slowly fades out. This is logical as tooltip might block important part of the page.
IE 9, Chrome 14 do not hide tooltip on key stroke.
Opera 11.51 hide keystroke immediately after key stroke.
So I would consider a new feature: Implement fading tooltip.
Comment 6•12 years ago
|
||
I just had some frustrating times with this issue in Firefox 19.0.2 and MacOS 10.8. To screenshot I would normally use command-shift-3 or command-shift-4. Hitting the command key makes the tooltip instantly disappear.
dzlastlinux, in my usual browsing experience a tooltip lingers until I am no longer mousing over its element.
Comment 7•12 years ago
|
||
appears to be related to:
https://bugzilla.mozilla.org/show_bug.cgi?id=296191
and
https://bugzilla.mozilla.org/show_bug.cgi?id=113009
Comment 8•12 years ago
|
||
Ah, no it isn't, I just put this into the wrong bug window.
Comment 9•8 years ago
|
||
This should have been fixed by 1327908.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 8 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•