Page MenuHomePhabricator

Back button doesn't work as expected on Media Search
Closed, ResolvedPublicBUG REPORT

Description

We have this: The page doesn't reload between searches, so the back button doesn't work as expected on Media Search. If the user clicks the back button, they leave the search page and lose all their search history for the current session.

We want this: The back button should work to take the user to a previously conducted search. If the user clicks the back button after conducting a search, they should be taken to their previous search (or empty search, if it's their first search), and shouldn't lose their search history for the current session.

During development, please test the following:

  • Test this feature while logged in AND logged out
  • Test this feature on at least one mobile browser
QA Notes

This patch should be live on Wednesday of next week (August 19) assuming the train goes out normally.

During testing, check for the following behavior:

  • If the user searches for a series of different terms ("Aardvark", "Bear", "Cat", "Dog"), then they should be able to use the browser's forward and back buttons to move back and forth in order ("Dog" back to "Cat" back to "Bear" etc).
  • Each time the user moves forward or backwards in the history, the following things should happen:
    1. The URL params should update to reflect the query (specifically, the "q" params should change here)
    2. The search text in the input box should change to reflect the correct term (it should match the URL "q" param at all times)
    3. Moving forward or backwards in history to a different search term should clear existing results, show a pending state, and then load the first batch of results for the current term (should match the URL's "q" params at all times); additional pages loaded via scrolling will have to be re-loaded normally
  • Moving back and forth between tabs should be recorded in the history the same way that adding new terms is; if the user searches for a given term ("Aardvark") and starts at the "Images" tab (the default), and moves across to Audio, Video, and Categories, then they should be able to use the forward/back buttons to return to the previous tabs in correct order. The URL "type" params should remain in sync at all times
  • Moving between tabs using history navigation should trigger the loading of new results if available the same way that manually clicking between tabs does
  • Clearing the results should be registered as a new history entry in the correct order, and the user should be able to navigate back to any "cleared" state just like they would for any other query
  • The initial state of the page (including any query parameters present when the JS initializes) should be accessible through history navigation just like all subsequent states

Event Timeline

CBogen created this task.Aug 12 2020, 5:07 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 12 2020, 5:07 PM

Moving this to Alpha because I think it's better to get the fundamental behavior here working correctly now. Will have a patch up shortly.

egardner updated the task description. (Show Details)Aug 13 2020, 7:52 PM
Etonkovidova added a subscriber: Etonkovidova.EditedAug 20 2020, 12:29 AM

For @egardner to review.
Checked on commons wmf.5 - there is some quirky behavior that I tried to describe below.

The browser button (back/forward) behavior depends on how search inputs are cleared - manually with the backspace/delete button on the keyboard or with 'x' in the search box.
I used the search terms you've provided in the description - "Aardvark", "Bear", "Cat", "Dog", entering them one by one(typing) and click 'Search' after entering them

Entered search items
empty state -Aardvark --->Bear --->Cat --->Dog

(1) Search items are cleared manually with the backspace/delete button on the keyboard

  • type "Aardvark" (without quotes)
  • click 'Search'
  • click in the Search box at the end of "Aardvark"
  • using the backspace/delete on the computer keyboard delete "Aardvark"
  • enter "Bear" (without quotes)
  • click 'Search'

Browser back button from the search results for "Dog":

ExpectedDog --->Cat --->Bear --->Aardvark --->empty state
ActualDog --->Cat ---> Bear displayed in the Search field and in the url, but the fetched results are for Cat --->results are for Bear, the Search field displays Aardvark --->empty search in the Search field, the results are for Aardvark

(click to animate the gif); look at the url; the last click on back button brings the landing page, not the empty search screen

Browser forward button from the search results for empty state:

Expectedempty state --->Aardvark --->Bear ---> Cat--->Dog
Actualempty state--->Aardvark --->Bear ---> Cat--->Cat results displayed; Dog is in the Search box

Note:

Entered search items
empty state -Aardvark --->Bear --->Cat --->Dog

(2) Search items are cleared via 'x' - going back will display empty Search box intermittently.

Steps:

  • type "Aardvark" (without quotes)
  • click 'Search'
  • click 'x' to remove "Aardvark"
  • enter "Bear" (without quotes)
  • click 'Search'

Browser back button from the search results for "Dog":

ExpectedDog --->Cat --->Bear --->Aardvark --->empty state
ActualDog--->still Dog results displays, but the Search box displays an empty state--->Cat--->still Cat results displays, but the Search box displays an empty state--->etc

the empty state in the Search box has url - https://commons.wikimedia.org/wiki/Special:MediaSearch?type=bitmap&q=
Note that the initial empty search page becomes unreachable with the Back button.
(click on the animated gif)

I think the quirky behavior was the result of two things:

  1. I was not properly recording the results of the user clicking the "X" button in the history (whatever search results were there previously were not getting removed)
  2. I was not properly recording the initial query params the user may have landed on the page with so that they could be restored later if the user navigated back to them

I can open a patch to fix this behavior shortly. @Etonkovidova once that patch lands (on either Beta or Production), please try to walk through the same scenario again and let me know if things work as expected. It will probably be helpful to totally clear your browser history before testing so that previous data doesn't interfere. Thanks for carefully reviewing this, this behavior really requires it!

Also, I'm making the assumption here that we want every new "clear results" state to be recorded in the history just like any other search query. So if the user searches:
"Aardvark" ---> (clears results ) ---> "Bear" ---> (clears results again), then hitting the back button should take them to the following states:
Starting at no results, clicking back ---> Bear results ---> no results ---> Aardvark results

Change 621566 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] History behavior follow-up

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

egardner updated the task description. (Show Details)Aug 20 2020, 6:56 PM

Change 621566 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] History behavior follow-up

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

Etonkovidova updated the task description. (Show Details)Aug 21 2020, 9:27 PM

Thanks, @egardner!

Re-checking:
The first case - is Fixed.

(1) Search items are cleared manually with the backspace/delete button on the keyboard

The second case - seems to work according to the spec. However, I marked the spec with for probably being worth re-evaluating.
There are two specs regarding that specific behavior

We want this: The back button should work to take the user to a previously conducted search.

and

Clearing the results should be registered as a new history entry in the correct order, and the user should be able to navigate back to any "cleared" state just like they would for any other query

Clearing search search items (with 'x') might not be viewed as a completed (conducted) search request from the user point of view (the 'Search' button was not clicked). Clicking browser Back button should present pages with search results for search requests which users actually submitted (clicked 'Search').

The current behavior is as per @egardner 's comment:

Also, I'm making the assumption here that we want every new "clear results" state to be recorded in the history just like any other search query. So if the user searches:
"Aardvark" ---> (clears results ) ---> "Bear" ---> (clears results again), then hitting the back button should take them to the following states:
Starting at no results, clicking back ---> Bear results ---> no results ---> Aardvark results

Etonkovidova closed this task as Resolved.Aug 26 2020, 10:15 PM

Checked on commons wmf.6 -works according to the specs.

I added a note to T261032: [S] MediaSearch - clearing search items should keep cursor focused in the search field - about clearing search items resulting in clearing also the fetched search results.