Page MenuHomePhabricator

[commons-wmf.23] MediaSearch: after navigation back from a file page the search results do not match displayed filter selection
Closed, ResolvedPublic


Found when testing

This bug is about displaying correct search results without showing user selected criteria after returning from a file page.

  1. On Special:MediaSearch with default active Image tab selected, enter any search criteria - e.g. "Yellow tulips" (with no quotes). The number of search results is 1,034 (

Screen Shot 2021-09-17 at 11.12.59 AM.png (1×2 px, 1 MB)

  1. Select some criteria, e.g. in the screenshot below - "All licenses" - No restrictions, "All file types" - jpg, "All image sizes" - Medium ( - the number of results is 29.

Screen Shot 2021-09-17 at 11.29.55 AM.png (531×1 px, 1 MB)

  1. Go to Categories and Pages (or any other filter tab). Select any namespace - e.g. Discussion.
  2. Click on one of the file links and, after viewing a file, click the browser button to return back.

The search criteria selected for Categories and Pages - Discussion namespace is preserved, so the page state is restored.
Go to the Image tab - the results are restored, but the search criteria are not displayed. The url shows no search criteria -

Screen Shot 2021-09-17 at 11.39.33 AM.png (1×3 px, 2 MB)

Event Timeline

Etonkovidova renamed this task from [commons-wmf.23] MediaSearch: after navigation back from a file page the search results do not match the displayed filter selection to [commons-wmf.23] MediaSearch: after navigation back from a file page the search results do not match displayed filter selection.Sep 17 2021, 6:53 PM

@Etonkovidova I just went through the steps to reproduce this bug (thanks for the thorough description).

Using Firefox on production Commons, I saw the correct behavior in this scenario (on Monday, 9/27):

  • set some image search filters
  • switch to the Categories & Pages tab
  • Update the "namespace" filter
  • Click on one of the Page results, go to the page
  • Click "back" –-> see the "namespace" filter is still active & results are correct
  • Click the "Images" tab --> previously-set image filters still active, active filters properly highlighted

Screen Shot 2021-09-27 at 2.58.12 PM.png (762×2 px, 1 MB)

However, using Chrome, the behavior is as you describe (filtered results, but no indication that filters are active):

Screen Shot 2021-09-27 at 3.02.11 PM.png (766×2 px, 1 MB)

The fact that this bug is present on Chrome but not on Firefox made me think it might be connected to whether or not a back/forward cache is used; Firefox uses a bfcache while Chrome (by default) does not. This is a browser feature that preserves the entire in-memory "application" of a page in history, not just the HTML from the server.

However, you can enable bfcache on Chrome with a feature-flag (chrome://flags/#back-forward-cache). I did this in Chrome 94 on Mac but the bug persists. So I'm not 100% confident this is the cause.

Other things that could be related here are (we rely on it here) and T284021 (last time we made significant changes to how history is handled).

Update on this: In Chrome with bfcache enabled, I see correct behavior when I do the following:

  • set some image search filters
  • switch to categories & pages tab
  • update the namespace filter
  • click on a Page result, departing Special:MediaSearch
  • use "back" to return to the page results
  • use "back" to return to the earlier image search tab

In that case, the filter controls are all set correctly and the results accurately reflect that.

Previously I was only using "Back" to navigate to the Categories & Pages tab; after that I returned to the Image tab by clicking on it normally. This adds a new entry in the history stack, we're "moving forward" in history here. When just moving backwards through history normally, everything works correctly.

Here's what I think may be happening:

When the user switches between tabs in the MediaSearch UI, we hang on to the results, filters, etc. in inactive tabs in memory in case the user wants to switch back. Most of these things live in the Vuex store of the application. We also store these different views as separate items in the history stack (changing URL parameters as the user moves around and changes things).

In a browser like Firefox that uses a true back/forward cache, the in-memory state of the application is preserved when the user navigates away from Special:Mediasearch, and is immediately restored when they return here using "back". This means that on Firefox (or Safari), the user will see correctly-preserved state in the Images tab regardless of whether they return there from Categories & Pages via clicking the tab (forward-navigating) or hitting "back" (back-navigating).

But on Chrome, which doesn't fully implement the bfcache feature, there is a discrepancy. The full in-memory state of the MediaSearch application is not perfectly preserved when the user navigates away from the page. Users who navigate back through their history will see the correct filter settings if they drill all the way back to the Images tab via the history stack, but they won't see the correct settings if they just navigate back to the first Special:MediaSearch view they see and then click over to the Images tab normally.

This probably is the result from us not storing the filter data correctly in for non-bfcache-enabled browsers. The data we want *is* being stored in history, but *is not* being stored in, essentially.

Change 724511 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/extensions/MediaSearch@master] Ensure that filter state is stashed in

Change 724511 merged by jenkins-bot:

[mediawiki/extensions/MediaSearch@master] Ensure that filter state is stashed in

Thank you @egardner for the explanation in!

On commons wmf.3 I checked FF and Chrome - the fix is working.