Long words (such as URLs) overflow columns
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
Critical
|
James Henstridge | ||
Bug Description
The way Malone displays URLs in bug pages and portlets at times causes excess width and horizontal scrolling
Long words in bug reports overlap into the right column of the page -- and sometimes beyond, causing horizontal scrolling.
Sometimes these words are URLs, such as "https:/
Sometimes they are not URLs, such as "OoÒÓÔÕÖØòóôõöø
Where such long words are present in titles, the problem is also present temporarily in the "Latest bugs" portlet.
Opera breaks URLs on slashes, so both bug #351 and https:/
Is this also one of the things you were working on kiko?
- and horizontal scrolling
+ The way Malone displays URLs in bug pages and portlets at times causes
+ excess width and horizontal scrolling
I posted some options for how to break words on one of the duplicate bugs. Since they are useful, I'll repeat them here:
1. use the non-standard <wbr> tag (word break). This is supported by all major web browsers (apparently includes Opera if used with some special CSS). Has the side effect that double click select won't select the entire word if it contains a word break.
2. use the zero width space character (​). Apparently causes some display issues in IE.
3. use the soft hyphen character (­ or ­). This character is supposed to only display when at the end of a line, and act as a word break. Unfortunately, it isn't properly supported by Mozilla (doesn't break words).
http://
https:/
4. use actual space characters. Works with every browser, but looks ugly and can change the meaning of the text.
A rundown of the compatibility for the various word breaking methods can be found here:
http://
In both cases, we'd need to make some decisions about where to place such breaks. How long can a word get before we break it? Do we just break words at a particular number of characters, or try to inteligently hyphenate the text?
The only option that does not break copy-pasting is the <wbr> tag. But it's not valid HTML by any measure.
Any other option is not acceptable for url, which are commonly copy-pasted. Of course you can right-click-
I witnessed one employee being badly surprised by copy-pasting a URL that contained zero-width space in the prototype of the branch registration code. That's why I removed the feature.
My preferred solution to this bug is:
* Do not try being smart, don't arbitrarily insert tags or special characters.
* Remove the right column, and use a layout that lets the browser handle overfull lines gracefully.
It is not a problem if scrolling is only required to view those veryverylongwords, and if they do not prevent other UI elements from being usable.
I am pretty sure that any other solution is bound to be diffult to implement and annoying in one way or another.
May I suggest addressing this problem with input validation? I can think of no valid use case for the user to enter this type of data when submitting a bug description or comment.
What do you mean by "this type of data"? If you mean long URLs in general, then it's perfectly reasonable for a user to file a Firefox bug report saying "this URL made my browser explode: ...".
On Fri, Sep 08, 2006 at 07:30:39PM -0000, Colin Watson wrote:
> What do you mean by "this type of data"? If you mean long URLs in
> general, then it's perfectly reasonable for a user to file a Firefox bug
> report saying "this URL made my browser explode: ...".
In my case the data was not a URL. I would argue that URLs which make the
browser explode shouldn't be displayed on the page for users to click. ;-)
--
- mdz
Taking.
Put a branch to fix this up for review. It fixes both long URLs and long words outside of URLs.
Merged to rocketfuel as r4201
fix included in today's rollout