32157 - (titletips) Title tips (tooltips) for cropped text

Status: NEW

(Core :: XUL, defect, P3)

Description

[Eric Vaughan]

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

Comment 1

[Eric Vaughan]

targeting

Comment 2

[Eric Vaughan]

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

Comment 3

[Eric Vaughan]

Here is a present Ben. You should be able to do this entirely with XBL!

Comment 4

[leger]

Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 6

[leger]

Putting on [nsbeta2+] radar for beta2 fix.   Always display whether cropped or 
not.

Comment 7

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 8

[Peter Trudelle]

[nsbeta2-]

Comment 9

[don]

M20

Comment 10

[verah (gone)]

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

Comment 11

[Peter 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

Comment 12

[Peter Trudelle]

this one really hurts, but we have resizable columns now, so...  ->future.

Comment 13

[Diane Sun]

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

Comment 14

[Jesse Ruderman]

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

Comment 15

[Peter Trudelle]

->ben

Comment 16

[John Morrison]

Any thoughts on doing this in the next cycle? Ben, Eric?

Comment 17

[R.K.Aa.]

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

Comment 18

[Peter Lairo]

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.

Comment 19

[Simon Lucy]

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.

Comment 20

[Peter Lairo]

... not really, since it was suggested that a "lazy mouseover" (2000-07-21
15:34) could do the trick without changes to the backend.

Comment 21

[Peter Lairo]

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.

Comment 22

[Blake Ross]

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

Comment 23

[Peter Lairo]

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?

Comment 24

[Simon Lucy]

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.

Comment 25

[Peter Lairo]

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
there?

Comment 26

[Simon Lucy]

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. 

Comment 27

[Peter Lairo]

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.

Comment 28

[Peter Lairo]

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.

Comment 29

[scottputterman]

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. 

Comment 30

[Peter Lairo]

Could you please also "simulate" it in bookmarks in the sidebar until it is
implemented?

Comment 31

[Jesse Ruderman]

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?

Comment 32

[rbs]

Updating summary to include 'tooltips' and 'cropped' --to ease the search. It
took me several jumps from other 'tooltips' bugs before reaching this one.

Comment 33

[jglick]

On a personal level, this is one that is really annoying for me not to have. I 
rely on these so much.

Comment 34

[scottputterman]

cc'ing hyatt because he's talked about the possibility of this for the outliner.

Comment 35

[David Hallowell]

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.

Comment 36

[David Hyatt]

This is no longer a ben thing.  It's now special to outliner.

Comment 37

[Peter Lairo]

great, maybe some movement at last :)

Comment 38

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 39

[Paul Chen]

nav triage team:

Marking nsbeta1+ and p4.

Comment 40

[Joseph Elwell]

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.

Comment 41

[Viswanath Ramachandran]

nav triage: this is not a Netscape beta or rtm stopper. 

Comment 42

[Alex Bishop]

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

Comment 43

[Blake Ross]

Renominating given status of the bugs this blocks.

Comment 44

[Keyser Sose]

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

Comment 45

[Peter Lairo]

I can't imagine ANY user not being annoyed by not being able to see cropped
texts. Please reconsider making this *nsCatFood+*

Comment 46

[Blake Ross]

Renominating for catfood per plairo, cc'ing selmer.  A bunch of 6.0 reviews 
noticed this missing feature.

Comment 47

[jglick]

In Mail, this is a big usability issue. This is one of the main features that 
keeps me from using mozilla fulltime.

Comment 48

[Jesse Ruderman]

This is mostfreq if dependencies are counted.

Comment 49

[Paul Chen]

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+

Comment 50

[Alex Bishop]

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

Comment 51

[Ben Goodger (use ben at mozilla dot org for email)]

outliner work by people in the nav group has been deprioritized. .9.3

Comment 52

[Peter Lairo]

Could the summary *brackets* () please be fixed. This bug might as well "look"
purdy while it's being moved back, and back, and back :(

Change:
[feature] title tips (tooltips for cropped texts)

To:
[feature] title tips (tooltips) for cropped texts

There must be some serious other problems to justify moving this back again
(#$%§$%).

Comment 53

[Ben Goodger (use ben at mozilla dot org for email)]

Depends on ability to reliably locate cropped text portion of outliner row.

Comment 54

[Peter Lairo]

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?

Comment 55

[Alex Bishop]

Correcting summary to keep Peter happy :-)

Comment 56

[Alfonso Martinez]

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

Comment 57

[Joe Hewitt (gone)]

Attachment: patch

Comment 58

[Joe Hewitt (gone)]

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!

Comment 59

[Jan Varga [:janv]]

