Extension talk:RevisionSlider

This is the feedback page for the RevisionSlider extension. Read about what we've learned about creating a RTL-accessible extension. Please report all RTL-related issues on this talk page!

I tested this feature and it works well in the English Wikipedia.

I used only a mouse in my testing.

Tracked here.

Problem

As a user, I can't easily move to the previous (or next) set of revisions easily without using the mouse.

Background

Currently, if a user wants to move both pointers at the same time they need to click and drag the pointers twice, once to move the first pointer, and a second time to move the second one. While this makes perfect sense when the revisions are far apart, it is quite cumbersome when one wants to move to the previous (or next) two revisions.

Proposed solution

Keyboard shortcuts to move in each direction:

• Shortcut to move both pointers ( ctrl + alt + ← →) - simultaneous move the pointers to the two previous revisions.
• Shortcut to move one pointer (ctrl + ← → ) - move the left or right pointer to previous or next revision

For the second shortcut since there are cases where one would want to use either the left or the right pointer, maybe these would be better:

• Move right pointer- META+⇧ Shift+← →
• Move left pointer - META+← →

Hej,

thanks for the feedback. I created a ticket for your proposal on Phabricator so we can keep track off the idea and consider it for a future version or volunteers that might want to work on it. https://phabricator.wikimedia.org/T162119

Best,

Christoph

