Open Bug 32157 (titletips) Opened 20 years ago Updated Last year

Title tips (tooltips) for cropped text


(Core :: XUL, defect, P3)





(Reporter: eric, Unassigned)


(Depends on 1 open bug, Blocks 3 open bugs, )


(Whiteboard: [adt2][ue])


(5 files, 5 obsolete files)

XUL <text> tag needs to be able to support a type of cropping that pops the full 
text up as a tool tip on top when you move over it. This is the 4x behavior in 
mail news then moving over cropped message summaries.

Estimated time: 2 days
Target Milestone: --- → M16
*** Bug 9676 has been marked as a duplicate of this bug. ***
Whiteboard: 2 days
Here is a present Ben. You should be able to do this entirely with XBL!
Assignee: evaughan → ben
Target Milestone: M16 → M17
Keywords: nsbeta2
Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.
Whiteboard: [nsbeta2+][5/16]
clearing nsbeta2+ for reconsideration.

a) This is a somewhat minor feature and it's past 5/16
b) I have no way of telling when a text node's text is being cropped. If I am 
able to access this information, this feature becomes easier to implement. 

Whiteboard: [nsbeta2+][5/16]
Putting on [nsbeta2+] radar for beta2 fix.   Always display whether cropped or 
Whiteboard: [nsbeta2+]
you don't understand. this would be incredibly annoying. tooltips have issues 
where they eat events (try playing around with the folder list in mail and 
you'll often find the tooltips themselves get in the way of context menus etc). 
Doing this to every element in the threadpane would not be good at this point. 
Yes this is a desirable feature. No, it is not the right time to be doing it. 
Re-clearing the nsbeta2+ for reconsideration.
Whiteboard: [nsbeta2+]
Whiteboard: [nsbeta2-]
Target Milestone: M17 → M20
Nav triage team: Peter please let us know if the back end work (knowing when a 
text node's text has been cropped) has been done. If not, this should be 
Assignee: ben → trudelle
No, it has not been done, and the support as requested would decrease tree
performance.  Some way of doing this lazily on mouseover would be preferable.
BTW, both this and column resizing have been marked nsbeta2-, which is a very
bad combination.
reassigning to hyatt
Assignee: trudelle → hyatt
this one really hurts, but we have resizable columns now, so...  ->future.
Target Milestone: M20 → Future
*** Bug 26233 has been marked as a duplicate of this bug. ***
Blocks: 60556
*** Bug 60556 has been marked as a duplicate of this bug. ***
Assignee: hyatt → ben
Blocks: 62586
Any thoughts on doing this in the next cycle? Ben, Eric?
Keywords: nsbeta2nsbeta1
Whiteboard: [nsbeta2-]
*** Bug 64747 has been marked as a duplicate of this bug. ***
I can't believe this bug has been lingering around for 9 months. The original
netscape reporter of this bug estimated the time to fix this at 2 days!!!

There is a limit as to how much one can increase the collumn width in message
headers, or how wide one can make the mysidebar to see ones bookmarks properly
without rendering webpages unreadable because so many of them require a lot of
screen width. Even THIS page is way too wide, but typical of the
screen-greedyness of webpage designers.

This is an important feature that needs to be implemented very soon. I suggest a
milestone on mozilla0.8. Please fix this soon. Thank You.
I think if you read the history of the bug its a little more complicated than
originally thought, which isn't to say it shouldn't be done.
... not really, since it was suggested that a "lazy mouseover" (2000-07-21
15:34) could do the trick without changes to the backend.
How about if the tool tip appeared just BELOW the line of text? That way the
tool tip would not get in the way of context menues (ben, 2000-05-26 00:17).

Ben, if this is a good solution, would you be motivated to start fixing this bug?

Is there a bug# for "back end work (knowing when a text node's text has been
cropped)"? It seems like there is no movement on that issue there either. Should
we really wait for this nebulous event? The tool tips could LATER be modified to
only appear when text is being cropped. But for now, it is important to finally
implement this needed feature.
*** Bug 64307 has been marked as a duplicate of this bug. ***
The other bug also requested that the URL be displayed in the status bar when
hovering over a bookmark in mysidebar (or anywhere else).

Could this be implemented here too?
its usually best to keep bugs well defined otherwise they go soggy and there's 
less chance of them getting closed.  If there's already a bug on showing 
tooltips in the status bar (which sounds a bit naff to me), then its best left 
where it is.
ben, do you want to look into displaying URL in title bar or should i make a
separate bug?

Simon, it is the "URL" not tooltip to be displayed in the status bar! It is not
naff", hover over a link on a webpage, the URL is currently displayed there. It
is a very useful feature.

Is Ben even monitoring this bug, he hasn't posted since last May? Ben, are you
Hence my comment about not mixing up different issues in the one bug report and 
I think you'll find that Ben has had all the mail on this from all the traffic 
I'm sure he'll contribute if and when he can. 
Suggest to change summary to: 

*Tool Tips (Title Tips) needed for Cropped Texts in Sidebar & Message Headers*

I think this is a very significant and badly needed feature, and a more
recognizable summary will draw more attention to it. I think most people refer
to what we are talking about as "Tool Tips" and not "Tiltle Tips".

It already works in Message Folders. I don't uderstand why it is taking so long
to migrate this feature to the other areas.
This feature affects the usability of mozilla. Strongly suggest to designate a
milestone of at least mozilla1.0 - anyone? Keyword?

If the developers mostly use a resolution of 1280 or even 1600 (I'm assuming),
please consider that most of us use 1024 or even 800 and cannot see the entire
subject lines of message headers or bookmark texts in the sidebar. This
seriously hampers the usefulness of mozilla for daily use.
Mailnews could really use it and we'd take advantage of it if it got implemented.

It actually doesn't work in the message folders.  We are using tooltips to
simulate it. Currently the tooltips show up regardless if cropping has occurred. 
Could you please also "simulate" it in bookmarks in the sidebar until it is
I suggest that the title be changed to "cropped tree items should get tooltips 
onmouseover" and that bug 42136 be marked as a duplicate (or dependent, like 
bug 62586).  Or does this bug apply to things other than trees?
Updating summary to include 'tooltips' and 'cropped' --to ease the search. It
took me several jumps from other 'tooltips' bugs before reaching this one.
Summary: [feature] title tips → [feature] title tips (tooltips for cropped texts)
On a personal level, this is one that is really annoying for me not to have. I 
rely on these so much.
Keywords: 4xp, mail3
cc'ing hyatt because he's talked about the possibility of this for the outliner.
Blocks: 42136
Nominating for 1.0 because this can be really annoying. At the current size most
of my subjects in the mail pane are cropped, large sender lines are cropped and
the date column is too narrow that you don't see the time

I also suggest nsCatFood but not making that nomination myself as I tend not to
add ns keywords.
Keywords: mozilla1.0
This is no longer a ben thing.  It's now special to outliner.
Assignee: ben → hyatt
great, maybe some movement at last :)
Target Milestone: Future → mozilla1.0
Keywords: nsCatFood
still a ben thing. working on a patch. I currently have tooltips coming up 
almost at the right position over outliner cells. Need to correct positioning, 
make them never hide, and make them only show on cells with cropped text. 
Assignee: hyatt → ben
nav triage team:

