See this all platforms checked on 10/23 Trunk and 10/29 Branch builds Nominating nsbeta1 for Buffy as it affects AIM Steps to repro: 1)Launch Composer and paste a long URL such as the following into the page: http://bugscape/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&product=InstantMessenger&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=exact&email1=&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=FixedTrunkOnly&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=keywords&type0-0-0=anywords&value0-0-0=nsbeta1 2)Resize the page to about half it's width. Actual results: URL goes off viewable area. A horizontal Scroll bar appears and you need to scroll right to see it fully. Expected results: URL wraps in viewable area of Compose window.

AIm bug in commercial is http://bugscape/show_bug.cgi?id=11755

Isn't this actually a layout bug? We certainly wouldn't want composer inserting actual breaks in the url text to reflect the author's page width (which would then display wrong on any recipient's machine). So if we want it to be displayed as wrapped, we'd want layout to do it without changing the actual document text. Is there some reason we'd want to see it wrapped in composer but not in the browser?

-> Karnaze

When I put a link longer than the viewport into composer it didn't wrap. When I viewed the page in Mozilla and IE, neither wrapped the link, so what is the bug?

If AIM wants it wrapped, maybe there could be an AIM-specific style sheet that makes links wrappable? For composer, I think we're okay as long as we do the same thing the browser does (so current behavior is fine).

Test Case attached

reproduced in 12/16 Trunk build, Win XP.

-> kin. nsbeta1-.

This needs to be fixed in the browser. It makes ALL the text hard to read on any page containing such a long link. That happens on sites like BBS's all the time, where people post long links. It's a long standing pain in the neck that gets worse and worse as message board sites become more and more popular.

I notice that the slashdot comment posting cgi breaks up long links to prevent this scrolling from happening. Before that change was put in, vandals were constantly posting long links on purpose, to make the rest of the comments unreadable without a lot of scrolling. The popular UBB (Ultimate Bulletin Board) web forum system also makes long links similar to the ones in the original example in this bug report. On sites where users like to link to each other's posts, a lot of the forum threads end up practically unreadable. There's one of those boards where I'm hanging out a lot lately, so this bug is really a major pain in the neck.

Could someone upgrade the severity of this bug to major. It is really a huge pain in the neck. It makes browsing many sites practically impossible. I find myself using lynx to read those sites.

Ping. Does anyone know a workaround for this bug?

(In reply to Akkana Peck, comment #2) > Is there some reason we'd want to see it wrapped in composer but not in the browser? Definitely. Many web forums allows one to use markup like [url=really_long_url_here]name[/url. This makes textareas difficult to use, but has no bearing on the browser display, as the URL is not shown. Prog.

Textareas (plaintext editor running in a form element) are different from html compose, which is what I was asking about in that comment. But honestly, given the current state of the web, it would be a significant boon to readability all over the web to have a layout style that can either wrap in the middle of long lines, or (even better) display all the normal text on a page wrapped to the visible window width, rather than to the length of the widest element on the page, so users don't have to scroll left and right to read the text (as described in comment 11).

This is possibly a dupe of Bug 136839 ("Browser doesn't wrap long unbroken strings of characters"). See also related Bug 56652 ("More intelligent Unicode-compatible linebreaking algorithms needed"). Prog.

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

This is fixed by bug 255990.