An example really long URL:
Hover over the above link in current Trunk and it'll truncate to fit into a popup bubble half the width of the browser in the lower left. Since we're now showing this on top of content rather than in a fixed space in the status or location bar, we've got more room to spare. We should at least show as much of it as we can so the user is more informed. There's no need to truncate it if we have the room.
Really long URLs are a known potential spoofing path, so showing as much as possible is potentially helpful in this area. (e.g. long URL with real URL it'll redirect to at the end) That being said, really long URLs that can't fit onscreen are also doable. Doing a marquee similar to what I suggested in bug 596802 might help with that, but that'd be another bug.
Using 100% of the browser width might be too much. Maybe up to 80% or so?
(In reply to comment #0)
> Using 100% of the browser width might be too much. Maybe up to 80% or so?
I'd vow for using 100% and making it the bubble multiple lines if need be.
To combat spoofing I should be as informed as I possibly can before clicking.
Can the bubble turn reddish if the destination is a known web forgery?
(In reply to comment #1)
> Can the bubble turn reddish if the destination is a known web forgery?
That's a really interesting idea, but way outside the scope of this bug.
Please file a new bug for that.
*** Bug 622374 has been marked as a duplicate of this bug. ***
The 50% max-width allows the panel to move to the other side to completely unblock content when needed.
The mirroring to unblock feature is only really needed for status update text, not link destination URLs. You can't hover the cursor over the status bubble to mirror it when it's for a link, as doing so would hover away from the link and hide it anyway. (in the keyboard only case, just tabbing away is all that would be needed to unblock content) Thus, the 50% max-width could be restricted to the status text case and a larger max-width could be used for link URLs.
No, links can be at the bottom of the content frame.
Ok, in that (literal) edge case the user still can unfocus the link to see any blocked content. The status update text, on the other hand, is not at the control of the user. In the instance of a link both being at the bottom of the screen and being particularly long, I think it's fine to trade off temporarily blocked page space to see more of the link because the user can always unfocus to get it back.
But blocking a link with the bubble will cause flickering of the bubble/link/mouse cursor. The solution would be to move the bubble more flexible (not only to the far right side but also vertically) to a position where it can not interfere with the link. Another solution would be to ignore that the link is not visible while the bubble is there but make the bubble "click/hover through" so that it does not flicker and the link can still be clicked while the bubble is shown.
(In reply to comment #4)
> The 50% max-width allows the panel to move to the other side to completely
> unblock content when needed.
why not use 100% of the width and move to the top edge of content video when needed?
*** Bug 647457 has been marked as a duplicate of this bug. ***
80% with marquesine for longer links is my opinion
We should use 100% of browser screen size IMO for the best efficiency.
*** Bug 640388 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> (In reply to comment #1)
> > Can the bubble turn reddish if the destination is a known web forgery?
> That's a really interesting idea, but way outside the scope of this bug.
> Please file a new bug for that.
Eventually filed bug 650687.
This seems to be resolved on trunk - Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110621 Firefox/7.0a1 ID:20110621030803
Close this bug?
Not resolved - Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0a1) Gecko/20110621 Firefox/7.0a1
Still Fx uses only 50% of screen space for long links.
*** Bug 658918 has been marked as a duplicate of this bug. ***
(In reply to comment #0)
> Hover over the above link in current Trunk and it'll truncate to fit into a
> popup bubble half the width of the browser in the lower left. Since we're
> now showing this on top of content rather than in a fixed space in the
> status or location bar, we've got more room to spare. We should at least
> show as much of it as we can so the user is more informed. There's no need
> to truncate it if we have the room.
Exactly. Truncating harms. So let's truncate *only when we have to* truncate.
> Using 100% of the browser width might be too much. Maybe up to 80% or so?
I prefer 100 %.
Chrome's behaviour is to show the link initially truncated and the expands out to the full URL after a short delay.
I prefer 100%, abbreviating the URL achieves little and is annoying for developers
(In reply to comment #19)
> Chrome's behaviour is to show the link initially truncated and the expands
> out to the full URL after a short delay.
This behaviour is less worse, but stills particularly annoys me. If you can
show the link after 2 seconds, then show it at once.
I agree, it should show it all right away. It's a big reason I use FF over Chrome where if it's too long, you just can't see it all.
Think about the people who actually use that in the first place. They are either only interested in the domain, or they are going to want to see the entire link. There's no purpose in only displaying a piece of it, it doesn't give any info to anyone who's going to bother looking.
*** Bug 667149 has been marked as a duplicate of this bug. ***
*** Bug 673830 has been marked as a duplicate of this bug. ***
The author in Bug 673830 submits a convincing case on why,
Thanks to you not fixing this bug,
dragging your heels. See also http://bugs.debian.org/625829 .
Furthermore, forget about truncating. The bad guys will just figure out where to hide the juice in your latest choice of what sector to truncate.
I'd like to see it even if it was that long. Of course even I would see a huge inconvenience in a bar over say two lines high, that would take up a real good chunk of the screen. So perhaps only if I mouse over it or wait a couple seconds. The immediately visible portion of the url should cover 90% of urls without needing to wait or anything else and I think 2 lines would take care of that.
How about allowing the link preview to expand 100% in "normal" cases, but still limiting to 50% once it needs to switch side (link preview would stay at 50% until you hover another link, even if switched back to left) ?
(In reply to Matthieu Rivaud from comment #27)
Do something. Anything.
In the meantime it is like I'm driving around the Internet with this big
Garfield doll stuck right in the middle of my windshield.
If I crash into something, you guys are responsible!
What am I supposed to do.
Post URLs that I wished I could see the middles of,
every day until somebody fixes the bug?
Is there some Plug-in stuff I can use in the meantime that your are Dragging your heels? Sure, the final result will be you lock me out of the bug tracker.
But this is having a big impact on my life.
What plug-in works to prevent this in FF7? Are you sure.
OK, a certain Lena told me about https://addons.mozilla.org/en-US/firefox/addon/url-tooltip/ ... when combined with https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/ and when clicking [x]wrap long URLs in its preferences... I'm home free! No more hanging out on the deadsville bug page. See ya ... bye ... My Posse's On Broadway
The "URL Tooltip" addon makes a tooltip near the hovered link, overlapping page text. So I'm still interested in improving the bottom-of-the-page popup.
(In reply to Lena from comment #31)
Yes, "I like Firefox little truncated-in-the-middle injured URL"
ha ha ha... I'll be using the plugin for now until it gets fixed.
One notes that the plugins require the user to move the mouse on top of links.
Moving to the link via TAB will not bring satisfaction via plugins. Only fixing this bug can do that. Also are you sure the name 'hover" is correct in the bug title? As TABing to the link is not hovering, as the mouse is still hovering elsewhere.
Furthermore on links like
Firefox will thankfully show the rendered Unicode, whereas the average plugin will only show the annoying %E5%82%BB codes, even if more of a security defense.
I.e., I'm still suffering waiting for Firefox to fix this, even though using the suggested plugins.
(In reply to jidanni from comment #34)
I'm saying that with e.g., hovering over
I can see spitefully truncated Chinese at the bottom of the screen, and spitefully raw % coded in the tooltip balloon provided by the plugin I was told to use.
So I'm still not happy.
Which it is your job to make me be.
If you get some spare time.
The same problem occurs when I fly over an entry in the history panel.
Windows Vista. Firefox 4.0.1.
(In reply to Nicolas Barbulesco from comment #36)
The same use-case problems don't apply as much with respect to bookmarks and history. You can always view the full URL via the Library ("Show All Bookmarks" / "Show All History"). The tooltips for these would be different from this issue, in any case.
Also, only latest Firefox, currently 6.0, and latest Firefox 3.6.x are supported by Mozilla so if you're running 4.0.1 still you really should update to at least get the security and stability updates.
Yes, opening the history as the big window is a workaround.
But when I bring the history as the side panel and I fly over one of its entries, I get the annoying truncating in both the address that appears at the bottom and the address that appears in the yellow tooltip.
Firefox 4.0.1 Windows, Firefox 6.0 Mac.
tried to be good (clutter-free browsing) and became worse. at least firefox 3's same functionality should be back.
FWIW a sample from a phishing e-mail I got today:
Perhaps "security" should be added to the keywords.
Agree! Not fully visible links are a bad idea and can be used in 'exploits'
*** Bug 720287 has been marked as a duplicate of this bug. ***
Created attachment 613634 [details] [diff] [review]
is it intentional that after unmirroring the sizelimit attribute is not removed?
(In reply to Felipe Gomes (:felipe) from comment #44)
> is it intentional that after unmirroring the sizelimit attribute is not
Yes, since the user could have moved the mouse back to the bottom right side. Limiting the size once the status panel had to be mirrored once simplifies things.
I like this change, but there is a slight edge case that isn't covered.
Scroll comment 29 so that the bottom right corner of the screen has part of the link in it. Hover over that part (by bringing the cursor up from underneath, or in from the right). The popup will appear on the right and truncated with the cursor on top of it. This requires an extra mousemove to switch the popup back over to the left.