183279 - Tabs don't have tooltips

Status: RESOLVED FIXED

(Camino Graveyard :: Tabbed Browsing, defect)

Description

[Mike Pinkerton (not reading bugmail)]

In bug 168719, we had to disable tooltips on tabs to work around a topcrash
caused by (what we surmise) an apple bug.

opening this bug to resolve the issue allowing us to close out 168719

Comment 1

[Mike Pinkerton (not reading bugmail)]

we need a testapp here, or someone willing to listen to us at apple w/out one.
dagley? any ideas?

Comment 2

[Steve Dagley]

I'll see what I can come up with

Comment 3

[Mike Pinkerton (not reading bugmail)]

might be worth seeing if this has been fixed in panther.

Comment 4

[Kurt Weinschenker]

When we say 'tooltips' here, is this a radio button on the tab that allows me to
close the tab with a mouse click?

Having to use a keyboard shortcut to close a tab annoys me from time to time.

Camino nightly build 20040208, Mac OS 10.2.3.

Comment 5

[Kurt Weinschenker]

I suppose we could mark this FIXED since the new icon set, and close button in
tabs came in at the end of February?

Just a thought.

Comment 6

[Stuart Morgan]

No, tooltips are the little floating mouse-over boxes that, in the case of tabs,
used to display the full title of the tab (useful when many tabs caused the
title to be truncated).  Definitely not a fixed issue.

Comment 7

[Bruce Davidson]

Now that bug 235782 has landed our own implementation of tabs, the Apple bug (if
that is what it was) should no longer be an issue.

Comment 8

[Warren TenBrook]

Reply to comment 7:  No, tabs still don't have tooltips in Camino 2004121608
(v0.8+) with new tab implementation.

Comment 9

[Jungshik Shin]

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

Comment 10

[Samuel Sidler (old account; do not CC)]

Ping.

Is this one anyone's radar? How simple is this to fix? Since we've implemented
our own tabs, is this just a quick "turn the feature back on" sort of thing?

Comment 11

[Mike Pinkerton (not reading bugmail)]

well...if apple didn't fix the bug, we need to leave them off....

Comment 12

[Samuel Sidler (old account; do not CC)]

I guess this sounded like it was something with the old, Apple provided tabs. I
figured the (Apple) bug may not be present with our new tabs.

Comment 13

[Mike Pinkerton (not reading bugmail)]

my undertstanding is that our tabs still use a lot of the os tab machinery, we
just override some of the classes to do our own drawing. that could be wrong,
but i'm pretty sure that was geoff's answer when I asked him.

josh? do you remember differently? i recall the conversation we had about it in
geoff's dining room, but not the actual answer ;)

Comment 14

[John Bailey]

Something else that would be very nice;
If it displays the page title, then it could also display the URL below the
title.  Maybe two return carriages to space it out nicely?

If there is no title, then it only displays the URL (obviously).

Comment 15

[Chris Lawson (gone)]

Am I correct in assuming we'll be able to add this back in regardless of Apple's
bug once we drop 10.2 support? Or is the bug more pervasive than that?

Simon's recent tooltips-for-bookmarks checkin (bug 311453) looks like it could
be applied pretty easily to this one, if the bug we were seeing can be avoided.

cl

Comment 16

[Simon Fraser [no longer active]]

Each tab item has a custom view for the tab itself (BrowserTabItemContainerView)
so this should be easy.

Comment 17

[Chris Lawson (gone)]

Anyone know why this (inserted into line 468 of BrowserWrapper.mm) isn't working?

  [[(BrowserTabViewItem*)mTabItem tabItemContentsView] setToolTip:[NSString
stringWithFormat:@"%@ (%@)", titleString, urlString]];

I don't get tooltips anywhere when I do that.

cl

Comment 18

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

For reference, because it was so difficult to find, here's the checkin for bug 168719: http://tinyurl.com/qmt8y

Comment 19

[Simon Fraser [no longer active]]

Tooltips on tabs were a big performance issue too (and probably will be still). Any time you have lots of tracking rects in a window, things bog down.

Comment 20

[Desmond Elliott]

I am continuing to free up bugs that I am not working on at the moment for new coders.

Comment 21

[Stuart Morgan]

Attachment: restore tooltips

Enables tooltips for tabs (and does some cleanup for the existing tracking rect creation loop as well).  We're maintaining these tracking rects ourselves, so OS bugs shouldn't come into the picture.  Also rips out the old disabling code, since I'm pretty sure it hasn't been doing anything since the tab rewrite anyway (and fixes a warning while in the file).

We'll have to see if perf becomes an issue, but we already have two rects per tab (the tab highlight tracking and the tab close icon highlight tracking) without anyone complaining--and if it came down to it I think we'd be better off without close button hovering than tooltips.

Comment 22

[Chris Lawson (gone)]

Comment on attachment 239803 [details] [diff] [review]
restore tooltips

Also looks good. Thanks for fixing this, Stuart. Had me totally baffled.

Comment 23

[Simon Fraser [no longer active]]

Comment on attachment 239803 [details] [diff] [review]
restore tooltips

Please test performance with lots of tabs; this used by be a big problem with the old tabs on 10.2.

Comment 24

[Stuart Morgan]

I'll try some before/after testing of nightly builds once this lands; if it's an issue I'll see if there are ways we can cut down on tracking rects.

Comment 25

[froodian (Ian Leue)]

Checked in on trunk and 1.8branch

Comment 26

[Samuel Sidler (old account; do not CC)]

Moving fixed "1.2" bugs to 1.1 where they were really fixed. Filter on CaminoFixed1.1 for bugmail purposes.