Last modified: 2007-05-24 20:56:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3438, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1438 - diff views do not wrap text, can be many times wider than browser width
diff views do not wrap text, can be many times wider than browser width
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
unspecified
Other other
: Normal normal with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
:
: 4494 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-31 07:19 UTC by Jeff Bonham
Modified: 2007-05-24 20:56 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Screenshot of broken diff rendering in Netscape 7.0 (83.99 KB, image/png)
2007-05-24 16:13 UTC, Ilmari Karonen
Details

Description Jeff Bonham 2005-01-31 07:19:30 UTC
In diff view, lengthy lines of text (without whitespace) cause the view to expand 
horizontally without restriction.  This makes viewing the differences between 
versions with long lines impractical. 
 
Example: 
http://en.wikipedia.org/w/index.php?title=Wikipedia&diff=next&oldid=9818898 
(tested on KHTML)
Comment 1 Brion Vibber 2005-01-31 07:20:36 UTC

*** This bug has been marked as a duplicate of 1229 ***
Comment 2 Stewart Gordon 2006-03-09 14:58:47 UTC
Bug 1229 is about the widths of the diff columns relative to each other.  This
is about the absolute widths of diff columns.  Never mind that that bug has
received so many off-topic comments.
Comment 3 Stewart Gordon 2006-03-09 14:59:46 UTC
*** Bug 4494 has been marked as a duplicate of this bug. ***
Comment 4 Brion Vibber 2006-03-09 21:25:38 UTC
Indeed, they may be wide if content is wide. That's why god invented scroll bars.
INVALID.
Comment 5 Omegatron 2006-03-09 21:31:17 UTC
(In reply to comment #4)
> Indeed, they may be wide if content is wide. That's why god invented scroll bars.
> INVALID.

Ummm...   So the whole page has to be widened when only a single element is too
long?  Scroll bars can be applied to individual elements, you know.

(not invalid)
Comment 6 Stewart Gordon 2006-03-10 10:29:11 UTC
Exactly.  All too often I come across diffs that are hard to read because they
are too wide, generally because of very long URLs.  This bug was filed in order
that a fix for this problem may be developed.    See the off-topic discussion at
bug 1229 for more info.

Traditionally, the way around it was to use tinyurl.  However, now tinyurl and
similar services are on the spam blacklist.  I filed bug 4891 on how better to
deal with such URLs, but others so far don't seem to like my idea.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-06-14 06:57:51 UTC
Hacky workaround (at least for Firefox): td.diff-context, td.diff-deletedline,
td.diff-addedline { overflow: auto; display: block; }.  For other browsers, a
much slower and possibly buggy Javascript hack is at
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_User_scripts/Scripts/Fix_diff_width.
Comment 8 blah 2006-07-17 23:25:32 UTC
This is a valid bug (or at least usability problem).  I think something should
be done about it.  See:

http://en.wikipedia.org/wiki/Page_widening
Comment 9 Ilmari Karonen 2006-07-18 00:13:00 UTC
While this doesn't fix the actual problem, in many cases the need for horizontal
scrolling could be significantly reduced by inserting soft word breaks in
certain locations, such as after slashes, in the diff text.

Unfortunately, the only markup for a soft word break that renders safely (i.e.
either as intended or not at all) in all browsers is the "<wbr>" tag, which is
not valid XHTML (see f.ex. http://www.quirksmode.org/oddsandends/wbr.html).  I
believe brion at least has opposed its use for that reason.  The second-best
alternative is probably "<span style="font-size:0px"> </span>", as used in
[[Template:Wbr]], but this renders as a visible space in non-CSS browsers.  The
Unicode zero-width space (&#8203;) is even worse, since on most older and some
newer systems it renders as a very conspicuous "unknown character" box.
Comment 10 Brion Vibber 2007-05-15 21:25:58 UTC
Did a little poking in r22192, which resolves this for Gecko and Opera, but not
for MSIE or KHTML. (See further comments on the commit.)
Comment 11 Brion Vibber 2007-05-16 18:02:27 UTC
r22204 fixes this for MSIE, KHTML (Safari and Konqueror) and iCab. Yay!

I'm now using the fixed table layout style; this should also take care of bug 1229.
Comment 12 Brion Vibber 2007-05-17 15:04:40 UTC
In r22227 I also added the 'word-wrap: break-word' CSS property, so we can get the desired wrapping behavior instead of the uglier scrolling in more cases.

This property is in CSS 3 draft, and supported by Internet Explorer (tested 6 and 7) and Safari.

Unfortunately Gecko/Firefox still doesn't support it:
https://bugzilla.mozilla.org/show_bug.cgi?id=99457

nor does Opera, but we can hope they'll add it eventually.
Comment 13 Ilmari Karonen 2007-05-24 15:44:18 UTC
Regarding the rendering problems in IE:  An explicit "width: 100%" might solve the lack of a scrollbar in IE 6.  An explicit "overflow-y: visible" (with higher specificity than the general "overflow: auto") might solve the spurious vertical scrollbars in IE 6/7.  These may, in turn, require the following IE-specific workaround to avoid the scrollbar overlapping the content:

table.diff td div { padding-bottom: expression(this.scrollWidth > this.offsetWidth ? "16px" : 0); }

(Note that all of this is guesswork, since I don't have IE to test with here.  However, I did do some testing of these things back when I wrote [[Wikipedia:WikiProject_User_scripts/Scripts/Fix_diff_width]].)

There have been some reports of severe rendering problems involving the vertical collapse of table cells down to one line.  One browser this has been reported on is Netscape 7.0 / Unix, which I'm currently installing to see if I can duplicate the issue.
Comment 14 Ilmari Karonen 2007-05-24 16:13:22 UTC
Created attachment 3672 [details]
Screenshot of broken diff rendering in Netscape 7.0

I've managed to reproduce the rendering bug on Netscape 7.0, see attached screenshot.  The scrollbars are completely missing, and all table cells are reduced to a height of one line.
Comment 15 Ilmari Karonen 2007-05-24 17:34:08 UTC
The rendering in Netscape 7.1 is correct; presumably this is a Gecko bug fixed between 20020823 and 20030624.  I'm not sure there's much we can or should do, except to advise the affected users to upgrade.
Comment 16 Brion Vibber 2007-05-24 20:56:38 UTC
There are no remaining IE 6.0 issues, since proper wrapping is now enforced there. The scrolling mode is only a workaround for browsers not supporting the forced wrapping.

The old Gecko problem is bug 9948, see my comments soon there.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links