I must say this is absolutely cool !
Only one nit, you don't need own getOutlinerBody() method. There is
nsIOutlinerBoxObject.outlinerBody.

Comment 60

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 61

[Joe Hewitt (gone)]

taking from his Goodgerness.

Comment 62

[jag (Peter Annema)]

Would you mind changing this:

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


to:

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

And then changing your cpp implementations to:

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

+NS_IMETHODIMP
+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 :-)

Comment 63

[rbs]

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

Comment 64

[Joe Hewitt (gone)]

Attachment: revised patch, post reviews

Comment 65

[rbs]

Nominating for m0.9.4 since the long-awaited patch is finally there there...

Comment 66

[Brian Ryner (not reading)]

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

Comment 67

[Ben Goodger (use ben at mozilla dot org for email)]

So, what sections of code have changed? (To prevent me from having to re-read
the whole thing) ;) 

Comment 68

[Blake Ross]

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

Comment 69

[Blake Ross]

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

Comment 70

[Joe Hewitt (gone)]

Attachment: new patch

Comment 71

[Johnny Stenback (:jst)]

As for the changes to nsEventStateManager.cpp and nsDOMEvent.cpp, here's some
comments:

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

[(not reading, please use [e-mail] instead)]

Comment on attachment 55154 [details] [diff] [review]
new patch

r=sspitzer (on the mailnews changes).

Comment 73

[Brian Ryner (not reading)]

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.

Comment 74

[Joe Hewitt (gone)]

fixed

Comment 75

[:deanis74]

Really cool.  Is there another bug somewhere for the click not passing through
to what's underneath, though?  This really hinders their usability.

Comment 76

[[e-mail] (gone - use [e-mail] instead)]

Bug 113621.

Comment 77

[:deanis74]

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.

Comment 78

[Joe Hewitt (gone)]

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.

Comment 79

[Joe Hewitt (gone)]

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.

Comment 80

[Blake Ross]

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

Comment 81

[Peter Trudelle]

nsbeta1+ per Nav triage team

Comment 82

[Blake Ross]

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

Comment 83

[Peter Lairo]

Summary: RFE <> Severity: normal?
This seems an important bug fo usability. Suggest to remove "RFE" from summary.

Comment 84

[[e-mail] (gone - use [e-mail] instead)]

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

Comment 85

[Peter Lairo]

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.

Comment 86

[:deanis74]

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.

Comment 87

[Peter Trudelle]

nsbeta1- per Nav triage team

Comment 88

[jglick]

13 dups (with some containing their own dups). 
I really think this needs to be fixed.

Comment 89

[Andy Edmonds]

FWIW, It is also a feature that Vivendi Universal is tracking and critical to 
the usability of our application.  

Comment 90

[Peter Trudelle]

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.

Comment 91

[Bamm Gabriana]

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.

Comment 92

[Blake Ross]

Nominating for buffy.

Comment 93

[:deanis74]

Again, I would gladly take a look at this if I could look at the existing code
that was backed out.

Comment 94

[John Morrison]

hewitt would, of course, have a more complete answer, but Dean, have a look
at http://bugzilla.mozilla.org/attachment.cgi?id=60746&action=view from
http://bugzilla.mozilla.org/show_bug.cgi?id=113639 and possibly also
http://bugzilla.mozilla.org/attachment.cgi?id=60880&action=view from 
http://bugzilla.mozilla.org/show_bug.cgi?id=114043 (which are rev 1.2 and
rev 1.3 of layout/xul/base/src/nsXULTooltipListener.cpp

Comment 95

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 96

[:deanis74]

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

http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsXULTooltipListener.cpp#323


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.

Comment 97

[:deanis74]

I of course meant thanks John, not Joe.  Sorry for the spam.

Comment 98

[:deanis74]

random notes:

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

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

2. Message sequence when clicking on a tooltip, regardless of the button:
  NS_PLUGIN_ACTIVATE
  NS_GOTFOCUS
  NS_DEACTIVATE
  NS_LOSTFOCUS
  NS_ACTIVATE

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 
titletips?

Comment 99

[Brian Ryner (not reading)]

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.

Comment 100

[av (gone)]

NS_PLUGIN_ACTIVATE is what WM_LBUTTONDOWN is mapped to on Windows.

Comment 101

[:deanis74]

The NS_PLUGIN_ACTIVATE issue is bug 113536.

Comment 102

[:deanis74]

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

Comment 103

[Peter Lairo]

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

Comment 104

[Brian 'netdragon' Bober]

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

Comment 105

[:deanis74]

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.

Comment 106

[Samir Gehani]

Over to jag.

