Last modified: 2007-06-13 20:08:32 UTC
Created attachment 3650 [details] screenshot of Mozilla 1.1 showing the bug. Note lines at the bottom of diff -- they are truncated. As of today, diff no longer wraps lines in Mozilla 1.1 browser. It shows only the beginning of lines, browser window size-dependent. This makes diff unususable in most instances. Demonstrated en and pl Wikipedia, Commons. Does not happen in Firefox 1.6a or Opera 9.20 on the same platform (linux/ppc). Does not happen in SeaMonkey 1.1.1 on Windows XP SP2. Bug did not happen as of yesterday (16 May 2007).
Seems to be a bug with overflow: auto in ancient versions of Gecko; confirmed in 1.1 on Mac OS X. It seems to work fine in Mozilla 1.2.1 (copyright 1998-2002), so you might try upgrading to a slightly more recent Mozilla release.
(Note it's showing scrollbars in 1.1/Mac, but they're very small and vertical.)
Created attachment 3673 [details] A possible JavaScript-based workaround I'm not entirely happy with this, but it seems to do the job as long as JavaScript is available... This does a quickie JavaScript hack to check specifically for Gecko older than the version reported by Mozilla 1.2.1, and override the 'overflow: auto' style back to 'overflow: visible'. The result is that very long diff lines will spill out, but without disrupting the page layout. Sub-ideal but much better than the current behavior. Downside is that it won't trigger without JS. I'm leery of server-side User-Agent checks for something like this; I'd prefer to find a nice friendly CSS layout that doesn't break the old Mozillas, of course. :) One other possibility is to change the diff.css definitions to use overflow-x and overflow-y instead of overflow; this is supported in Mozilla 1.9 / Firefox 1.5 and later, where the overflow properties actually work properly... but not by Mozilla 1.2 through 1.7, Firefox 1.0, or Opera. So it would provide sub-ideal output on many more not-quite-current browsers and some current ones.
(should say Mozilla 1.8, not 1.9, above.)
What's the status of incorporating the JavaScript remedy proposed above in production code? It's not there as of WikiMedia 1.11alpha (r22718). The fix does work for me on the affected machine where the bug was noticed and for Mozilla 1.1beta on Mac Os X. Has it already gone in and possibly got overwritten, or is it still in the queue? Or are the developers considering a different fix?
Applied with fixes in r22970
