Last modified: 2008-10-26 08:51:58 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 T17925, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15925 - Asymmetric rendering of bytes-changed in watchlists and recentchanges
Asymmetric rendering of bytes-changed in watchlists and recentchanges
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-10 11:17 UTC by Happy-melon
Modified: 2008-10-26 08:51 UTC (History)
2 users (show)

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


Attachments
Patch (1.29 KB, patch)
2008-10-11 13:43 UTC, Happy-melon
Details
Fixes bug while reverting previous commit (to RecentChange.php) related to this. (2.00 KB, patch)
2008-10-14 23:55 UTC, FunPika
Details
Improved per suggestions by Brion on #mediawiki. (1.99 KB, patch)
2008-10-15 00:30 UTC, FunPika
Details
More improvements (1.86 KB, patch)
2008-10-15 00:56 UTC, FunPika
Details
Uses abs function instead of new global per Demon. (1.19 KB, patch)
2008-10-15 19:53 UTC, FunPika
Details
use abs more in check, use .patch format. (1.16 KB, patch)
2008-10-15 20:34 UTC, FunPika
Details

Description Happy-melon 2008-10-10 11:17:46 UTC
The current method for rendering the bytes-added/removed values in watchlists is asymmetric.  For a small negative change, it uses "<span class='mw-plusminus-neg'>(-84)</span>", for a large negative change it uses "<strong class='mw-plusminus-neg'>(-627)</strong>" ("strong" makes it bold), but for *any* positive number, it uses "<span class='mw-plusminus-pos'>(+19,269)</span>". This means that while large deletions are bolded, large additions (which may be adding trivia or restoring legitimately removed content) cannot be similarly highlighted.  It should be trivial to extend the check to both sides of zero.
Comment 1 Happy-melon 2008-10-10 12:16:24 UTC
The code is at the bottom of /includes/RecentChange.php - I'd just replace the stacked ifs with something like this:

        return '<' 
               . ( abs($szdiff) > abs($wgRCChangedSizeThreshold) ? 'strong' : 'span' ) 
               . ' class="mw-plusminus-'
               . ( $szdiff == 0 ? 'null' : ( $szdiff > 0 ? 'pos' : 'neg' ))
               . '/>(' . ( $szdiff > 0 ? '+' : '' ) 
               . $formatedSize . ')</span>';

Backwards compatible AFAIK. 
Comment 2 Happy-melon 2008-10-11 13:43:02 UTC
Created attachment 5418 [details]
Patch
Comment 3 Chad H. 2008-10-14 12:57:07 UTC
Patch applied in r42078
Comment 4 FunPika 2008-10-14 23:54:08 UTC
Patch appears to have completely messed up RecentChanges. The +- character parts no longer appear, and the majority of Special:RecentChanges became bolded. 
Comment 5 FunPika 2008-10-14 23:55:25 UTC
Created attachment 5434 [details]
Fixes bug while reverting previous commit (to RecentChange.php) related to this.
Comment 6 Brion Vibber 2008-10-15 00:07:47 UTC
Reverted r42078 in r42088 -- bad HTML completely breaks output, as well as just making the code much harder to read.
Comment 7 FunPika 2008-10-15 00:30:42 UTC
Created attachment 5435 [details]
Improved per suggestions by Brion on #mediawiki.
Comment 8 FunPika 2008-10-15 00:56:56 UTC
Created attachment 5436 [details]
More improvements
Comment 9 Brion Vibber 2008-10-15 00:58:36 UTC
Looks good!
Comment 10 Happy-melon 2008-10-15 12:22:05 UTC
<cries in corner>Methinks I need my own copy of MediaWiki that actually runs... Such a stupid error too... </cries in corner>

Sorry for breaking the universe :-D
Comment 11 Chad H. 2008-10-15 19:30:10 UTC
Only thing I wonder, why are we bothering with a new global? Wouldn't it be easier to just abs() like in the original patch?
Comment 12 FunPika 2008-10-15 19:53:22 UTC
Created attachment 5438 [details]
Uses abs function instead of new global per Demon.
Comment 13 Happy-melon 2008-10-15 20:27:23 UTC
Wouldn't using abs() on $szdiff as well obviate the need for the more complex logic test? 
Comment 14 FunPika 2008-10-15 20:30:14 UTC
^demon already did it to his local copy but said nothing here. 
Comment 15 FunPika 2008-10-15 20:34:14 UTC
Created attachment 5439 [details]
use abs more in check, use .patch format.
Comment 16 Chad H. 2008-10-15 20:39:45 UTC
Applied correctly and with all the fixes in r42110
Comment 17 AlexSm 2008-10-26 05:55:00 UTC
There was a good reason why additions weren't bold: discussion pages. 

With r42110 both RC and watchlist look really ugly. There are so many bold green numbers that the boldness simply becomes useless. 
Comment 18 Happy-melon 2008-10-26 08:51:58 UTC
the bytecounts can be styled easily enough; 

strong.mw-plusminus-pos {font-weight:normal;}

would do the trick.  Styling can be applied at either an individual, wiki, or sitewide level.  The important thing is that the facility is there to have the numbers bolded if desired.

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


Navigation
Links