| SimoneThisDot | |
| Sep 27 2022, 7:46 PM |
| F35839488: search_scroll3.gif | |
| Dec 6 2022, 3:01 AM |
| F35839476: search_scroll2.gif | |
| Dec 6 2022, 3:01 AM |
| F35747892: first_second_results3.gif | |
| Nov 10 2022, 10:17 PM |
| F35746882: first_second_results2.gif | |
| Nov 10 2022, 10:17 PM |
Steps to replicate the issue (include links if applicable):
What happens?:
What should have happened instead?:
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Always autoscroll the page to the first result | mediawiki/extensions/SearchVue | master | +3 -2 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T307038 [Placeholder EPIC] SDAW Search Improvements | |||
| Resolved | None | T306341 [EPIC] Quickview/Search Preview panel on the special:search page | |||
| Resolved | BUG REPORT | SimoneThisDot | T318748 SearchVue - Always autoscroll the page to the first result |
Change 835684 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):
[mediawiki/extensions/SearchVue@master] Always autoscroll the page to the first result
@SimoneThisDot: Assuming this task is about the SearchVue code base, hence adding that project tag so other people who don't know or don't care about team tags can also find this task when searching via projects. Please set appropriate project tags when possible. Thanks!
Change 835684 merged by jenkins-bot:
[mediawiki/extensions/SearchVue@master] Always autoscroll the page to the first result
For @Sneha quick review. If there is no follow-ups, you may move to Verify in Production.
Adding the gif ( enwiki betlabs; the fix is in place) showing the steps in the description
- search for a term with multiple result
- click on the second result
(1) as in the description above - at the top of search results
(2) click search results at the bottom of the page
(3) the case when a user clicks on article snippet at the top (for QuickView), then scrolls down, and clicks on an article snippet at the bottom, was filed as a bug - T322886: Search improvements - not closed QuickView disregards article snippet position. It's a relatively minor issue since it happens only when a user scroll down and attempts to display the QuickView without closing the QuickView for the previous article.
I am not sure if I understand this bug clearly. There are some issues with the way quick view is shown i.e. it is not relative to the position of the snippet. But I am assuming this bug is a different issue. Also in the first gif I am not sure if the scrolling is happening automatically or you are manually scrolling it.
I re-read my comment and realized that it didn't illustrate the fix correctly. Basically, what was fixed - the QuickView is aligned with the clicked snippet and the page is not scrolled.
Below is another gif (the page is not scrolling):
Viewing QuickView for the articles from the bottom of the page has a bug which was filed. The bug is - if a user clicks for QuickView from the bottom of the page , the Quickview will be moving up.
Hi @Etonkovidova this bug may not be valid anymore as the way quick view works is updated to have a fixed position. See this ticket T324278
Agree. I reviewed T324278 - yes, it makes sense to close this task. Closing it as Resolved rather than invalid, since there was a change in feature behavior and the overall issue with autoscrolling was, in fact, resolved.