Closed Bug 183279 Opened 18 years ago Closed 14 years ago

Tabs don't have tooltips

Categories

(Camino Graveyard :: Tabbed Browsing, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Camino1.5

People

(Reporter: mikepinkerton, Assigned: stuart.morgan+bugzilla)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.8.1)

Attachments

(1 file)

6.00 KB, patch
bugzilla-graveyard
: review+
sfraser_bugs
: superreview+
Details | Diff | Splinter Review
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
we need a testapp here, or someone willing to listen to us at apple w/out one.
dagley? any ideas?
I'll see what I can come up with
might be worth seeing if this has been fixed in panther.
Target Milestone: --- → Camino1.1
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.
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.
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.
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.
Blocks: 235864
Assignee: pinkerton → me
Reply to comment 7:  No, tabs still don't have tooltips in Camino 2004121608
(v0.8+) with new tab implementation.
*** Bug 262246 has been marked as a duplicate of this bug. ***
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?
well...if apple didn't fix the bug, we need to leave them off....
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.
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 ;)
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).
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
Each tab item has a custom view for the tab itself (BrowserTabItemContainerView)
so this should be easy.
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
Assignee: me → mikepinkerton
QA Contact: bugzilla → tabbed.browsing
Target Milestone: Camino1.1 → Camino1.2
For reference, because it was so difficult to find, here's the checkin for bug 168719: http://tinyurl.com/qmt8y
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.
Blocks: 338983
Assignee: mikepinkerton → d.elliott
Status: NEW → ASSIGNED
No longer blocks: 338983
I am continuing to free up bugs that I am not working on at the moment for new coders.
Assignee: d.elliott → nobody
Status: ASSIGNED → NEW
Attached patch restore tooltipsSplinter Review
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.
Assignee: nobody → stuart.morgan
Status: NEW → ASSIGNED
Attachment #239803 - Flags: review?
Comment on attachment 239803 [details] [diff] [review]
restore tooltips

Also looks good. Thanks for fixing this, Stuart. Had me totally baffled.
Attachment #239803 - Flags: review? → review+
Attachment #239803 - Flags: superreview?(sfraser_bugs)
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.
Attachment #239803 - Flags: superreview?(sfraser_bugs) → superreview+
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.
Whiteboard: [needs checkin]
Checked in on trunk and 1.8branch
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [needs checkin]
Moving fixed "1.2" bugs to 1.1 where they were really fixed. Filter on CaminoFixed1.1 for bugmail purposes.
Target Milestone: Camino1.2 → Camino1.1
You need to log in before you can comment on or make changes to this bug.