Closed Bug 154772 Opened 22 years ago Closed 10 years ago

Tooltip for address bar should show complete current URL

Categories

(SeaMonkey :: Location Bar, enhancement)

enhancement
Not set
normal

Tracking

(seamonkey2.26 fixed, seamonkey2.27 fixed)

RESOLVED FIXED
seamonkey2.27
Tracking Status
seamonkey2.26 --- fixed
seamonkey2.27 --- fixed

People

(Reporter: mrmazda, Assigned: philip.chee)

References

Details

Attachments

(2 files, 2 obsolete files)

Currently, when you mouseover the URL bar, a tooltip is displayed: "Enter search
term, keyword, or web address". It is probably more common than not with the
various tool icons sharing the horizontal space with the URL bar that the
current URL is not fully displayed. Often times one wants or needs to see a
larger portion of the current URL, as much as all of it at once. Currently there
is no way to do this short of copying it somewhere else where it is possible. It
would thus be good to change the tooltip to display the complete current URL if
a page is loaded, and only display the currently used tooltip if there is no
page displayed, or if the current URL is fully displayed, or maybe also if the
current URL has been selected.
I disagree. If anywhere, the URl should be shown in status bar.
Long URL's don't fit in either the status bar or the URL window. That's the
reason for the RFE. AFAIC, the tooltip could pop up anywhere, including over the
status bar, but that could be disconcerting or overlooked by the average user.
Tooltips are supposed to be short (!) descriptions of an UI item.
Tooltips are also descriptions of web page images. They can describe whatever
the Mozilla developers choose for them to describe.

Can you offer a better suggestion for providing access to an incompletely
visible URL?
> ------- Additional Comment #4 From mrmazda@atlantic.net  2002-06-28 15:09 -------
> 
> Tooltips are also descriptions of web page images.

...or any other html element

> They can describe whatever the Mozilla developers choose for them to describe.

Mozilla, iirc, has a limit of 100 characters for their descriptions (in the
title attribute) though. So once again, they're supposed to be *short*.

> Can you offer a better suggestion for providing access to an incompletely
> visible URL?

The status bar is where the user most expects it. The tooltip can receive a
shortened version of it (see the personal toolbar for an example where that is
currently being done), but in this case, that is pointless since the urlbar
already *has* that shortened version.

Can you point me to a browser that *does* show the whole URL in the tooltip? IE
doesn't... I haven't checked Opera and others yet.
Again you are entirely missing the point. What any other browser does is totally
irrelevant. The tooltip was just an idea to provide easy means to:

         >>> see a complete URL all at once. <<<

I really don't care how it is done, only that it is done. A tooltip would seem
to be a simple way, and that's why the summary was written as it was.

It could alternatively be done the way 1-2-3 does when editing a cell, spilling
the edit field (here, the URL bar when focused and containing a URL longer than
the display field) down as far as required into space normally used for toolbars
or tabs or main view window or whatever it takes to make the whole field display
the entire URL (which AFAIK doesn't have a cognitively usable length limit).
Such a space preemption is something the typed URL dropdown history already does.
> ------- Additional Comment #6 From mrmazda@atlantic.net  2002-06-28 16:51
> 
> Again you are entirely missing the point.

No I'm not, I do understand the point.

> What any other browser does is totally irrelevant.

No it isn't. Other browser have market share, and other browsers' developers
have possibly *thought* of how to solve this problem before. So looking at other
browsers' solutions doesn't do any harm.

> The tooltip was just an idea to provide easy means to:
>         >>> see a complete URL all at once. <<<

I figured that.

> I really don't care how it is done, only that it is done.

I would like to have it done too.

> A tooltip would seem
> to be a simple way, and that's why the summary was written as it was.

I've told you why a tooltip is a suboptimal solution.

> It could alternatively be done the way 1-2-3 does when editing a cell, spilling
> the edit field (here, the URL bar when focused and containing a URL longer than
> the display field) down as far as required into space normally used for
> toolbars or tabs or main view window or whatever it takes to make the whole
> field display the entire URL (which AFAIK doesn't have a cognitively usable
> length limit).

That's a nice idea...

> Such a space preemption is something the typed URL dropdown history already
> does.

...but this shows why it isn't that good. A vertically stretched (while hovering
/ focusing) URLbar is confusing because urlbar autocomplete *also* does this.
"...but this shows why it isn't that good. A vertically stretched (while hovering
/ focusing) URLbar is confusing because urlbar autocomplete *also* does this."