This seems like such an easy hack, that it would probably also be useful for mediawiki core, and it is also easy to write a simple userscript (something I'll probably do for myself).

Thanks for the prompt feedback...

I created this small userscript that does this. It doesn't yet move the pointers individually because that's a bit more complex. This even works on older mediawiki versions (> mediawiki 1.19).

// This software is entirely free to re-use, adapt, or sell  (hope it makes someone rich!), without any warranty of any kind or need to attribute "the IP". Use it at your own risk.
// Use ctrl + alt + arrow (left or right) to move to previous revisions or next.
var pressedKeys = {
	ctrl: false,
	shift : false,
	left: false,
	right : false
};
var urlQry = {};
location.search.substr(1).split("&").forEach(function(token) {
	urlQry[token.split("=")[0]] = token.split("=")[1];
});
document.onkeydown = function (event) {
	if (urlQry.type === "revision" || urlQry.diff) {
		if (event.ctrlKey) {
			pressedKeys.ctrl = true;
		}
		if (event.keyCode == 37) {
			pressedKeys.left = true;
		} else if (event.keyCode == 39) {
			pressedKeys.right = true;
		}
		if (pressedKeys.ctrl && pressedKeys.left) {
			document.getElementById("differences-prevlink").click();
		} else if (pressedKeys.ctrl && pressedKeys.right) {
			document.getElementById("differences-nextlink").click();
		}
	}
};
document.onkeyup = (function(event) {
	// reset status of the button 'released' == 'false'
	if (urlQry.type === "revision" || urlQry.diff) {
		if (event.ctrlKey) {
			pressedKeys.ctrl = false;
		}
		if (event.keyCode == 37) {
			pressedKeys.left = false;
		}
		if (event.keyCode == 39) {
			pressedKeys.right = false;
		}
	}
});

It is also works independently from revision slider, so maybe it will help future "searchers".

I just had this extension activated on a history page I've been utulising a few hours. I found no hide button; but a small tutorial. That tutorial contained no information about how to turn off this feature.

I'm experienced enough to guess that there might be some possibility somewhere in my preference pages; and I'll check that. However, I really think that the tutorial should contain a hint about how to disactivate this. Regards, ~~~~

There is a large collapse button in the top-right corner. See Extension:RevisionSlider#Usage. There is also a pin feature you might want to deactivate in case you accidentally activated it.

This a very nice feature. No issues so far. Thank you to everyone involved.

Thank you for taking the time to give us feedback! We were really happy when we received it (and we still are :-) - this is very motivating for everyone!

As far as I am concerned this useless graph is just clutter which interferes with my work. How do I get rid of it? ~~~~

Hi @JRSpriggs, you can disable the RevisionSlider by checking Don't show the RevisionSlider in your preferences under Appearance -> Diffs.

Its right now I think the vertical bars do not have enough room to show the potential difference in changes. For example you can just barley tell between something thats a minor grammatical change and something that has rewritten half the page. It would be useful if there was some option to expand the page.

I'm really curious, but need a screenshot or example page to understand the problem better. As of now the graph is logarithmic and dynamically scales so that the biggest change takes up 100% of the available height, with all other changes scaled accordingly. It's mathematically not possible for a minor change to look identical to a rewrite. Not even when a page's history contains a change that replaced the entire page.

Well I don't mean and didn't say it's impossible to tell the difference what I mean is that the difference between a minor change and a major change could be more visually noticeable when sifting through a large list of edits. So it would be nice but not required if it was possible to make the section taller by not using a logarithmic system and instead using a linear one.

I hope that clarifies it I just wanted to see if there was any way to make it easier for editors to find potentially malicious or significant edits in the history. I have included a screen shot showing the issue https://imgur.com/SA0QKpF. The high bar to the right is the a major edit while the other edits are either template edits or other wise minor.

Thanks for the help,

Reallygreatoaktree

I would love to understand better which page that is, on which wiki? How big are these changes according to the information shown in the popups?

The best theory I have at the moment is that what you describe as a "major" edit was removing and adding a similar amount of bytes, but the total size of the page didn't change much. The RevisionSlider bars are meant to show how much the size of a page changed, i.e. the same as the +/− in the watchlist.

Currently, the bars are showing the change in page size. This is nice, but it's not the most important aspect about an edit to the page. If someone would replace every letter of the page with an x, it wouldn't change the page size.

Maybe you could make the bars represent the "total of characters changed"? So that adding or removing a letter equals 1, but replacing a letter with another equals 2 ticks in the bar height, because it is actually 2 changes (removing and then adding)?

The bars could then sit on a baseline, with only one direction to show the total changes.

Alternatively, the bars could show the characters added on the top of the baseline, and the characters removed could be on the bottom. This would be a lot of useful info in one view.

You explained the idea really well. Thanks for that! We discussed this several times (just recently here). Unfortunately it's a hard problem. Not only is a "number of characters that actually changed" nowhere to be found in the database. It's not possible to reliably calculate it. Any number would be a questionable estimate. For example, what if a paragraph was moved but no other change made? Technically the new version contains all the same characters as before. How to visualize this? Something like -500/+500 wouldn't be correct because these 500 characters aren't removed from the article. They just moved to another position. Should we estimate the minimal number of keystrokes it takes for a cut and paste operation? Or should it be 0 because nothing actually changed? Which is what currently happens.

Personally I like the idea very much. But I'm afraid it's not possible.

Thank you for the quick reply. I see now that this is really much harder than I initially thought.

Should be fixed by task T352169.

Hi. Is there any hope the Revision Slider will work once on RTL wikis?

I'm a bit surprised. RevisionSlider is RTL-compliant pretty much ever since. I just tested it on a random RTL page and it works fine, as far as I can see.

Maybe you can describe the problem in more detail? Are you referring to the Hebrew Wikipedia? Maybe you accidentally disabled RevisionSlider in your preferences?

I always liked the Slider, and used it a lot on hewiki. I also participated very heavily in discussions about its creation. It was very helpful and worked in perfect way. But about a year or more ago it broke. I explained the problem to the creators in details. Don't remember if it was on this page, on Phabricator or anywhere else. Since then I'm waiting for the fix.

Now for the problems. There are two, and looks like they are interconnected and probably even have the same cause. The smaller problem is that clicking to "move to the previous screen" sometimes responds unexpectedly, didn't find any rules for this part. The bigger problem is that clicking on some particular revision always finds some another revision of the page. There was no case in all this time that I get the revision I expected to get, even by chance. Maybe it's because of RTL, because I suspected that if one clicks on fifth revision from the left on a current screen, they get the fifth revision from the right, and vice versa. But I'm not sure about this counting, maybe I'm wrong.

This sounds like it's related to phab:T336729 and maybe phab:T349208. I believe I can reproduce the issue now. I created a new ticket for us to keep track of it, see phab:T352169. Thanks a lot for the detailed report! We will definitely look into this.

A temporary workaround I found is to collapse the tools menu on the left. It looks like RevisionSlider works as expected without this menu.

No, all this does not fit the problem. I never uncollapsed the side menus, all three of them - main, tools, and TOC.

Let's create an example. I have an URL like this. It's exactly one revision diff. I open it. I click on RevisionSlider. I click on some revision on the left part of the slider. I get this, one old dot and two new dots. I try in the old Vector, I get this, three new dots. Back in Vector 2022. I add uselang=en. I get this, one old dot and one new dot, exactly as expected. Also, safemode does not help in this problem.

Anyone? Thiemo Kreuz?

Well, 23 day later, no answers.

The Technical Wishes team is tracking this via phab:T352169 and already invested quite some time in this and related issues, notably phab:T336729. Unfortunately we couldn't figure it out so far. What we know is that the underlying issue is probably as old as RevisionSlider itself. The reason we only see it now is because of the new Vector skin. We are very much interested in fixing this but need to invest our very limited resources wisely. For the moment the product decision was made to give this a lower priority as it's not blocking users from working with the history.

Both of these tickets have nothing to do with the problem, @Thiemo Kreuz (WMDE). They are about menus in Vector 2022, when I'm talking about the fact that the Slider does not work at all in all the skins.

Hello, @Aaron Liu. Could you tell me, please, why did you reverted this edit? The phabricator ticket has nothing to do with the problem. Thank you.

1. 14 minutes later, that account did some quite banal vandalism on another page. I assumed this one was also vandalism. 2. The slider seems to work as expected?

1. I see, Aaron Liu, thank you. 2. The slider does not work on RTL wikis more than a year, at least for me.

Yeah, I've tried your link with the default language and it works perfectly for me.

It worked for me to once or twice, and didn't work dozens of times, as you can see in the screenshots.

A couple of months later. Is there something new? Maybe you should just remove the RevisionSlider at all on RTL wikis until you found and fix the problem. As with graphs or wikicode highlighting. For now, it just takes space.

You can collapse it, and it works for a lot of people. Also, the linked task has had a lot of patches lately. Maybe it'll be fixed when you check back next Wednesday?

What do you mean in "you can collapse it", @Aaron Liu, how does it help in all the screenshots I brought? I'll check, no problem, but the fix is about Vector 2022, and the RevisionSlider does not in any design.

Clicking on the header of the revision slider can prevent it from taking up that much space.

Still a non-working feature better will not appear at all.

Feels like we're talking in circles :p It works in Hebrew for me

Yap. It just means there are some conditions to work and different ones not to work. I have a suspicion that it can depend on browser, but I can't approve or disapprove this, because I really don't know what happens inside the RevisionSlider, and how to debug it. If this is the problem, it works wrong at least in Samsung Internet, last version. But the condition must be something completely different either.

Hey all! Thanks a lot for the patience. We kept working on this the past months, one step at a time, and documented our findings in phab:T352169. The one remaining issue we have been able to reproduce on our machines is finally gone with the current MediaWiki release. Please let us know if it works for you as well.

Well, @Thiemo Kreuz (WMDE), I've checked now, on hewiki, and all the problems looks to be disappeared. On different skins. Don't know how it's possible, I never make more than 100% screen, but still. I'll try a couple more times in case in the next few weeks, to check if I've missed something, but I really hope that this time everything is fine.

Tracked in Phabricator
Task T352152

Hi, I've stumbled across this nice extension, but it seems like it does only work in Firefox.

When using Vivaldi (in a new private window) I can move the sliders but the pages shown / diff won't change.

I guess that must be known already, but maybe there could be a warning somewhere in the tutorial to curb expectations.

Thanks a lot for the report, that's super helpful! RevisionSlider is supposed to work the same in all browsers including Vivaldi. Can you possibly provide more information? Especially on which wiki this happens and which skin you are using?

I've just tested it again on the english Wikipedia with the article of the day.

No special skin, just the default.

To be sure that no extensions / addons are interfering, I used a new private window.

I can't post a direct link to a screenshot, but here you go

imgur dot com /a/CDjtNB8

And here is the popup for the yellow dot:

imgur dot com /a/4Eyl4fx

The popup on the yellow dot says: Date 3 November 2022, the revision shown under it says: Date 19 November 2022.

The blue dot is on the rev. from 20 Nov, which is correctly shown underneath. The next earliest revision is the one from 19th Nov which is shown on the left instead of the one that was selected with the yellow dot.

I have tried a few things:

In the Revision history, select two versions that are not directly in sequence and click "compare selected revs". Then open the slider. The two revisions will be shown correctly.

Now click on the lower half of the graphic to move only the yellow dot.

As a result, the yellow dot will move to the new position, but the blue dot will move right next to it. (Is this a bug or a feature? It's not intuitive to me.) Both the displayed revisions will be changed to the new dates.

If you instead drag the yellow dot, the blue dot will remain where it was. But dragging the yellow dot will not lead to a refresh of the revision shown underneath.

Dragging the blue dot seems to crash the RevisionSlider: the revision comparison disappears after some delay, and the article is shown instead (but the title says [Article Name]: Difference between revisions)

Checking on the German Wikipedia, I can't drag the blue dot at all with Vivaldi.

When I started with two not adjacent revisions, they were displayed correctly.

When dragging the yellow dot, the revision shown will change to the one that comes just before the one with the blue dot.

Unclear conflict with an experimental Firefox feature.

Hi. There is a button of revision slider, browse history, in mobile version, that does nothing. It's better to remove it, isn't it?

Can you please clarify what you mean when you say "mobile version"? I'm aware of several ways to get a mobile view:

• The "mobile view" link at the end of each page leads to the view small-screen devices like phones get by default. Example: https://de.m.wikipedia.org/wiki/Spezial:Mobiler_Unterschied/178162652. Revision slider is not active there. This is being worked on as part of phab:T165835.
• Users can use the same mobile skin on desktop. Example: https://de.wikipedia.org/w/?diff=178162652&useskin=minerva. RevisionSlider is active there and works, as far as I can tell.
• There are mobile apps for Android and iOS. RevisionSlider is not meant to work with these.

Maybe you experience the problems you describe on a specific device?

Reproduction steps:

1. Windows 7, last Quantum
2. Install Side view extension - allows to compare desktop and mobile versions side by side.
3. Open some diff page.
4. Click the side view button on browser address fiels, nearby the bookmarking star.
5. The mobile version of the same page appears in the side view

I found a gadget on the English Wikipedia thats called "Mobile sidebar preview" (source code). But I assume this is not what you mean. RevisionSlider works fine with this, as far as I can see. Are you talking about a browser extension? Which browser are you using, and where to find this extension?

Yes, like I said: I'm on Quantum. You can find it on .

Personally I'm happy to see the Mozilla folks working on a feature like this. But I honestly don't think it makes sense hunting bugs in an experimental Firefox feature that started just a few days ago, according to the page.

Let's talk in May?

This should now be deployed and thus fixed!

The mouse-over Info boxes partly hide i.e. the flagging-form. Please consider showing them beyond the slide, not above, because it might be easier to mouse-out.

Hi! by 'Info boxes' do you mean the tool tips that appear when you hover over a revision in the slider? These display the summary, user, date etc.

As a result of working on phab:T141071 the tool tips will be displayed underneath the slider.

This should be deployed to dewiki on Wednesday the 3rd of August!

This is right: so for example if you want to "sight" (is this the English word for "sichten" (de)?) an article, this is very irritating and it steals your time.