Page MenuHomePhabricator

Empty diffs appear as long columns of text when viewed in Safari
Closed, ResolvedPublic

Description

Author: titoxd.wikimedia

Description:
The right-hand side of the diff headers' output (where the user who made the edit, as well as his/her talk page, contributions, etc) in the Modern skin is sometimes heavily compressed when seen in Safari v3.0 and higher in Mac OS X. This bug does not occur all the time, but the page linked in the bug description shows an example of one time it does occur.


Version: 1.13.x
Severity: normal
URL: http://en.wikipedia.org/w/index.php?title=Template:Red&diff=next&oldid=208929760

Details

Reference
bz13875

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:13 PM
bzimport set Reference to bz13875.
bzimport added a subscriber: Unknown Object (MLST).

titoxd.wikimedia wrote:

Screenshot of affected page

Attached:

Bug_13875.png (835×1 px, 157 KB)

Updated summary -- it's not just Modern skin, it's any skin. Only affects diffs that show no changes (such as on a move or protection log entry).

Tested w/ Safari 3.1 on Mac OS X 10.5.

wiki.pierroman wrote:

I also have the same problem with Safari 3.1.2 on Windows Vista, with default skin.

There's a screenshot of the diff from the user who pointed out the bug to me: http://fr.wikipedia.org/wiki/Image:Nanoxyde1.jpg
And a link to the diff: http://fr.wikipedia.org/w/index.php?title=La_Mort_de_l%27incroyable_Hulk&diff=next&oldid=29835762

thecentercannothold wrote:

ok, here is a temporary solution to the problem. copy the following code into your monobook.css page:

table.diff {
table-layout: auto ! important;
}
table.diff td.diff-ntitle,td.diff-otitle {
width:50% ! important;
}

this might cause table expansion with ling URL names, but at least you'll be able to read the URLs.

The problem, as far as I can figure out, is that when Safari sees a table with (a) 'table-layout:fixed', (b) defined columns, (c) a colspan property on the last table cells in the first row, and (d) no data in the last cell of any of the other rows, it gives the colspaned cell the width defined in the first column. in our case here, col 3 is for the +/- checkmarks and is preset to 2% of the table width, so Safari s trying to choke what should be going into a 50% colspan=2 cell into 2% of the space.

Needless to say, I'll report this to apple, but if anyone can find a more permanent solution...

thecentercannothold wrote:

better solution - delete the above addition from monobook.css, and add the following code to your monobook.js page:

<pre>addOnloadHook( function() {
var url = document.URL;
if ( url.search(/&diff=/) == -1 ) return;
var tbody = document.getElementsByTagName("TBODY")[0];
var row = document.createElement("TR")
var td = new Array
for (i=0; i<4; i++) {

		td[i] = document.createElement("TD")
		td[i].appendChild(document.createTextNode(""))
		row.appendChild(td[i]);

}
tbody.appendChild(row);
} );</pre>

it adds a dummy row at the bottom of the diff table that straightens everything out.

If adding an empty row fixes the diff for safari, it may well be added to mediawiki.

A simpler fix yet may be just to replace "<td colspan="2">&nbsp;</td>" in diff output with "<td>&nbsp;</td><td>&nbsp;</td>". There's no real gain from using colspans there.

thecentercannothold wrote:

well, I think the colspans in the first line are so that the revision headers center properly (otherwise they'd center in cells 2 and 4, which would make them appear slightly skewed to the right because of the 2% width of cells 1 and 3). not a huge issue of aesthetics, but still...

the dummy line would work, probably, though there has to be an empty text node in the cell - I think Safari treats cells with empty text nodes differently from cells with null content.

we could also remove the HTML COL elements. removing those would solve the problem somewhat (there's still an issue with Safari only using the width of cell 3, but at least without the COL elements it minimizes the space taken up by cell 4 and maximizes 3). but then we'd have to code cell widths into each cell.

I love Safari, really, but on some occasions the thing is a royal pain. :-)

wiki.pierroman wrote:

The same bug occurs with Google Chrome (1.0.154.53). Another example: http://fr.wikipedia.org/w/index.php?title=Modèle:L&curid=1019424&diff=40072824&oldid=39862247

Now that more than one browser is affected by this problem, it would be a good idea to find a proper solution to it... ;)

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

titoxd.wikimedia wrote:

This doesn't happen with Safari 4.0.2 anymore; should this be marked as fixed, or is there a temporary hack in place?

wiki.pierroman wrote:

Well, I still encounter this bug with Chrome (2.0.172.33), so the problem doesn't seem fixed at all to me.

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

Still somewhat of a problem at times. For instance: http://en.wikipedia.org/w/index.php?title=Kamen_Rider%3A_Dragon_Knight&action=historysubmit&diff=337010287&oldid=336578750

Shows the problem in Safari and in Firefox as well (see attachment for screenshot in FF)

The problem is that on empty diffs, the col elements are not added (<col class="diff-marker"/><col class="diff-content"/><col class="diff-marker"/><col class="diff-content"/> to the table. These elements set the width required in the CSS. By setting diff-otitle and diff-ntitle to width:50%; the problem is solved.

Created attachment 6946
Screenshot of behavior in Firefox 3.5

Attached:

SNa1CX.png (298×944 px, 66 KB)

*** This bug has been marked as a duplicate of bug 21053 ***