Open Bug 249641 Opened 20 years ago Updated 2 years ago

Long URL makes webpage too wide for window

Categories

(Core :: Layout, defect)

x86
Windows XP
defect

Tracking

()

UNCONFIRMED

People

(Reporter: ehume, Unassigned)

References

()

Details

Attachments

(7 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040702 Firefox/0.9.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040702 Firefox/0.9.0+

Web pages that contain URL's that are longer than the width of the screen cause
that web page to be wider than the screen, thus requiring mousework to read
lines of text.

This has long been a problem with Px/Fb/Fx. It is a significant user issue.

 Even if we get to web designers, it will likely not be enough without fixing
Fx. Take this example: although the web designer for this page--

http://www.strategypage.com//fyeo/howtomakewar/default.asp?target=HTCBTSP.HTM

--did not place an extra-long URL on the page, a user responded with a message
that included a long URL on 2004-06-15. Oops. Now it's hard to read.

Reproducible: Always
Steps to Reproduce:
1. Attempt to read a page where the URL is longer than the screen is wide.
2.
3.

Actual Results:  
Page too wide for screen.

Expected Results:  
Either:

Break the URL's when they are longer than the screen is wide, or

Word wrap normal text while allowing extra-long URL's or extra-long text of any
sort to hang over the edge.

The norml work-around is to use the IE View extension to view the page in IE,
which breaks the URL's into manageable chunks.
I second this. I'm designing a web site that takes user input (like a message
board for example), and the page layout and tables get messed up in
mozilla/firefox because it doesn't properly wrap long lines. IE does it fine. 

Mozilla should make this a high priority bug because it seriously messes up the
layout of many pages, and there is no good way that I know of for the web
designer to fix this (I can manually break long strings into separate lines, but
then the link will be two or three separate links rather than one contiguous link). 
This bug was last touched before 1.0.4. Is it still reproducable?
Try the latest branch build (1.0.5): http://www.mozilla.org/products/firefox/
Try the latest nightly trunk build (v1.0+): http://www.mozilla.org/developer
(Reviving old UNCONFs)
Still reproducible with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b3) Gecko/20050713 Firefox/1.0+

Test page: http://www.jerrypournelle.com/mail/mail364.html#Thursday


Keywords: qawanted
Ok this image confirms the bug submitted already.  Although I have since had this behavior happen even when a long address was NOT in the address bar.  Seems to happen randomly.
*** Bug 332276 has been marked as a duplicate of this bug. ***
Long URL string in the middle of the screen capture (underlined in red) will not break, and forces containing TD off the screen. This line should break, ideally at punctuation?
I have this problem with long URLs as well as long signature images.  My problem is exacerbated by the fact that, many times, I have no horizontal scrollbar and am unable to read text that falls to the right of the screen.  Should I post this as a separate bug?  I added an attachment to demonstrate the problem.
Confirmed in latest firefox

Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.1) Gecko/20061213 BonEcho/2.0

