Filing bug 587908 comment 73 - bug 587908 comment 75 as a new bug. With the current truncation system, there is no way to view the full destination URL. There's less space up in the address bar area for this then there was in the status bar. Previously, the destination URL shown in the status bar could use up to the full width of the window. Now it's only the right portion of just the address bar. It's around a 60% reduction in space and even moderately long URLs can get truncated. This reduces the user's ability to know where what they click takes them. Copied from bug 587908: (In reply to Frank Yan [:fryn] in bug 587908 comment #71) > Any suggestions on how it should truncate? bug 587908 comment 39 -> drop the scheme, domain, and port if they are identical to the origin's bug 587908 comment 36 -> consider sometimes doing a marquee instead of just truncating Possible route for long destination URLs: 1) drop domain if it's duplicate info: http://example.com/here > .../there 2) if the destination URL still doesn't fit, then truncate at the end: http://example.com/here > .../there/at/some/long/path/that/doesnotfit... 3) after a second or two of hovering, marquee the full destination URL. The shown part goes to the left revealing the end part that was truncated, cycling around to show the beginning and repeat. This would truncate smartly but still allow for the ability to see everything if needed. Oh, and to state what should be obvious, I am *not* suggesting the use of the actual <marquee> tag, just a marquee effect. :) or 2b) smart truncate out the middle, then revert to end truncation when the marquee starts. (just brainstorming here) Thus we start as: http://example.com/here > .../there/at/some/long/.../reallylong/page.html then after 1 or 2 seconds the destination URL changes to the following, which doesn't fit anymore: http://example.com/here > .../there/at/some/long/path/that/doesnotfit/because/the/path/is/reallylong/page.html but is truncated to fit (without the "..."): http://example.com/here > .../there/at/some/long/path/that/doesnotfit/beca which then slides to the left to show more of the right portion and cycles around to the beginning and repeats. Eventually we get this: http://example.com/here > doesnotfit/because/the/path/is/reallylong/page.h then: http://example.com/here > path/is/reallylong/page.html .../there/at/some/ then continued cycling at least once more so the user can see the full URL again (I hope that was somewhat clear) The later part not fitting would marquee around showing less on the left and more on the right, continually cycling until the full destination URL is shown at least twice, then eventually reverting to normal origin only state after 5-10 seconds as proposed above. Bit complex, but it shows some minimal info simply but also gives a route to show it all.
Will this rely on the CSS Marquee Module Level 3? http://www.w3.org/TR/css3-marquee/ It makes sense to use that for this (but since no one is working on implementing it, we might need to use a temporary ECMAScript solution until then).
Josh, this bug is still in the initial idea stage. Thanks for the implementation notes, but we're not there yet. ;)
How about recovering the characters stricken in red for starters? Just hover on the link in "Show dependency tree" above and you'd see my point.
I have another suggestion. Since the status bar is "going to be removed", replace is with a completely new "URL bar". The URL bar's sole purpose is to display the full URL of the link when hovering that link. Also this new URL bar can be used to display add-ons that are not yet compatible with the add-on bar. Also URL bar can be used to display the status of loading the page. Not displaying the URL in full is a major security issue. This must definitely be sorted out by any means necessary.
Now that bug 541656 has landed and the destination URL no longer uses the address bar, truncation is less important than it was before and removing it is easier.
Yeah, this but is no longer applicable as filed. In lieu of an N/A status, marking INVALID. I've filed bug 632634 to address this with the new system.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.