We need tooltips when the URL in the search/wr tab is long enough to be clipped. This will improve its usability.

its more important to have Search than What's Related. marking nsbeta1+, P1

See bug 60245.

First glance:Added tooltips to the tree. This should be fixed by a tree widget and outliner tooltip being built into the widgets themselves but that is not going to happen. Risk:not much length:3 days reason:People like tooltips? I think the PM's should write completing reasons why we should do this. Search i understand but we still don't know how many people actually use the sidebar search. From stats i think it was very few. Are we really playing into the 80/20 rule here. I've gotten more duped bugs on fixing other search bugs that got lattered to mozilla 1.0 then requesting tooltips for search. As for What's related I don't understand why the PM's want us to spend cycles they have given little attention to. We have reverted back to the old 6.0 related tab. The what's related tab is supposed to be not in the flyout or in the sidebar by default. I'd be happy to do it but like comments why we would bury this tab but continue to invest engineering time into it.

The search sidebar tab is useful in a couple ways: 1) It is another entry point for searching the web, possibly more discoverable than the URL bar for some users. 2) Search results displayed in the sidebar tab allow users to navigate their results without moving back and forth within those results in the main browser window. While we have data that suggests that not many users are taking advantage of 1) above, we do not have data that says anything about whether or not people are taking advantage of 2). Tooltips in the search sidebar tab speak to the second of these two items. Currently the sidebar search results are not as useful as they could be for two reasons: 1) They don't display quickly enough (i.e. users can begin navigating the main browser window results before sidebar search tab populates). This is covered in a separate bug. 2) Users can't distinguish easily between sidebar search results or tell what each result is because sidebar real estate is too skinny. Try any search and look at the results in the sidebar to see this problem. Tooltips will solve this second problem - give users a full URL and site description (as we now do in the autocomplete field) so that they can actually use the sidebar as intended - as a way to easily navigate search results. Doing this, I believe, will increase search sidebar tab usefulness and usage significantly. As Vishy said, What's Related is of a lower priority at this point. However, I believe the same problem exists in that tab as well and could be solved similarly.

If any engineer is going to spend time on coming up with solutions for cropped items, it should be Ben, to fix bug 32157. It would take Matt just as long to fix this bug, the difference being that this fix would be a terrible hack that only the Search panel could take advantage of. Mail tried something like this before and it failed; tooltips too often came up at the wrong time, and in the wrong places, and it ended up causing more usability problems than the one it was trying to fix. I say we bite the bullet and fix that bug already. The whole product would benefit from it.

Just to clarify, we're asking for "Titletips" not tooltips. However, if the two terms are interchangeable to you, then no worries. With respect to "why we should do this" - I second tpringle's point about making Search easier to use by adding Titletips. WRT What's Related, yes, that falls a distant second behind doing this for Search.

Titletips are tooltips, they just have specialized behavior (only appear at certain times, in different positions). I'm not asking why we should do this at all, but why we have three or four different bugs on implementing this individually for certain panels (an approach that practically ensures inconsistent implementation and behavior), instead of just implementing the generic functionality so that everyone would benefit.

and the Sun is a Star, it just has specialized behavior (4.5 billion years old, 93 million miles away) :-) that was the point blake, we know they're different AND they're a subset. Anyway, i digress. Blake is right, it would be a horrible waste to implement this case by case, it will be frought with bugs (no knock on Matt) beause it's bad design to try it this way, and it'll end up being throw away code. I can't imagine we as a group have time to write throwaway code. let's just mark this bug as depending on that bug and go push there. maybe the nsbeta1+ 0.9.2 should be reconsidered here? (likewise maybe squeeze the other into 0.9.2)

My point is that unless you fix 32157, they are not going to be titletips, they are going to be *tooltips* that someone has hackishly programmed to get them to show up in a certain spot. That's why I said tooltips, not titletips, for mailnews. The way to get true titletips is to fix 32157.

I completely agree about consistent implementation, and as such I think Vishy (what up Vishy?) should try to get the same person to implement for history, bookmarks, search and if there's time, What's Related. Tooltips, while probably not as good as titletips, are a huge step forward for end users. Correct me if I'm wrong, but tooltips are what we currently have in the buddy list tab. A similar implementation for these tabs with full URL and description would be great. IE, incidentally, uses tooltips in these areas effectively, not titletips.

I understand that titletips are better than tooltips for these panels, however I would be willing to start with tooltips, given the short m0.9.2 cycle. Also yes, it is better to have one person fix all the panels, I'll see if I can move the bugs aroung. However - we shd have separate bugs for each panel to track it better. On 32157 - how much time will it take to be fixed?

nav triage: not an rtm stopper anymore, moving to nice-to-have list on m0.9.3.

nav triage team: Clearing status whiteboard, targetting mozilla1.0

Talked with German: This is what is impletemented What is required is the Name, the url, and the description in the popup. Thus we have to use a tooltip. Added customize tooltip with box and 3 text node. Title on results treeitem, URL of treeitem when clicked, and the description from the search site. Cleaned up the description a bit. Still needs more clean up depeneding on search engines. Cleaned up &nbsp %quot and took the name out if the name was in the Description so that the information is not repeated.

Need r and rs note: took off what's related from this since in mozilla alexa uses and html page in an iframe. It is completely dependent on the server. filed new bug for the netscape what's related.

Cool. Matt was working on this. Thanks for the patch Doug! You want to take this bug?

