[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator

History page unnecessarily renders last row in its own list
Closed, ResolvedPublicBUG REPORT

Description

List of steps to reproduce (step by step, including full links if applicable):

  • Visit a history page where the 2 edits at the bottom of the list share the same day of edit.
  • Inspect the DOM to see if they are li in the same list

What happens?:

When rendering the history page, edits are grouped by date.

Displaying each row requires the revision ID from the next row, to create the 'undo' and 'prev' links. (These links specifically refer to the next displayed row, according to the current filters, and not just the previous revision, like the byte diff numbers.)

Previously this class would override normal row formatting to display the previous row instead when the normal pager would display the current row, and then handled the last row especially. This code dates back to 2009: 3b4e961c47. It was complicated and got more complicated when grouping by dates was introduced (ed63ede657), when it caused the last row to be displayed in a separate list.

What should have happened instead?:

We'd like the edits to be grouped in the same list.

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.:

Event Timeline

Change 766160 had a related patch set uploaded (by Jdlrobson; author: Bartosz Dziewoński):

[mediawiki/core@master] HistoryPager: Refactor to avoid special handling for the last row

https://gerrit.wikimedia.org/r/766160

Requesting a review from @tstarling on this particular patch given he worked on the patches in 2010-ish that introduced the existing behaviour.

Change 766160 merged by jenkins-bot:

[mediawiki/core@master] HistoryPager: Refactor to avoid special handling for the last row

https://gerrit.wikimedia.org/r/766160

matmarex claimed this task.

The fix will be deployed to Wikimedia wikis later this week, per the usual schedule.