Odds are high that if the URL is longer than the standard URL window that
autocomplete won't be active. If it is, a bold border could divide the extended
URL bar window from the autocomplete window, which would be displaced further
down as required by the length of the extended URL window.
What I described in comment 6 appears to be asked for in bug 115118. The need
for the tooltip probably depends on the implementation of bug 49543. Marking dep.
Depends on: 49543
fixing summary misspell  s/should should/should show/
Summary: [RFE] Tooltip for address bar should should complete current URL → [RFE] Tooltip for address bar should show complete current URL
Blocks: 157199
No longer blocks: 157199
> Other browser have market share, and other browsers' developers
> have possibly *thought* of how to solve this problem before. So looking at other
> browsers' solutions doesn't do any harm.

No it doesn't, but limiting options to what other browsers do *is* harmful.
After all, why be standards compliant when no other browsers are?
Summary: [RFE] Tooltip for address bar should show complete current URL → Tooltip for address bar should show complete current URL
It would be nice if a tooltip could also show the complete URL and/or description for items in the dropdown history, as with several similar long URLs it is often impossible to tell which one wanted.
I've just realised it actually already attempts to do this, it just doesn't work properly (in Seamonkey 1.0 with WinXP). When the tooltip appears under the mouse pointer the dropdown menu item is deselected so the tooltip disapears, but I assume there's a separate bug for that somewhere.

Sorry for the noise.
Now that bug 366797 is fixed, when the Firefox has to cut off the URL in the address bar, the tooltip does show more of the URL.  But it only shows the last part of the URL (cut off at the beginning with ellipses).  I think it would be more useful if it tried harder to show the entire URL (hard-wrapped) in the tooltip.
Attached image screenshot
I can see the beginning of the URL in the address bar, and I can see the end of the URL in the tooltip, but I can't see the middle of the URL.  (Conversely, for URLs that only barely fail to fit in the address bar, there's confusing overlap between what's shown in the address bar and what's shown in the tooltip.)
Blocks: 366797
Assignee: hewitt → nobody
Keywords: uiwanted
QA Contact: claudius → location-bar
Depends on: 389708
Product: Core → SeaMonkey
This patch does the following:
1. Moves the current static text for the input tooltiptext to the textbox placeholder.
2. Dynamically updates the urlbar tooltip with the complete url when it overflows the urlbar and removes the tooltip when the urlbar underflows.
3. If the urlbar is not empty use the placeholder text as the tooltiptext. Otherwise remove the tooltip completely.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Attachment #805367 - Flags: review?(neil)
No longer blocks: 366797
No longer depends on: 389708
Keywords: uiwanted
Comment on attachment 805367 [details] [diff] [review]
Patch v1.0 dynamically update the urlbar tooltip.

>-          <xul:hbox class="textbox-input-box paste-and-go" flex="1" xbl:inherits="context,tooltiptext=inputtooltiptext">
...
>+          <xul:hbox class="textbox-input-box paste-and-go" flex="1" xbl:inherits="context">
>-                        xbl:inherits="tooltiptext=inputtooltiptext,value,type,maxlength,disabled,size,readonly,placeholder,tabindex,accesskey,mozactionhint,userAction"/>
[Huh, I wonder why we used to inherit tooltiptext twice.]