Marking nsbeta1+ and p4.
Keywords: nsbeta1nsbeta1+
Priority: P3 → P4
Blocks: 75698
Ben: in case you didn't know, there's an undocumented attribute for tooltip
popups, noautohide="true". This will prevent the tooltip from disappearing until
the mouse leaves the content node.
Blocks: 77623
nav triage: this is not a Netscape beta or rtm stopper. 
I myself think that this is a major usability issue. It's annoying having to
resize columns or whatever to see all of a cropped text. I think it could
seriously detract from the user satisfaction of the next Netscape release. But I
don't make these decisions...
Renominating given status of the bugs this blocks.
Keywords: nsbeta1-nsbeta1
*** Bug 74697 has been marked as a duplicate of this bug. ***
I can't imagine ANY user not being annoyed by not being able to see cropped
texts. Please reconsider making this *nsCatFood+*
Renominating for catfood per plairo, cc'ing selmer.  A bunch of 6.0 reviews 
noticed this missing feature.
Keywords: nsCatFood-nsCatFood
In Mail, this is a big usability issue. This is one of the main features that 
keeps me from using mozilla fulltime.
This is mostfreq if dependencies are counted.
Keywords: mostfreq
nav triage team:

This is a nice one to have but Ben doesn't have time for this for mozilla0.9.1. 
Marking mozilla0.9.2 and nsbeta1+
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla1.0 → mozilla0.9.2
*** Bug 80490 has been marked as a duplicate of this bug. ***
Keywords: nsCatFoodnsCatFood+
outliner work by people in the nav group has been deprioritized. .9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Blocks: 77624
Target Milestone: mozilla0.9.3 → mozilla1.0
Could the summary *brackets* () please be fixed. This bug might as well "look"
purdy while it's being moved back, and back, and back :(