Would something like adding "/" (And perhaps "&" and "?" to the list of separators work?
There does seem to be no problem with a link spanning various lines of text.
Actually, only the url is longer than the width of the page.
Text is wrapped in the way mentioned in the message above:

Word wrap normal text while allowing extra-long URL's or extra-long text of any
sort to hang over the edge.

Assignee: bross2 → nobody
So, as I'm understanding it, this bug exists only on certain pages where the URL or other text extends past the window border on the right and, apparently, a horizontal scrollbar is never created. Is that the case?

I've never seen this happen without a horizontal scrollbar present. Can you please provide sites this happens on as well as a testcase (please attach it to this bug.)
Scrollbars are created, but then one must scroll back and forth to read each line of text, which is a considerable annoyance, especially for a page with a lot of text. Lucky for us Windows users that we have the IE Tab extension, which allows us to switch the page view to IE. 

Not so lucky are the Linux users. I suppose Mac users can switch to Safari.
Can you please provide a specific site this happens on as well as a testcase? I'm guessing that Firefox is rendering these sites as they're designed.
The site at the top of the bug is no longer reachable. However, this site shows the behavior:

http://forums.mozillazine.org/viewtopic.php?t=521325&sid=749c8f2866bb7895a7a7d585ee716483

Go to this post: 2007-02-17 2017  
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Based on comment 14, Firefox is rendering the site as expected. I'd guess this bug is INVALID, but I'll let a layout triager make that call.
Keywords: qawanted
The site referenced in comment 14 is NOT rendering as expected. Nobody wants to be forced to scroll back and forth to read lines of text. Perhaps with a small font size you are having no problems, but it is a problem for me with my 1280-pixel screen. It is also a problem for others, since I see the occasional comments to posters on how to avoid making long urls such as the example in comment 14.

Try, as an exercise, opening that link in IE. Where Firefox does not break up the url and thus causes the page to be overly wide, IE breaks up the url and makes the page manageable. If IE can do this, why not Firefox?
Was just going through a list of old Bugs I'd voted on and saw this one still alive. I did some testing and realized that it's not actually the fact that it is a 'long URL' that makes long URLs wrap, it's just that it's 'long text' that's not wrapping correctly.

In order to test the browser's wrapping behaviour, I made an .html file (attached) in which I could toggle on & off the visibility of both an excessively-long URL ('Example #1') a text(non-linked) version of the identical string ('Example #2).

note: For simplicity's sake, I used 1024x768 resolution and made the string very long and am hoping that it's sufficient even on a wide-screen monitor.

My observation is that Firefox is 'smart' but 'not smart enough' !!
.. while it breaks a line (URL or text, no difference) at a natural 'break-point' such as a '/' and then continues on the next line, if it cannot find a suitable 'break point' then it will just spit out that unbreakable-portion all out on the 1 line, thereby invoking the horizontal scroll bar.

I then repeated the test in IE7, Maxthon-2, Google Chrome beta and Opera 9.6 -- the first 3 are 'stupid' in that they do not wrap at all(!) whilst Opera was refreshingly 'intelligent' - wrapping the whole thing as most users might expect 'wrap' to wrap*. I will attach screencaps of the Firefox result, the IE7 result and the Opera result.

* 2 notes about Opera's wrap:
   1)-As you can see from the screencap that I will attach in a moment, Opera has a "Fit to Width" option, that can be toggled from the Menu and/or from the StatusBar. Obviously "Fit to Width" must be *enabled* for the wrap to be 'intelligent', turn it off and you just get 1 long line and the inevitable horizontal scroll bar.
   2)-Interesting to note that what I referred to above as 'intelligent wrap' seems to be the result of a 2-step process / conscious design decision ... if you look at the 2nd line of either of my examples, Opera seems to realize that the (exceedingly-long) filename will not fit on that line, so it doesn't even bother trying to squeeze it in and creates a 3rd line and commences the filename portion of the string there. It then gets to the end of the 3rd line, and not yet finding a 'break point', wraps to the 4th.

   I suppose it's probably open for debate, but I would *expect* to see NO blank-space in a properly wrapped long string (URL or text) -- my examples should be (IMHO) 3 FULL lines followed by whatever is remaining on the 4th.

--
As the result of my findings, I don't know whether this Bug should be marked 'duplicate' of another text-wrap-related Bug or whether a 'Fit to Width' enhancement Bug should be filed. I did find Bug 276166 "Implement 'Fit to window width' as in Opera 8.0 (no-horizontal-scrollbar mode)" but reading the Bug it doesn't actually sound like they're even talking about the same thing.

Feedback?

*** 4 attachments coming up in quick succession ***
As per Faaborg via a recent Mozillazine thread asking for Firefox 3.1 'polish'
suggestions (http://forums.mozillazine.org/viewtopic.php?f=23&t=938165) - I'm
adding him to the CC list and requesting someone with Bug permissions to and
the following Whiteboard terms to this bug (less single quotes on each):
'[polish-hard]', '[polish-visual]' and '[polish-high-visibility]'
This isn't a polish bug, and frankly, it isn't really what we look for in a bug report.  (One of the most important things we look for in a bug report is that it should be easy to determine whether the bug is fixed.  If it's not, how would we know when to mark it fixed?)  This bug report seems to be a description of a general category of problems related to:
 1. what we allow vs. don't allow as a break point, and
 2. how different layout systems respond to text wider than its container.

Specific things that should be changed about each should be filed as specific bugs.  However, please be aware of the requirements of relevant specifications (e.g., CSS 2.1) when doing so.

In particular, I expect most of the bugs that ought to be filed are related to the first category.  But I suspect many of them are already filed.  One that might not be is doing emergency breaking by default, even in the middle of a sequence of Latin letters.  (I'm not sure whether we want to do that, but it's one of the things suggested here.)

But, again, specific issues that can be clearly demonstrated to be either "fixed" or "not fixed" should be filed as separate bugs.  This one should probably then be marked as incomplete or invalid.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: