Last modified: 2012-08-13 22:19:44 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 T37526, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35526 - jquery.tablesorter should preserve original order of equal cells when reversing sort order twice
jquery.tablesorter should preserve original order of equal cells when reversi...
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on: 31255
  Show dependency treegraph
Reported: 2012-03-27 18:42 UTC by Richard Guk
Modified: 2012-08-13 22:19 UTC (History)
5 users (show)

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


Description Richard Guk 2012-03-27 18:42:48 UTC
The current tablesorter algorithm is "unstable": it does not preserve (or sort consistently) the relative order of rows where the cell content is equal.

For example, in the enwiki:VPT example linked below, clicking the "Col 1" sort button twice in the table below should preserve the order of rows 2 to 8 (or invert them then restore them). But instead, the tie-break rows sort pseudorandomly (returning to the orginal order after 6 clicks instead of 2).

It is confusing for tables to change the order of rows with identical sort values. Since Wikipedia articles are not expected to contain extremely large tables, computational optimisation should be less important than intuitive operation.

The current jquery.tablesorter.js claims to use a merge sort algorithm, but apparently not a stable one.

At present, enwiki is at version 1.19wmf1 (r114429). I do not know whether this also affects versions prior to 1.19.

Live JavaScript:


I think Bug 31255 is a different but similar issue.

Example at:

Wikitext of example table:

{| class="wikitable sortable"
! Col 1 !! Col 2 !! Col 3
| aa || aba || 1
| ab || abb || 2
| ab || abc || 3
| ab || abd || 4
| ab || abe || 5
| ab || abf || 6
| ab || abg || 7
| ab || abh || 8
| ac || abi || 9
Comment 1 Krinkle 2012-03-29 12:10:03 UTC
Changing summary to reflect the main issue raised (the intent to maintain original order when reversing the order twice)
Comment 2 Richard Guk 2012-04-13 14:50:42 UTC
Not only should the re-sorting be reversible; there should be consistent tie-breaking on each click.

A stable and intuitive tie-breaker (fallback secondary sort key) would be any one of:
* the original row order
* the current row order
* the sort order of content in other columns.

Clicking to reverse a column's sort order could either maintain the tie-breaker or reverse it. But whichever approach is chosen, there should be an implicit tie-breaker (or, equivalently, a stable sort algorithm) so that rows do not move to counterintuitive or inconsistent positions.

Example moved to
Comment 3 Richard Guk 2012-07-13 23:04:07 UTC
Fix proposed by Anomie at Gerrit change #15638
Comment 4 matanya 2012-08-13 22:19:44 UTC
patch merged. seems to be resloved.

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