Last modified: 2012-03-13 00:33:09 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 T36978, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34978 - Mistake in filtered history page diff size
Mistake in filtered history page diff size
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.19
All All
: Normal normal (vote)
: 1.19.0 release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-05 00:00 UTC by Jarry1250
Modified: 2012-03-13 00:33 UTC (History)
2 users (show)

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


Attachments

Description Jarry1250 2012-03-05 00:00:40 UTC
See 
https://en.wikipedia.org/w/index.php?title=Milton_Keynes&action=history&year=&month=-1&tagfilter=possible+vandalism . Note that the diff size here is wrong, because the software has assumed for the fact that no more results were found that the diff must be for a page creation (thus ignoring the input of the tag filter). 

Specifically, HistoryPager::historyLine() assumes that if there is no $next, the revision must be a page creation. That is simply untrue. It would probably be worth switching to instead look at rev_parent_id (which is 0 if and only if the revision is a page creation), in which case the bug collapses into #34922 (which deals with the unexpected consequences on rev_parent_id === null).
Comment 1 Jarry1250 2012-03-05 01:08:17 UTC
As Bawolff points out on IRC, the whole relation assumed here - that the next log entry is the preceding log entry - is at fault. This causes both the problem outlined in comment #1, but also faulty diff size entries where a filter has meant that some intervening edits have been removed. Thus it seems inevitable to me at least that this feature will have to be rewritten to based it on top of rev_parent_id (bug #34922 closed, see bug #34981 instead for problems with that approach).
Comment 2 Aaron Schulz 2012-03-13 00:33:09 UTC
Fixed in r113696.

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


Navigation
Links