Errr, cc'ing Doug so he can see last comments.

OK, that was Matt pretending to be Doug. Never mind. Removing dougt from cc list. Sorry for the spam. :o)

Comment on attachment 52827 [details] [diff] [review] new patch creating tooltips dynamically. Looks good. With fixes for the few minor nits I cite below r=sgehani. >Index: search-panel.js >=================================================================== >RCS file: /cvsroot/mozilla/xpfe/components/search/resources/search-panel.js,v [snip] >+//Step up the dom until getting the desired node. >+function getItemNode(aNode,nodeName) >+ { >+ var node = aNode; >+ while (node.localName != nodeName) { >+ node = node.parentNode; >+ } >+ return node ? node : null; >+ } Cleanup extra whitespace before function start/end braces. [snip] >+//Fill in tooltip in teh search results panel >+function FillInDescTooltip(tipElement) >+{ >+ var retValue = false; >+ >+ //Get the cell node and the tree item node of >+ //moused over sherlock result >+ var nodeTreeCell = getItemNode(tipElement, "treecell"); >+ var nodeTreeitem = getItemNode(tipElement, "treeitem"); >+ >+ //Get the Name of the tree cell for first item in the tooltip >+ var nodeLabel = nodeTreeCell.getAttribute("label"); >+ var id = nodeTreeitem.id; Name change: id -> nodeID for consistency with nodeLabel. >+ >+ //Query RDF to get URL of tree item >+ if (!id) >+ return; >+ >+ try { >+ var ds = document.getElementById("Tree").database; >+ if (ds) { >+ var rdf = Components.classes[RDFSERVICE_CONTRACTID].getService(nsIRDFService); >+ var src = rdf.GetResource(id, true); >+ var prop = rdf.GetResource("http://home.netscape.com/NC-rdf#URL", true); >+ var url = ds.GetTarget(src, prop, true); >+ >+ if (url) { >+ url = url.QueryInterface(nsIRDFLiteral).Value; >+ } >+ } >+ } catch (ex) { >+ } Cleanup whitespace and alignment issues with curly braces for try...catch block and if blocks. >+ >+ //Fill in the the text nodes >+ //Create these dynamically and append them. >+ //textElem is the text node for Name Name change: textElem -> textElemName for consistency with textElemUrl. >+ //textElemUrl is the text node for URL >+ if (nodeLabel || url) { Remove "|| url" condition since the check is done in the next if block. >+ var tooltipNode = document.getElementById("descTooltip"); >+ var boxText = document.getElementById("tipTextBox") >+ if (nodeTreeCell) { >+ var textElem = document.createElementNS("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul","text"); >+ textElem.setAttribute("value",nodeLabel); >+ boxText.appendChild(textElem); >+ } >+ if (url) { >+ var textElemUrl = document.createElementNS("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul","text"); >+ textElemUrl.setAttribute("value",url); >+ boxText.appendChild(textElemUrl); >+ } >+ retValue = true; >+ } >+ return retValue; More whitespace cleanup and alignment above. > } >Index: search-panel.xul >=================================================================== >RCS file: /cvsroot/mozilla/xpfe/components/search/resources/search-panel.xul,v >retrieving revision 1.64 >diff -u -r1.64 search-panel.xul >--- search-panel.xul 2001/09/18 21:47:15 1.64 >+++ search-panel.xul 2001/10/10 00:17:22 >@@ -47,6 +47,13 @@ > <menu /> > </popup> > </popupset> >+ >+ <popupset id="descTooltipSet"> >+ <tooltip id="descTooltip" class="tooltip" noautohide="true" onpopupshowing="return FillInDescTooltip(document.tooltipNode)" onpopuphiding="CleanUpTipText(document.tooltipNode);"> >+ <vbox id="tipTextBox" flex="1"> >+ </vbox> Alignment cleanup of vbox close tag. [snip]

Updated patch. I turned tabbing off in my editor so I have no excuse for that ugliness anymore. 1. Also addressed urls that are to long. Cut off is 100 chars otherwise take the substr and add "..." 2.Took out return before reading rdf data. We can still add the name. 3. Need the (nodeLabel || url) to know if we should build up the tooltip. If not we return false. I can take that if statement and just added retvalue = true in each of the if statements.

A few comments on the patch: * This variable assignment is never used, so you can get rid of it: + var tooltipNode = document.getElementById("descTooltip"); I'm not sure I like the idea of adding and removing the text nodes to the tooltip. Why not just add two <label/> elements to the xul and set their value or collapse them if not needed?

1. Ya, I noticed that was not used and took it out but forgot to add the extra patch. In my first prototype I did something similiar to what you are saying hewitt. i can easily put that back and add the collapse and show to it. Samir?

Sure, if collapsing <label/>s is more efficient than creating <text/> nodes then we should go that way. My original concern was not with the implementation of dynamically displaying the description, URL, and resource but with the lack of any dynamism. This lead to blank lines in the tooltip as you may recall.

We can use collapse or hide to deal with the extra lines.

Was having problems with collapse so used hidden instead. Added two text elements for formatting purposes. reviews?

Comment on attachment 54832 [details] [diff] [review] attachement My only comment is that you should remove the redundant class="tooltip" from the tooltip element. Other than that, sr=hewitt

Comment on attachment 54832 [details] [diff] [review] attachement r=sgehani

fixed with class=tooltip taken out

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

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]