136839 - Browser doesn't wrap long unbroken strings of characters

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P4)

Description

[Yakov Markovitch]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

Mozilla doesn't wrap long lines in the document. 

Reproducible: Always
Steps to Reproduce:
1. Open the page

Comment 1

[Yakov Markovitch]

Attachment: Simple testcase for non-wrapped long lines inside <td> element

IE 5.0 renders this quite OK (wrapping long lines)

Comment 2

[Boris 'pi' Piwinger]

This is OS-independent. Anyways, Mozilla does not break in the middle of a word
(here: long URLs). I think this is correct. Suggesting: INVALID or WONTFIX.

pi

Comment 3

[Ian Graham]

This is not a table issue -- MOzilla never inserts formatted line breaks break
inside contiguous strings of characters, inside a table or not.  I changed the
subject line to reflect this, and changed component to layout.

Internet Explorer 5+ also does not add line breaks inside strings -- _except_
after percent (%) characters [maybe others, I didn't check all of 'em]. For
example, IE will not break inside a long string containing only roman letters
and/or numbers. 

If we wanted to add such breaks, we'd need to define how and why we want to do
so, and also make sure that cut and paste doesn't include the inserted break.
You'd probably also want a way of turning this on and off (a style property,
perhaps).

This seems equivalent to automatic hyphenation (see bug 67715). Mark as a
duplicate?   
 

Comment 4

[Yakov Markovitch]

May I add my two cents:
1. There are quite a few sites that obviously rely on that long URLs be wrapped;
2. Such sites look terribly wrong in Mozilla; 
3. Long URLs are common enough, and any page with such URL will look wrong.
4. Since very long URLs almost always have % character inside, it indeed would
be enough to break long lines on this character.

Comment 5

[Amarendra Hanumanula]

Adding the testcase keyword and setting the priority.

Comment 6

[Ryan]

I encounter long URLs all the time especially on message boards, where a single
long URL can make a whole bunch of posts nearly unreadable (entire page is too
wide because of one posters long URL).  I also think that this should be an
option, perhaps as simple as an option to wrap all URLs to the current window width.

Comment 7

[karnaze (gone)]

mass reassign to default owner

Comment 8

[Mike Cowperthwaite]

This appears to be a dupe of Bug 95067.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

bug 95067 might be specific to hyphens, but bug 95067 comment 64 might be
relevant here.

Comment 10

[Christopher Hoess (gone)]

*** Bug 196591 has been marked as a duplicate of this bug. ***

Comment 11

[Malx]

Addition to Layout of not-wraped URLs:

 If you have table with fixed width and long URL (which is not wrap) then
you see strange thing:

1. URL will cross the tables border
2. URL will overwrite something near table (if there is floating box)
3. You will not be able to click right part of URL (which is outside of table)
 (it is strange thing if table border=0 see example)
4. Some times right part of URL will disappiar completly.
 (example - when you rigth-click near it and context menu will cover link)

Example: 
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=72360&ixReplies=2
 (discussion board - it could be deleted)

IMHO this is essential:
<table cellSpacing=0 cellPadding=10 width=610 border=0 STYLE="table-layout: fixed">

Comment 12

[erik johansson]

Attachment: Test case: Table-Layout: fixed, how it works in mozilla

testcase attachment for comment #11.

Wrapping should happen, the line/link/word should be confined in the table, and
not span outside. If not possible to wrap it CHOP it.

Opera: wraps on /, and then chops
Explorer: wraps on & and %, and then chops
Mozilla: No wrap and no Chop

IMHO it should wrap anywhere.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This bug is too vaguely defined to be able to say that a certain change would
"fix" it, and is therefore too vaguely defined.  We already have separate bugs
about breaking around - and /.  If we need to break on other characters (see UAX
#14's recommendations, perhaps?), we might want different bugs, or you might
want to mark it duplicate of a bug on implementing a specific linebreaking
algorithm (e.g., that in UAX #14).

Comment 14

[Clarence Risher]

The recent popularity of links to the new google maps service, often a few
hundred characters long, has brought this bug ("that is, a feature that cannot
be turned off") back to the forefront of my 'most annoying Mozilla bug' list. 
I'd like to put in my 2 cents in favor of some sort of option for last-ditch
text breaking in cases like this.  I have opinions on the hyphen, bracket, %,
etc etc wrapping arguments, but those belong elsewhere.  What we need here is
some sort of fallback that will wrap the most stubborn of strings (such as a
long bacteria or chemical name) forcefully after all else fails.

It is to the point that over 50% of the posts I read on some forums every day
are almost unreadable.  Barring a chance of it actually being fixed, I thought
this may be a worthwhile place to ask if anyone may have a bookmarklet that will
serve as a 'brute force' solution to this problem, perhaps inserting spaces into
very long words, or even just truncating them?

PS: of course bugzilla wont let us change the platform and OS, but perhaps
someone should, in the long term interest of proper bug categorization.

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Bug 255990 is fixed now. Therefore, in many cases, we should not have this bug. But it is not fixed the second testcase (attachment 132569 [details]). Because the patch is not breaking the simple long string which only has alphabets/numerics. e.g., 'a' is typed very many times. I think that the issue should be marked as WONTFIX (or INVALID).

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

And WinIE7 doesn't break the simple long string in the second testcase (attachment 132569 [details]), we don't need to break it...

I'm marking this to FIXED.