[feature] title tips (tooltips for cropped texts)

[feature] title tips (tooltips) for cropped texts

There must be some serious other problems to justify moving this back again
Blocks: 80221
Depends on ability to reliably locate cropped text portion of outliner row.
Depends on: 74831
Depends on: 91460
Depends on: 91462
I've created bug 91462 to deal with the "ability to locate cropped text portion
of outliner row".

I've also created bug 91460 so that we can see title tips no matter whether the
text is cropped or not as an interim solution, and step towards fixing this long
overdue bug.

PS. Could someone please correct the incorrect summary?
Correcting summary to keep Peter happy :-)
Summary: [feature] title tips (tooltips for cropped texts) → [feature] Title tips (tooltips) for cropped texts
*** Bug 92681 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
Attached patch patch (obsolete) — Splinter Review
The patch above implements titletips.  Just hover over any cropped cell in any
outliner (mail thread pane, history sidebar, etc... ) and wait about half a
second and a tooltip will appear showing the full text of the cell.

I know somebody wants to review this sucker!
I must say this is absolutely cool !
Only one nit, you don't need own getOutlinerBody() method. There is
d00d, I am salivating.

couple of points though:

1) title tips don't have a delay! at least make it optional if you want one. 
2) Maybe I'm missing something but it doesn't look like:
+    nsAutoString cell; cell.AssignWithConversion("cell");

is ever used.

taking from his Goodgerness.
Assignee: ben → hewitt
Would you mind changing this:

+  boolean isCellCropped(in long row, in wstring colID);


+  boolean isCellCropped(in long row, in AString colID);

And then changing your cpp implementations to:

+nsOutlinerBoxObject::IsCellCropped(PRInt32 aRow, const nsAString& aColID,
PRBool *_retval)

+nsOutlinerBodyFrame::IsCellCropped(PRInt32 aRow, const nsAString& aColID,
PRBool *_retval)

+    if (!colID.EqualsWithConversion(aColID))

Since both colID and aColID are wide-char strings, no need for the WithConversion.

Can you add some // XXXjag fix nsIRenderingContext to use nsAString to the
cellText line? Or file a bug on me or something. It's a shame we need to make a
copy there :-)
To set the font, you might want to simply do (moving the declaration next to 
where it is used):
+ const nsStyleFont* fontStyle = textContext->GetStyleData(eStyleStruct_Font);
+ rc->SetFont(fontStyle->mFont);
That will eliminate the chunk of code to GetDeviceContext, GetMetricsFor, ...
Attached patch revised patch, post reviews (obsolete) — Splinter Review
Nominating for m0.9.4 since the long-awaited patch is finally there there...
Keywords: mozilla0.9.4
OS: Windows NT → All
Hardware: PC → All
Target Milestone: mozilla1.0 → mozilla0.9.5
No longer depends on: 91462
*** Bug 91462 has been marked as a duplicate of this bug. ***
So, what sections of code have changed? (To prevent me from having to re-read
the whole thing) ;) 
Summary: [feature] Title tips (tooltips) for cropped texts → [feature] Title tips (tooltips) for cropped text
*** Bug 77623 has been marked as a duplicate of this bug. ***
Depends on: 101677
Priority: P4 → P2
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Keywords: mail3nsbeta1
*** Bug 102917 has been marked as a duplicate of this bug. ***
Attachment #45502 - Attachment is obsolete: true
Attachment #45687 - Attachment is obsolete: true
Attached patch new patchSplinter Review
As for the changes to nsEventStateManager.cpp and nsDOMEvent.cpp, here's some

- You'll leak |curContent| in the first two changes in nsEventStateManager.cpp,
make |curContent| a nsCOMPtr<nsIContent> in stead of a raw pointer.

- In nsEventStateManager.cpp:

+    nsCOMPtr<nsIDOMXULDocument> xulDoc = do_QueryInterface(doc);
+    nsCOMPtr<nsIDOMNode> popupNode;
+    xulDoc->GetPopupNode(getter_AddRefs(popupNode));

all documents are not nsIDOMXULDocuments, add a null check (since other XML
documents can have elements named "tooltip", even if they're not in a XUL document.

- In nsEventStateManager.cpp:

+    nsIFrame* bodyFrame;
+    presShell->GetPrimaryFrameFor(popupContent, &bodyFrame);
+    if (bodyFrame) {

initialize |bodyFrame| to nsnull to make sure you don't access uninitialized
memory in case the GetPrimaryFrameFor() call fails.

Other than that, nsEventStateManager.cpp and nsDOMEvent.cpp changes look good,
sr=jst, but joki, hyatt or saari should have a look too.
Comment on attachment 55154 [details] [diff] [review]
new patch

r=sspitzer (on the mailnews changes).
Attachment #55154 - Flags: review+
hewitt -- content nodes are refcounted... you need to use an nsCOMPtr when you
call GetContent on the frame or you will leak them.  The mousewheel handling
code looks fine other than that.

Target Milestone: mozilla0.9.6 → mozilla0.9.7
Summary: [feature] Title tips (tooltips) for cropped text → [RFE Title tips (tooltips) for cropped text
Summary: [RFE Title tips (tooltips) for cropped text → [RFE] Title tips (tooltips) for cropped text
Depends on: 109025
Depends on: 108757
Closed: 18 years ago
Resolution: --- → FIXED
Really cool.  Is there another bug somewhere for the click not passing through
to what's underneath, though?  This really hinders their usability.
verifying by testing on mail folders, bookmarks sidebar, and the mail message
list using a Dec 5 build

And from the bug reports such as 113621, this works on other OSes as well.
I had to turn titletips off for now, there are annoying issues still to be fixed
and I'd rather not have everyone suffer while I fix them.
Resolution: FIXED → ---
Target Milestone: mozilla0.9.7 → mozilla0.9.8
I had to turn titletips off for now, there are annoying issues still to be fixed
and I'd rather not have everyone suffer while I fix them.
Depends on: 113536
*** Bug 64307 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
nsbeta1+ per Nav triage team
Keywords: nsbeta1nsbeta1+
*** Bug 114435 has been marked as a duplicate of this bug. ***
Whiteboard: [adt3]
Summary: RFE <> Severity: normal?
This seems an important bug fo usability. Suggest to remove "RFE" from summary.
*** Bug 134759 has been marked as a duplicate of this bug. ***
This bug is heavily laden with taget milestone and keywords. This important bug
should come in early enough *before* 1.0 to allow some testing.
Joe, is the code still in there somewhere, or did you back out everything?  I'd
be willing to take a look at this if you can give me something to start with and
describe some of the problems.
nsbeta1- per Nav triage team
Keywords: nsbeta1+nsbeta1-
Whiteboard: [adt3]
Target Milestone: mozilla1.0 → mozilla1.2alpha
13 dups (with some containing their own dups). 
I really think this needs to be fixed.
FWIW, It is also a feature that Vivendi Universal is tracking and critical to 
the usability of our application.  
This is an enhancement request, new behavior which was scheduled to be
implemented for MachV, but wasn't finished due to flakey behavior and higher
cost than anticipated.  We are way past the point of adding new features in this
release, especially ones with high risk like this one.  We should be able to get
it on our P1 list for the next point release.
I just want to note that this is also a usability issue. For example, I could
not see the titles in mail. This should not be considered a new feature but a
defect in the current implementation.

I'd like to suggest removing the [RFE] from the summary.
Whiteboard: [ue]
Summary: [RFE] Title tips (tooltips) for cropped text → Title tips (tooltips) for cropped text
Nominating for buffy.
Keywords: nsbeta1-nsbeta1
Again, I would gladly take a look at this if I could look at the existing code
that was backed out.
hewitt would, of course, have a more complete answer, but Dean, have a look
at from and possibly also from (which are rev 1.2 and
rev 1.3 of layout/xul/base/src/nsXULTooltipListener.cpp

Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1nsbeta1+
Whiteboard: [ue] → [ue][adt2]
Thanks Joe.  I'm now at least able to turn these back on to play around with. 
For anyone that's interested, just remove the "#ifdef DEBUG_crap" in

Another thing to note when trying to implement these again is that the titletips
shouldn't be repositioned to the left if they don't fit on-screen.  Tooltips do
this, but the titletips should stay over the tree cell.
I of course meant thanks John, not Joe.  Sorry for the spam.
Blocks: 160730
random notes:

1. To get the tooltip label filling, need to change PR_FALSE to PR_TRUE in 

  aTooltip->SetAttr(nsnull, nsXULAtoms::label, label, PR_FALSE);

2. Message sequence when clicking on a tooltip, regardless of the button:

3. What about on other platforms, is the sequence the same?

4. Nowhere in there is there a mouse message.  Is there a way to distinguish 
what mouse button caused NS_PLUGIN_ACTIVATE?  Maybe there's an WM_MOUSEACTIVATE 
message that's getting eaten.  If so, is it safe to let those pass through for 
PLUGIN_ACTIVATE and LOSTFOCUS only occur on windows.  LOSTFOCUS is only
important if the isMozWindowTakingFocus field of the event is false (can you
check that?).  I'm not sure what we use PLUGIN_ACTIVATE for.
NS_PLUGIN_ACTIVATE is what WM_LBUTTONDOWN is mapped to on Windows.
Blocks: majorbugs
No longer blocks: majorbugs
Blocks: majorbugs
The NS_PLUGIN_ACTIVATE issue is bug 113536.
Keywords: mozilla1.0mozilla1.2
*** Bug 62586 has been marked as a duplicate of this bug. ***
Blocks: 176238
"Mozilla1.2alpha" is long gone. Please update the Target Milestone (and KW?).

IMO this is now the most important and visible bug in all of Mozilla.
Keywords: mozilla1.2mozilla1.3
Dean: Any news on how things are going? Thanks for taking a look at this since 
most people would probably agree this is a very important issue and something 
that really puts Mozilla at a disadvantage in terms of usability compared to 
other software. Do you think this has a possibility of at least getting on the 
trunk by 1.3a?

I rolled it back since the milestone was out of date as Peter noted.
Added alias: titletips
Alias: titletips
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
Brian: I haven't looked at this in a little while.  I'm trying to figure out
where Joe was heading with the rollup listener idea (bug 113536 comment 41). 
I've got a couple of other ideas that I may try sometime soon, but my thinking
is that we may need a tooltip class that is separate from menu popups.
Over to jag.
Assignee: hewitt → jaggernaut
"Mozilla1.3alpha" is long gone. Please update the Target Milestone to
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b-
Clearing milestone for now, I doubt it's going to make 1.3b or 1.3 final.
Target Milestone: mozilla1.3alpha → ---
*** Bug 192448 has been marked as a duplicate of this bug. ***
Whiteboard: [ue][adt2] → [adt2][ue]
Target Milestone: --- → mozilla1.4alpha
(Three years old!)

Is this proof that they've made Mozilla code too complicated for a normal human
programmer to fix?  IMO (and everyone elses, apparently) this is the most basic
feature that any first year programer can deal with.  The debate on how to do
this (here) is simply amazing!  How over complicated can they make the most
basic feature?

The last sad comment on this bug:
"Clearing milestone for now, I doubt it's going to make 1.3b or 1.3 final."

This is a serious Usabilty issue.  A function that would be used many times per

Please, stop adding new features and fix the basics!
> IMO (and everyone elses, apparently) this is the most basic feature that any
> first year programer can deal with.

So we can expect your patch soon then?
Cut the spam, please.
Flags: blocking1.4a?
cmorley: As you can see, this bug depends on two bugs:
Bug 74831
Bug 113536

so its obviously not a quick-bang job. Even if both those bugs had new patches
submitted today, they might not be r=, and s= within the next two months judging
by the way other patches are going. Bug 74831 has an old patch and probably
needs it updated. Bug 113536 has no patch, although bug 11356 comment #44
mentioned that a related bug has been fixed.

Unlike a small personal programming project, bug-fixes require time for review,
superreview, and testing and also developers have a lot of bugs they are working
on. Your highest priority bug might not be a developer's highest priority bug
because, for instance, you might not be aware of a crash issue they are working on.
*** Bug 136662 has been marked as a duplicate of this bug. ***
So there are some problems. The biggest problem is that mousedown/click won't
go through the titletip, so you'll have to wait for the titletip to disappear
(ca. 5 seconds) before you can do anything with the treecell behind it.

I've tried fixing this, but it's rather hard. With some luck I can deal with
this in the tooltip listener's mousedown handler by redispatching the event to
whatever cell the titletip is for. That is, if I can figure out why that
mousedown handler currently isn't called at all. mouseup does get called
though, so the tooltip is at least receiving some mouse events. Btw, this
happens on both Mac and W2k. On W2k it looks like nsWindow::WindowProc is never
called for mousedown on the titletip, which is a bit odd. Spy++ shows that the
mousedown message is sent to the titletip native window, so ...

I have a patch to the rolluplistener code by hewitt that at least makes the
titletip go away when clicked on. If all else fails, perhaps we can take that
as an intermediate solution to getting titletips.

Smaller warts are that (IMO) the titletip should appear immediately instead of
after a small delay, and it should only remain as long as you're over the
cropped cell (in other words, moving from a column with cropped text, titletip
showing, to a column to the right of it, should make the titletip disappear as
soon as you hit the second column). There is a small alignment issue (2 or 3 px
too far to the left) for titletips on a cell that contains an icon (e.g. folder
jag: I suppose you probably know, but see bug 113536 comment 6 and 7. Sorry if
it's irrelevant/useless - just wanted to make sure you don't waste time on
something that has already been discovered.
I've just added this patch to my tree and having tooltips for bookmarks and
history rocks :-D

I find an easier workround for not being able to click through the tooltip is to
just move the cursor up a few pixels 'til the tip disappears then back down and
click rather than wait 5 secs for it to clear. It needs fixing but it's
perfectly usable until it is IMO.

One bug (not in this patch) is that it appears that the text has to be cropped
by ~10% before it will show a tooltip; it should really appear even if the text
is cropped by a single character.

Real example of why this is a problem. I have 2 bookmarks

Checkins to module SeaMonkeyAll in the last day:
Checkins to module SeaMonkeyAll in the last week:

I don't get tooltips until the word 'last' gets cropped, so

Checkins to module SeaMonkeyAll in the last...

Is it 'day' or 'week'?
click-through is hard to fix, but here's the next best thing: tooltips for free
on trees!
So in nsTreeBodyFrame::GetCellWidth we forgot to add the cell image margin,
which caused us to not always correctly detect "IsCellCropped".
Attachment #117992 - Attachment is obsolete: true
That's better. The tip appears to the right of the cursor so just moving it a
couple of pixels left is enough to get round not being able to click through tips.

However, I'm still seeing the same problem in comment 117 though. I've
identified the cause as the scrollbar. In bookmarks the scrollbar covers the
Name column and this is not being taken into account. Looking at the code I
can't see how to identify if the scrollbar is over the column we are creating
the tip for. In bookmarks we only need to know if the scrollbar is displayed
because there is only one column, but in History there can be more than one.

This is a bit pedantic, but it is possible to have a column width (without
scrollbar) such that the last 3 letters are replaced with '...' but no tip
appears. In this case there is a 30 twips difference between currentSize and
desiredSize in IsCellCropped(), which just happens to be the margin of the
image. Does the text itself have a margin that we should add to desiredSize?

parish: Did you build in the themes directories? The treetip should show up
below the mousepointer, much like a tooltip would for buttons etc.

And I couldn't reproduce your problem in the bookmarks window, but I understand
now that you're talking about the sidebar panel, and I do see the problem there.
You seem to be right about the scrollbar causing this. I think we can fix that,
but I'd rather not hold this patch up for that.

Jan, any idea how we would incorporate the scrollbar width measurement into
IsCellCropped? I mean, it must somehow know, since the text itself is properly
Mea culpa. I was using the Skypilot theme. Swtiching to Modern shows them as

Re. the scrollbar problem. AFAICT in all windows, and the History sidebar panel,
the scrollbar appears under the column select button, which is always present so
the scrollbar never obscures the columns. The Bookmarks sidebar is the only
place that doesn't have this (as there is only one column). If there is no easy
way to get the scrollbar width and, more importantly, to determine if it is
obscuring the column we are looking at then how about adding a dummy button
(no-op on click) to the Bookmarks sidebar to act as a placeholder for the scrollbar?
jag, this seems like a good way to go (at least until we figure out all the
issues with titletips)

it looks like you are enabling joe's code, but avoiding the "mousedown/click
won't go through the titletip" problem by not putting the "treetip" under the
mouse, and making it vanish on mouse move (like a tooltip)

some questions:

1)  can you comment the .css files, to explain why you (temporarily?) commented
out the margins?
2)  do we need a spin off bug about uncommenting the css, once we address the warts?
3)  forgive my ignorance, but does the css change affect any thing else?
We want this in alpha but it's not a blocker.
Flags: blocking1.4a? → blocking1.4a-
jag, re comment 115:
> That is, if I can figure out why that
> mousedown handler currently isn't called at all.

Maybe I'm way off the mark here, but could it be Windows is "stealing" the
mousedown event? Tooltips in Moz work even when the window doesn't have focus
(unlike Explorer for instance). Try this:

Reduce your Sidebar width so that Bookmarks or History will generate titletips.
Give another window (either Moz or another app) focus but still be able to see
your side bar.
Move the mouse over the sidebar until a titletip appears.
Click *on* the titletip.

The window the sidebar is in gets focus and comes to the front. That is Windows
handling the click and, it would appear, not forwarding it on.

If you repeat the above but with the sidebar window having focus then the window
frame flashes which doesn't happen with Explorer for instance.

As I said, I'm probably way off the mark, but I noticed this "non-standard"
behaviour of Moz tool/titletips.

Attachment #117994 - Flags: superreview+
Comment on attachment 117994 [details] [diff] [review]
treetips, now with longer tips, and for less than 10% crop!

Attachment #117994 - Flags: review+
Comment on attachment 117994 [details] [diff] [review]
treetips, now with longer tips, and for less than 10% crop!

*frowns* you shouldn't be able to click the tooltip... Odd, I can reproduce it
for these treetips, but not for regular tooltips.

So, yeah... For a click on a tooltip we get a WM_MOUSEACTIVATE (with as detail
WM_LBUTTONDOWN) and a WM_LBUTTONUP from Windows. I guess something similar
happens on the Mac. We must be able to deal with this though, since (at least on
Windows) you can click a link on a site, even if the browser window isn't active.

Seth: I'll add comments (I was thinking the bonsai log would be enough). I don't
think we need a spin-off bug, I'll make the comment point to this bug. The CSS
changes shouldn't affect anything else, these rules were put in for the original
titletips (which were then turned off).
Comment on attachment 118090 [details] [diff] [review]
Add comments, make treetips go bye bye when you move your mouse into another app.

copying over r= and sr=.
Attachment #118090 - Flags: superreview+
Attachment #118090 - Flags: review+
> The CSS changes shouldn't affect anything else, these rules were put in for
> the original titletips (which were then turned off).

Now that the patch has resolved the hiccups that these CSS rules attempted to
work around, it seems to me it would be simpler/clearer just to remove the
outdated rules altogether, since they have no other purpose, and there is no
intention to resurrect them later.
rbs: actually, the css wasn't working around anything. For true titletips (the
ones that are directly over the cell such that their text matches up with the
cell text, you need these margins to deal with the titletip borders etc. For
now, since I'm doing treetips, I won't need those adjustments, but for future
reference (i.e. when we switch over to true titletips) I'd like to keep them
around as comments.
| Name	       |
|cropped i...|^|
|cropped i...| |

So here's our sidebar bookmarks panel with a scrollbar. In GetCellWidth we get
the width for the column cell. It is assumed that the cell's width is the same
as the column's width, which is true for everything but the last column, since
that column may have to share space with a scrollbar, in which case the cell's
width is less than the column's width. That's what the overflow calculation
deals with, by adjusting the cell width (as copied from the column width) to be
whatever space is actually available.
Attachment #118090 - Attachment is obsolete: true
Comment on attachment 118113 [details] [diff] [review]
This one deals with the scrollbar (the overflow check)

Attachment #118113 - Flags: review+
Comment on attachment 118113 [details] [diff] [review]
This one deals with the scrollbar (the overflow check)


to be clear, we don't have title tips yet, we have jag's new "treetips". 
should we spin up a new bug about "titletips", or leave this bug open after you
check in?
Attachment #118113 - Flags: superreview+
Seth: Leave this bug open - see votes, CCs, dependecies...
Keywords: mozilla1.3
Leaving this bug open, clearing target milestone and nsbeta1+.
Keywords: nsbeta1+
Target Milestone: mozilla1.4alpha → ---
*** Bug 200900 has been marked as a duplicate of this bug. ***
It looks to be fixed in 1.4b, isn't it ?
And then is fixed also
> It looks to be fixed in 1.4b, isn't it ?

No, tooltips are still cropped.
karl: Tooltips being cropped is bug 45375, not this one. This bug is about
displaying tooltips in place of text that is cropped when the mouse hovers over
said text. (Example: message subject in the Mail's three-pane view.)

This bug is nearly fixed. In particular, the title tip is displayed, so the main
purpose is fulfilled, but it isn't displayed in the right place (it should
replace the cropped text exactly in its place, as I understand it).
No. They appear and disappear so fast that you can't read them. 2003050908 trunk
RE comment #141: vdvo, you have the meanings of Tooltips and Titletips reversed.
Tooltips are below the curser (current partial fix). Titletips are inline (this
as yet unfixed bug).
*** Bug 172281 has been marked as a duplicate of this bug. ***
This file shows that the tool tip displays correctly for the newsgroup server
name. It doesn't truncate it. Howeverö for a server topic the tooltip truncates
The title tip shows the cropped text for newsgroup server topics.
Cag Onganer, you are in the wrong bug.  This bug is about using a tip to expand 
cropped text (such as seen in your first screenshot), except to do that as a 
"title tip" rather than a "tool tip".  

Un-abbreviating newsgroup names in the tip is bug 174234.
tooltips work for me on winxp 1.7b 2004031508

not sure however of wheither this bug is about titletips (inline?) or tooltips
(below cursor) ?!
This bug (In reply to comment #148)
> not sure however of wheither this bug is about titletips (inline?) or ...

This bug is about *Titel Tips* (inline!). The reference to "(tooltips)" in the
summary is merely to avoid duplicates. (also see comment 143)

Bug 258728 just implemented a "creative" solution (really a workaround) for
Sunbird until "true" title tips are created (any volunteer CREATORS here?).
No longer blocks: majorbugs
Attachment #136542 - Attachment mime type: text/plain → image/gif
Assignee: jag → nobody
Moving to p3 because no activity for at least 1 year(s).
See for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.