@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

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

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 mw.storage (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 mw.storage for non-bfcache-enabled browsers. The data we want *is* being stored in history, but *is not* being stored in mw.storage, 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 mw.storage

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

Change 724511 merged by jenkins-bot:

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

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