Comment 107

[Peter Lairo]

"Mozilla1.3alpha" is long gone. Please update the Target Milestone to
Mozilla1.3beta.

Comment 108

[jag (Peter Annema)]

Clearing milestone for now, I doubt it's going to make 1.3b or 1.3 final.

Comment 109

[R.K.Aa.]

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

Comment 110

[cmorley]

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

Please, stop adding new features and fix the basics!

Comment 111

[Alex Bishop]

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

Comment 112

[Andrew Hagen]

Cut the spam, please.

Comment 113

[Brian 'netdragon' Bober]

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.

Comment 114

[jag (Peter Annema)]

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

Comment 115

[jag (Peter Annema)]

Attachment: This re-enables titletips, warts and all

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

Comment 116

[Vaclav Dvorak]

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.

Comment 117

[parish]

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'?

Comment 118

[jag (Peter Annema)]

Attachment: Okay, how about treetips instead?

click-through is hard to fix, but here's the next best thing: tooltips for free
on trees!

Comment 119

[jag (Peter Annema)]

Attachment: treetips, now with longer tips, and for less than 10% crop!

So in nsTreeBodyFrame::GetCellWidth we forgot to add the cell image margin,
which caused us to not always correctly detect "IsCellCropped".

Comment 120

[parish]

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?

Comment 121

[jag (Peter Annema)]

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

Comment 122

[parish]

Mea culpa. I was using the Skypilot theme. Swtiching to Modern shows them as
described.

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?

Comment 123

[(not reading, please use [e-mail] instead)]

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?

Comment 124

[Asa Dotzler [:asa]]

We want this in alpha but it's not a blocker.

Comment 125

[parish]

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.

Comment 126

[Joe Hewitt (gone)]

Comment on attachment 117994 [details] [diff] [review]
treetips, now with longer tips, and for less than 10% crop!

r=me

Comment 127

[Joe Hewitt (gone)]

Comment on attachment 117994 [details] [diff] [review]
treetips, now with longer tips, and for less than 10% crop!

r=me

Comment 128

[jag (Peter Annema)]

*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 129

[jag (Peter Annema)]

Attachment: Add comments, make treetips go bye bye when you move your mouse into another app.

Comment 130

[jag (Peter Annema)]

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

Comment 131

[rbs]

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

Comment 132

[jag (Peter Annema)]

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.

Comment 133

[jag (Peter Annema)]

Attachment: This one deals with the scrollbar (the overflow check)

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

Comment 134

[Jan Varga [:janv]]

Comment on attachment 118113 [details] [diff] [review]
This one deals with the scrollbar (the overflow check)

r=varga

Comment 135

[(not reading, please use [e-mail] instead)]

Comment on attachment 118113 [details] [diff] [review]
This one deals with the scrollbar (the overflow check)

sr=sspitzer

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?

Comment 136

[Adam Hauner]

Seth: Leave this bug open - see votes, CCs, dependecies...

Comment 137

[jag (Peter Annema)]

Leaving this bug open, clearing target milestone and nsbeta1+.

Comment 138

[Stefan Borggraefe]

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

Comment 139

[Olivier Vit (just a reporter)]

Hey
It looks to be fixed in 1.4b, isn't it ?
And then http://bugzilla.mozilla.org/show_bug.cgi?id=200900 is fixed also

Comment 140

[Karl Ove Hufthammer]

> It looks to be fixed in 1.4b, isn't it ?

No, tooltips are still cropped.

Comment 141

[Vaclav Dvorak]

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

Comment 142

[Jerry Baker]

No. They appear and disappear so fast that you can't read them. 2003050908 trunk

Comment 143

[Peter Lairo]

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

Comment 144

[noririty]

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

Comment 145

[Cag Onganer]

Attachment: Tool Tip Newsgroup Server Name OK

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

Comment 146

[Cag Onganer]

Attachment: Newsgroup Server Topic Truncated on Tool Tip

The title tip shows the cropped text for newsgroup server topics.

Comment 147

[Mike Cowperthwaite]

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.

Comment 148

[Olivier Vit (just a reporter)]

tooltips work for me on winxp 1.7b 2004031508

not sure however of wheither this bug is about titletips (inline?) or tooltips
(below cursor) ?!

Comment 149

[Peter Lairo]

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)

Comment 150

[Peter Lairo]

Bug 258728 just implemented a "creative" solution (really a workaround) for
Sunbird until "true" title tips are created (any volunteer CREATORS here?).

Comment 151

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 152

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

The severity field for this bug is relatively low, S3. However, the bug has 17 duplicates, 49 votes and 79 CCs.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 153

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