Open
Bug 64232
Opened 24 years ago
Updated 1 year ago
Separate pref for chrome tooltips
Categories
(Core :: XUL, defect, P4)
Core
XUL
Tracking
()
NEW
mozilla1.1alpha
People
(Reporter: cyd, Unassigned)
References
()
Details
Attachments
(1 file, 2 obsolete files)
11.95 KB,
patch
|
Details | Diff | Splinter Review |
Currently, the browser.chrome.toolbar_tips/"Show tooltips" preference (bug 56920, bug 60005) affects ALL the tooltips displayed by Mozilla. It's nice to be able to hide the chrome tooltips, as being told that the reload button "reloads current page" gets annoying the 100th time the tooltip appears. However, turning tooltips off also stops the browser from showing title attributes in rendered pages (see bug 1358.) The latter feature is extremely useful, for example in the MozillaZine buildbar (URL enclosed.) There should be two separate tooltip preferences, one for the chrome and the other for normal pages.
Comment 1•24 years ago
|
||
pink, is this yours? I think this would actually be quite easy because, iirc, we have a separate function (FillInHTMLTooltip(), or something?) for non-chrome tooltips.
Assignee: trudelle → pinkerton
Component: XP Toolkit/Widgets → XP Toolkit/Widgets: Menus
OS: Linux → All
Hardware: PC → All
Comment 2•24 years ago
|
||
how, pray tell, is the code supposed to know what is chrome and what is content? What about apps that aren't Navigator, such as Vixen or Komodo? I renew my objection to placing the policy decisions in the tooltip code as I should only have to provide the mechanism (return false from oncreate()) and let apps handle the policy, since only know best. over to xpapps.
Assignee: pinkerton → ben
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → mozilla1.0.1
Comment 5•23 years ago
|
||
I too was confused about this "Show tooltips" preference. I don't understand how one can call text from a link's TITLE tag a "tooltip" as links don't fall into the category of browser "tools" in my book.
why not make FillInTooltip return false (or whatever is required to cancel the creation of a tooltip) when "Show tooltips" is unchecked. In other words, make the turn-off-chrome-tooltips-feature a xul/js thing...
Updated•23 years ago
|
Target Milestone: mozilla1.0.1 → Future
Comment 9•23 years ago
|
||
Could this be something implemented in a popup menu? Here's my idea: Tooltips: None Toolbars Only Web Links Only (or "Link Titles Only" or something similar) All (default) I don't know if these options are feasible as separate entities, but it would be great for users to be able to select WHICH tooltips they desire -- there might be some users who want the toolbar tooltips but not the link titles, or vice versa. Just my two cents.
Comment 10•23 years ago
|
||
Jonas, we could return false in those cases. However, then we'll still be firing off tooltip timers and doing work, and only bailing at the end. pink, you wanted this to be an apps thing (and I agree it should), so I assume you don't consider this a problem...?
Comment 11•23 years ago
|
||
pink: this would also I think mean getting rid of the C++ pref checking code and doing this work in js. are you okay with that?
Comment 12•23 years ago
|
||
pink...er...ton?
Comment 13•23 years ago
|
||
as per my comment on 2001-01-07, getting the check out of the c++ and out of the toolkit altogether is a win. toolkit implements mechanism (return false to not show tooltip), application implements policy.
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Comment 14•23 years ago
|
||
*** Bug 111751 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.1
Comment 15•23 years ago
|
||
*** Bug 89292 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
*** Bug 118178 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
*** Bug 122104 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
I think I'm just going to remove the tooltip pref altogether. I don't know of any standard Windows app that lets users turn off tooltips in the chrome. That's (a) a function of the OS and (b) a total geek feature. And I can't see the usefulness of being able to turn off tooltips for webpage elements.
Comment 19•23 years ago
|
||
Arrrgh! No! Do you have any idea how obnoxious the chrome tooltips are? I've been leaving them on for the past couple weeks, just to see, and so content-area tooltips work. They're pure distraction once you know what the chrome does (which is mostly obvious to begin with...) Being able to turn them off is a basic usability feature, not a "geek feature". It's on the same level as controlling which toolbars to show. Are you going to take that out too?
Comment 20•23 years ago
|
||
re: windows apps don't let you turn them off Mozilla is not (just) a windows app. NN on mac lets you turn off chrome tooltips, loosing that feature in Mozilla is a nuisance
Comment 21•23 years ago
|
||
Toolbars are app-centralized. Most people wouldn't be so annoyed by all forms of toolbars, all shapes and sizes, that they'd want a pref in their operating system to turn them off everywhere. But tooltips are the same everywhere, and so if they're annoying in one place, they're probably annoying everywhere. And so it should be a pref in the operating system. If being able to turn off tooltips is a "basic usability feature," as you assert, then I assume that either Microsoft would have added a control to the operating system, or many apps would have taken it upon themselves to add a pref because of a flood of complaints from users. I don't see that this has happened. Why are you so annoyed by our chrome's tooltips? Possibly because our tooltip behavior is currently broken in a number of ways...? I hardly ever run into the tooltip on, as you said, the reload button. I generally tend to click buttons, not hover over them then click. But if you're finding that a number of tooltips are useless, file bugs to remove them. We don't *need* a tooltip on everything just for the sake of having a tooltip on everything. m_mozilla@wickline.org, what other mac apps allow you to turn off tooltips?
Comment 22•23 years ago
|
||
frankly, Netscape Navigator and Microsoft Internet Explorer are the only ones I can think of, but that may just be because other apps have them off by default, or I've always turned them off so early that I never had to think about them existing. Most apps use the OS's "baloon help" for tooltips, and you get volumes of information about everything you hover over when baloon help is implemented properly (for example, try using it BBEdit's Find dialog). And, the baloon help is turned on/off at the OS level. This is the "proper" way to do things in Mac OS... Well, before OS X. Now that OS X is here, I don't think there is any OS level function for this sort of thing. Baloon help is gone, and I don't have any inside info about whether it's likely to return, or to be replaced by anything, or whether that OS-level functionality is gone for good. I don't tend to hover over buttons either, but I do sometimes whip my pointer out of the page-rendering area to make reading easier. It's annoying when it lands somewhere that causes a tooltip to pop up and distract me. I'd love to be able to turn off chrome tooltips (but if I *had* to chose, I want to keep content tooltips even if it means I have to suffer through chrome tooltips). -matt
Comment 23•23 years ago
|
||
> But tooltips are the same everywhere, and so if they're annoying in > one place, they're probably annoying everywhere. IIRC, chrome tooltips were invented in order to deal with the sea of tiny pictograms appearing on toolbars in Word, which have no comprehensible relationship to their function. This was the *wrong* fix for the problem; the pictograms should have been changed to have an obvious relationship to their function, replaced with text, or eliminated altogether. However, given the constraint ("We Must Have Toolbars With Incomprehensible Pictograms!") they are a useful workaround. This does *not* stop them from being annoying. In Mozilla, the pictograms are large (too large, in fact), clearly labelled, and relatively obvious. Therefore, the tooltips are not just an annoyance, but a useless annoyance. The pictograms that _are_ confusing, where tooltips would be _helpful_, either don't have a tooltip at all, or show the wrong one - for instance, the bookmark icon at the left of the URL bar should have a tooltip saying "Bookmark this page" but what you get is the last tooltip string displayed anywhere. The mysterious status bar icons have no tooltips at all. The implementation chosen by Mozilla is particularly annoying: the font is the same size and family as the chrome label text, and the background color is almost the same gray as the default page and chrome backgrounds. This makes the tooltip appear to be some odd part of the page, if you're not paying attention. Notice how Word's tooltips are displayed in a small font and use a different color (bright yellow, IIRC) background from everything else? It is therefore obvious that they are not part of the chrome or document. This last complaint is also an irritation with text-area tooltips. [I am using the Classic theme, incidentally.] > And so it should be a pref in the operating system. Where such a pref exists, Mozilla should recognize and honor it; however, that doesn't mean the ability should be unavailable within the application. I hope I have illustrated above why tooltips might be less desirable in one application than another. Also, Windows is not the whole universe; I'm using a platform (Unix) where there is no such thing as an OS-wide preference.
Looked through the applications i have on my system. The following applications didn't allow turning off tooltips: Internet Explorer (automatically turns off when selecting icons with text) Outlook Express (automatically turns off when selecting icons with text) GetRight Mediaplayer Real player Acrobat Reader The following applications did allow turning off tooltips: All MS-Office applications All Visual Studio applications mIRC TextPad WinAmp WinZip ICQ (I have not listed applications that don't have tooltips at all)
Comment 25•23 years ago
|
||
fwiw mpt has repeatedly noted that we have to ignore macos's baloonhelp pref because when it's on, users can't do anything w/o getting ballons for standard widget elements, so everyone turns them off.
Comment 26•23 years ago
|
||
*** Bug 124055 has been marked as a duplicate of this bug. ***
Comment 27•22 years ago
|
||
*** Bug 176480 has been marked as a duplicate of this bug. ***
Comment 28•21 years ago
|
||
*** Bug 197839 has been marked as a duplicate of this bug. ***
Comment 29•21 years ago
|
||
*** Bug 226198 has been marked as a duplicate of this bug. ***
Comment 30•20 years ago
|
||
*** Bug 280766 has been marked as a duplicate of this bug. ***
Comment 31•20 years ago
|
||
(This is my first Mozilla patch so please be generous ...) My Bug 280766 was marked as duplicate of this one. Since this bug seems to exist for 3 years without any improvement I decided to fix it. I do not know Mozillas code good enough to move the handling from the C++-part into the JavaScript-part so this patch is only an improved C++ part. I'm not sure if it catches all possible situations but as far as I could test it seems to work. The patch also modifies the preferences dialog to include the new setting (Appearance pane).
Comment 32•20 years ago
|
||
Comment on attachment 173635 [details] [diff] [review] Proposed patch (in C++-Part) just a note about mozilla style (and yes it's not your fault, the current code does not follow the style), it's frowned upon to have an 'else' immediately after a 'return'. instead the |else| token should be ommited and the following block shouldn't be indented. >+ if (sShowGUITooltips) { >+ mRootBox->GetDefaultTooltip(aTooltip); >+ NS_IF_ADDREF(*aTooltip); >+ } >+ return NS_OK; > } else { > nsAutoString tooltipId; > targetEl->GetAttribute(NS_LITERAL_STRING("tooltip"), tooltipId); i'm also not particularly fond of the ui you selected for prefs. but for the time being i'm just going to pass this to neil/bz.
Attachment #173635 -
Flags: superreview?(bzbarsky)
Attachment #173635 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 33•20 years ago
|
||
I'm not a fan of the way you code in a special meaning for aHTMLTooltip. A few alternatives that spring to mind: 1. Detect whether the hovered element is in the same document as the tooltip 2. Detect whether the hovered element is in a web page (i.e. not chrome://) (this allows tooltips in remote XUL applications to continue to function) 3. Detect whether the hovered element is loaded into a browser (to allow titletips in about:config to continue to function)
Comment 34•19 years ago
|
||
I tried to implement each one of your suggestions but failed for 1 and 2: 1) It seems that the document is the same for GUI elements/tooltips as well as it is for content targets/title-tips. I'm not completelly sure here but invested some time in it and did not get a better result. 2) Could also be my small knowledge of Mozillas classes but everything I tried returned chrome:// (BaseURI) or http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul (GetNamespaceURI). No difference between GUI/content. 3) That's the way the new patch works. If the target node name is "browser" (or "editor" - Composer) it is considered a content object. In any other case it is handled as GUI element. The preferences are implemented the same way they were in the first patch. I tested it without the group box but then the labels are quite long and hard to read. A popup does not fit here in my opinion since this is not an kind of "One-Of-Some-Options" but a "Some-Of-Some-Options".
Attachment #173635 -
Attachment is obsolete: true
Attachment #174376 -
Flags: superreview?(bzbarsky)
Attachment #174376 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 35•19 years ago
|
||
Ah, you're looking at mSourceNode but I was looking at mTargetNode...
Updated•19 years ago
|
Attachment #173635 -
Flags: superreview?(bzbarsky)
Attachment #173635 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 36•19 years ago
|
||
Comment on attachment 174376 [details] [diff] [review] Proposed patch (detect GUI/content by node info/name) sr- per Neil's comments....
Attachment #174376 -
Flags: superreview?(bzbarsky) → superreview-
Comment 37•19 years ago
|
||
Now using the target node to discover the scheme. GUI is still the same. Change in existing code: The timer is only created if there is a tip to display.
Updated•19 years ago
|
Attachment #174376 -
Attachment is obsolete: true
Attachment #175010 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 38•19 years ago
|
||
*** Bug 295123 has been marked as a duplicate of this bug. ***
Comment 39•19 years ago
|
||
Is there any hope to see this in the next release?
Updated•17 years ago
|
Assignee: bross2 → nobody
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → xptoolkit.menus
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
Comment 44•10 years ago
|
||
Comment on attachment 175010 [details] [diff] [review] Proposed patch (detect GUI by scheme: chrome/resource) Cancelling outdated review request. Feel free to re-request review after ensuring patch still applies.
Attachment #175010 -
Flags: review?(neil)
Updated•10 years ago
|
Attachment #174376 -
Flags: review?(neil)
Comment 45•7 years ago
|
||
Starting with Firefox 50.0, it seems that setting browser.chrome.toolbar_tips false no longer prevents tooltip display for HTML "title" attributes. In lieu of a separate preference for those, the following works reasonably well in userChrome.css: /* Do not display tooltip popups for HTML "title" property */ #aHTMLTooltip, #remoteBrowserTooltip {display: none !important}
Updated•2 years ago
|
Severity: normal → S3
Comment 46•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 15 duplicates.
:enndeakin, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(enndeakin)
Comment 47•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Flags: needinfo?(enndeakin)
You need to log in
before you can comment on or make changes to this bug.
Description
•