I think using sessionStorage isn't ideal (opening a link in a new tab, etc.) but it is better than what we have now. It might be a good to do that first and see if we need to implement a more complex solution later.

A "simple" alternative would be to make the pins force a page refresh (and update the token). But I don't think that's a great UX because I certainly wouldn't expect a button like that to refresh the page.

A more complex solution could be to create an Action API module to update the token. When the user pins a field, the state will be updated in the background and a new token will be pushed replaced in the user's address bar.

As far as I know, creating the Action API module is simple/straightforward, so it's not that complicated, but there are some pitfalls to be aware of. For instance, any links on the page (like next/previous links) will also need their tokens updated. Though we could have the Action API accept and return multiple tokens and we could mark the links that have tokens that need to be updated with a class or data attribute.

I imagine creating such a module would be helpful for other purposes as well (i.e. anytime we want to persist the state without forcing a page refresh).

Another option would be to update a hidden field with the highlight data, then submit via POST on clicking the pagination links. We're already using hidden fields and POST for the filter and add-target buttons.

In T246172#6098030, @Tchanders wrote:

Another option would be to update a hidden field with the highlight data, then submit via POST on clicking the pagination links. We're already using hidden fields and POST for the filter and add-target buttons.

Oh! that's not a bad idea. If I'm understanding this correctly it would defer the update, until they click the pagination links which would be taken over, but they would still result in a POST and then result in a redirect to to a page with the new-new token (i.e. one with the new page offset AND the pins)

Summary from our engineering meeting.

Behaviour of highlights

• Persistence across tabs: If a user pins a highlight on Preliminary Check, then navigates away to Timeline, then back to Preliminary Check, their highlight should still be there on Preliminary Check
• Persistence across pages: If a user pins a highlight for User1 on Preliminary Check page 1, then requests Preliminary Check page 2, any results for User1 should also be highlighted on page 2

Technical approaches

• We favoured two approaches: storing the pinned highlight data for each tab in session storage (T246172#5946084), and storing it in the token (T246172#6098030)
• We decided to go with session storage for now. We favoured session storage over local storage due to making it easier to clean up and easier to have different highlights in different browser tabs.

@aezell I double checked what I said about age/stability and sure enough both sessionStorage and localStorage have support all the way back to IE 8. IndexedDB isn't as well supported, but still supported in all modern browsers (not that we would need something that robust anyways).

I forgot that Cookies, even though they are added to every HTTP request, they do allow you to set an expiry time, which is rather nice.

@dbarratt Thanks for checking that. Interesting stuff.

Change 601726 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/CheckUser@master] Persist highlights across pages in Special:Investigate

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

Question perhaps for @Prtksxna.

At the moment, if you have a highlight pinned you can only unpin it by finding a highlighted cell and clicking the pin.

If highlights persist across pages, to unpin or pin something else you might have to go back to the page where you first set the pin.

Might there need to be another way to unset a pin or pin something else, from any page?

@Prtksxna If the user pins a highlight then clicks on "Next page", there's a small flicker between the table being displayed and the highlight being added.

Briefly, this is because the yellow highlighting is added when a certain class is present on a table cell; we store and retrieve the information about which cells to add this class to in sessionStorage; that is only available to the JavaScript, which runs after the table is already visible. (It is possible to hide the table until the JavaScript has run, but in some cases that could leave the user waiting for a long time to see the results, even when there is no highlight present.)

As long as the browser cache is enabled, the flicker is quite quick, so I suspect this may be bearable. If it's not bearable, we could store the info in the token and add the classes in PHP.

In T246172#6188716, @Tchanders wrote:

@Prtksxna If the user pins a highlight then clicks on "Next page", there's a small flicker between the table being displayed and the highlight being added.

Is it that first the table loads and then suddenly some rows become yellow? Or is the flicker more than that?

In T246172#6188702, @dom_walden wrote:

At the moment, if you have a highlight pinned you can only unpin it by finding a highlighted cell and clicking the pin.
If highlights persist across pages, to unpin or pin something else you might have to go back to the page where you first set the pin.

I hadn't thought about this use-case, thanks for finding it! Added T254424: Special:Investigate: Add a way to unpin a highlight when the highlighted rows aren't on the page

Is it that first the table loads and then suddenly some rows become yellow?

Yes

In T246172#6191417, @Tchanders wrote:

Is it that first the table loads and then suddenly some rows become yellow?

Yes

I think then the flicker is acceptable.

Do you think adding a transition: 300ms background-color ease; would help? I could add a separate task for this if you think it would.

Do you think adding a transition: 300ms background-color ease; would help? I could add a separate task for this if you think it would.

Yes, that does look less jarring. I can easily add it into this patch - thanks.

Change 601726 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Persist highlights across pages in Special:Investigate

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

The current value of the highlighting is stored in the browser's session storage, and persists across pages, tabs, adding/removing filters and adding users/IPs to investigation. It also persists if you start a new investigation, which is unexpected (I think) but might actually be useful.

This applies to the IP and UA in the Compare tab but also to the "Date Attached" and "Wiki" in the Preliminary tab.

Clicking the blue pin icon will remove the value from the storage.

If you have a highlight value in storage but there are no matching cells on the current page/tab, you can pin another cell (without unpinning the previous value). This will replace the current value in the session storage. This is perhaps one solution to the issue raised in T254424. @Prtksxna might want to check this out.

I am not exactly sure what range of characters the session storage will support. I found a weird UA string[1] online and tried pinning that. It appeared to be handled fine. I didn't test this very thoroughly.

I briefly tested that the right things were being highlighted. I had two tabs open with the same investigation, one tab had everything on one page and the other had multiple pages. I compared the highlighting on the single page with the same highlighting across multiple pages.

I tested this mainly on Firefox, but briefly tested on IE11 and iPhone 11 Safari.

It should be noted that pinning of highlights does not appear to be available on the mobile version of the site, but you can switch to the desktop version.

Ref

1. weird_ua.txt195 BDownload