>+        this.inputField.addEventListener("overflow", this, false);
>+        this.inputField.addEventListener("underflow", this, false);
It's easier to just add inline event handlers on the element, either using lots of .parentNode or document.getBindingParent(this) to touch the _overflow property (which you didn't add a field for) although alternatively you could simply set the property on the input field itself and retrieve it when showing the tooltip (in which case you wouldn't worry about a field).

>+      <method name="_showTooltip">
>+        <body><![CDATA[
>+          if (this._overflow)
>+            this.inputField.setAttribute("tooltiptext", this.value);
>+          else if (this.value)
>+            this.inputField.setAttribute("tooltiptext", this.getAttribute("placeholder"));
>+          else
>+            this.inputField.removeAttribute("tooltiptext");
>+        ]]></body>
>+      </method>
You should use an actual <tooltip> element and compute its label in its popupshowing event. (See tabbrowser.xml for an example).
Attachment #805367 - Flags: review?(neil) → review-
(In reply to comment #17)
> It's easier to just add inline event handlers on the element
Except when that particular event doesn't have an inline event handler. Oops.
(In reply to neil@parkwaycc.co.uk from comment #17)

> You should use an actual <tooltip> element and compute its label in its
> popupshowing event. (See tabbrowser.xml for an example).
Fixed.
Attachment #805367 - Attachment is obsolete: true
Attachment #807237 - Flags: review?(neil)
Comment on attachment 807237 [details] [diff] [review]
Patch v1.1 Use an actual tooltip element.

>         this.inputField.controllers.insertControllerAt(0, this._editItemsController);
>+        this.inputField.addEventListener("overflow", this, false);
>+        this.inputField.addEventListener("underflow", this, false);
>       ]]></constructor>
> 
>       <destructor><![CDATA[
>         this.inputField.controllers.removeController(this._editItemsController);
>+        this.inputField.removeEventListener("overflow", this, false);
>+        this.inputField.removeEventListener("underflow", this, false);
>         this.mPrefs.removeObserver("browser.urlbar", this.mPrefObserver);
Nit: style seems to be to remove stuff in reverse order.

>+      <field name="_overflow">false</field>
Nit: _overflowing would be slightly more grammatically correct.

>+      <field name="mTooltip" readonly="true">
>+        document.getAnonymousElementByAttribute(this, "anonid", "tooltip");
>+      </field>
Nit: can avoid this by passing the tooltip node explicitly or by reading it from the event.

>+          if (this._overflow)
>+            this.mTooltip.label = this.value;
>+          else if (this.value)
>+            this.mTooltip.label = this.placeholder;
>+          else
>+            aEvent.preventDefault();
(As an alternative to passing the event you can also return true or false as appropriate, but you would have to return from the attribute too and also rearrange the block to put the false return first.)
Attachment #807237 - Flags: review?(neil) → review+
> Nit: style seems to be to remove stuff in reverse order.
Fixed.

>>+      <field name="_overflow">false</field>
> Nit: _overflowing would be slightly more grammatically correct.
Fixed.

>>+      <field name="mTooltip" readonly="true">
>>+        document.getAnonymousElementByAttribute(this, "anonid", "tooltip");
>>+      </field>
> Nit: can avoid this by passing the tooltip node explicitly or by reading it from the event.
Now getting the tooltip node from event.target.

>>+          if (this._overflow)
>>+            this.mTooltip.label = this.value;
>>+          else if (this.value)
>>+            this.mTooltip.label = this.placeholder;
>>+          else
>>+            aEvent.preventDefault();
> (As an alternative to passing the event you can also return true or false as appropriate, but you would have to return from the attribute too and also rearrange the block to put the false return first.)
(Sounds too complicated) :P
Attachment #807237 - Attachment is obsolete: true
Attachment #808295 - Flags: review+
Attachment #808295 - Attachment description: Patch v1.2 nits nitted. Carrying r+ from Neil → Patch v1.2 nits nitted. Carrying forward r+ from Neil
Pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/8e9dff6fa8ce
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.27
Blocks: 1018792
landed on relbranch on comm-release for SeaMonkey 2.26.1:

changeset:   20170:b8059a5e7a4b
branch:      SEA_2_26_1_RELBRANCH
tag:         tip
user:        Philip Chee <philip.chee@gmail.com>
date:        Sun Sep 22 23:07:05 2013 +0800
summary:     Bug 154772 Tooltip for address bar should show complete current URL r=Neil
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: