Separate pref for chrome tooltips

NEW
Unassigned

Status

()

P4
normal
18 years ago
a year ago

People

(Reporter: cyd, Unassigned)

Tracking

Trunk
mozilla1.1alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

18 years ago
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

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

Comment 3

18 years ago
I'll take a look.
Assignee: ben → blakeross

Updated

18 years ago
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → mozilla1.0.1
*** Bug 77908 has been marked as a duplicate of this bug. ***

Comment 5

18 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

18 years ago
Target Milestone: mozilla1.0.1 → Future

Comment 7

18 years ago
is bug 90476 a dupe of this?

Comment 8

18 years ago
usability/polish 0.9.4.
Target Milestone: Future → mozilla0.9.4

Comment 9

18 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

17 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

17 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

17 years ago
pink...er...ton?
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

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Updated

17 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Updated

17 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

17 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.9
*** Bug 111751 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Target Milestone: mozilla0.9.9 → mozilla1.1

Updated

17 years ago
Blocks: 89292

Updated

17 years ago
No longer blocks: 89292
*** Bug 89292 has been marked as a duplicate of this bug. ***

Comment 16

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

Updated

17 years ago
Blocks: 122104
*** Bug 122104 has been marked as a duplicate of this bug. ***

Comment 18

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

17 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

17 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

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

17 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

17 years ago
*** Bug 124055 has been marked as a duplicate of this bug. ***
*** Bug 176480 has been marked as a duplicate of this bug. ***

Comment 28

16 years ago
*** Bug 197839 has been marked as a duplicate of this bug. ***
*** Bug 226198 has been marked as a duplicate of this bug. ***

Comment 30

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

Comment 31

14 years ago
Created attachment 173635 [details] [diff] [review]
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

14 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

14 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

14 years ago
Created attachment 174376 [details] [diff] [review]
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".
Attachment #173635 - Attachment is obsolete: true
Attachment #174376 - Flags: superreview?(bzbarsky)
Attachment #174376 - Flags: review?(neil.parkwaycc.co.uk)

Comment 35

14 years ago
Ah, you're looking at mSourceNode but I was looking at mTargetNode...
Attachment #173635 - Flags: superreview?(bzbarsky)
Attachment #173635 - Flags: review?(neil.parkwaycc.co.uk)
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

14 years ago
Created attachment 175010 [details] [diff] [review]
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.

Updated

14 years ago
Attachment #174376 - Attachment is obsolete: true
Attachment #175010 - Flags: review?(neil.parkwaycc.co.uk)
*** Bug 295123 has been marked as a duplicate of this bug. ***

Comment 39

13 years ago
Is there any hope to see this in the next release?
Assignee: bross2 → nobody
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → xptoolkit.menus
Duplicate of this bug: 360610
Duplicate of this bug: 391743

Updated

10 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
Duplicate of this bug: 489298

Updated

9 years ago
Duplicate of this bug: 533166
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)
Attachment #174376 - Flags: review?(neil)

Comment 45

a year 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}
You need to log in before you can comment on or make changes to this bug.