64232 - Separate pref for chrome tooltips

Status: NEW

(Core :: XUL, defect, P4)

Description

[Cyd]

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

[Blake Ross]

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.

Comment 2

[Mike Pinkerton (not reading bugmail)]

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.

Comment 3

[Blake Ross]

I'll take a look.

Comment 4

[Boris Zbarsky [:bzbarsky]]

*** Bug 77908 has been marked as a duplicate of this bug. ***

Comment 5

[TommyBee (No E-mail)]

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.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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...

Comment 7

[Harald Glatt]

is bug 90476 a dupe of this?

Comment 8

[Blake Ross]

usability/polish 0.9.4.

Comment 9

[TommyBee (No E-mail)]

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

[Blake Ross]

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

[Blake Ross]

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

[Blake Ross]

pink...er...ton?

Comment 13

[Mike Pinkerton (not reading bugmail)]

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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 111751 has been marked as a duplicate of this bug. ***

Comment 15

[Hixie (not reading bugmail)]

*** Bug 89292 has been marked as a duplicate of this bug. ***

Comment 16

[R.K.Aa.]

*** Bug 118178 has been marked as a duplicate of this bug. ***

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 122104 has been marked as a duplicate of this bug. ***

Comment 18

[Blake Ross]

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

[Zack Weinberg (:zwol)]

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

[m_mozilla]

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

[Blake Ross]

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.

[e-mail], what other mac apps allow you to turn off tooltips?

Comment 22

[m_mozilla]

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

[Zack Weinberg (:zwol)]

> 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.

Comment 24

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

[timeless]

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

[R.K.Aa.]

*** Bug 124055 has been marked as a duplicate of this bug. ***

Comment 27

[Boris Zbarsky [:bzbarsky]]

*** Bug 176480 has been marked as a duplicate of this bug. ***

Comment 28

[R.K.Aa.]

*** Bug 197839 has been marked as a duplicate of this bug. ***

Comment 29

[Boris Zbarsky [:bzbarsky]]

*** Bug 226198 has been marked as a duplicate of this bug. ***

Comment 30

[Stefan Borggraefe]

*** Bug 280766 has been marked as a duplicate of this bug. ***

Comment 31

[Daniel Höpfl]

Attachment: Proposed patch (in C++-Part)

(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

[timeless]

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.

Comment 33

[[e-mail]]

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

[Daniel Höpfl]

Attachment: Proposed patch (detect GUI/content by node info/name)

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".

Comment 35

[[e-mail]]

Ah, you're looking at mSourceNode but I was looking at mTargetNode...

Comment 36

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 174376 [details] [diff] [review]
Proposed patch (detect GUI/content by node info/name)

sr- per Neil's comments....

Comment 37

[Daniel Höpfl]

Attachment: Proposed patch (detect GUI by scheme: chrome/resource)

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.

Comment 38

[Matthias Versen [:Matti]]

*** Bug 295123 has been marked as a duplicate of this bug. ***

Comment 39

[Daniel Höpfl]

Is there any hope to see this in the next release?

Comment 44

[Thomas D. (:thomas8)]

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.

Comment 45

[Elhem Enohpi]

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}

Comment 46

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 47

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.