forum.dudu-auto.com - The in-page search “Find in page” closes unexpectedly while the user is typing
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(Webcompat Priority:P3, Webcompat Score:3, firefox147 affected)
| Tracking | Status | |
|---|---|---|
| firefox147 | --- | affected |
People
(Reporter: bfarkas, Unassigned)
References
()
Details
(Keywords: webcompat:needs-diagnosis, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs])
User Story
user-impact-score:30 platform:android impact:feature-broken configuration:general affects:all branch:release diagnosis-team:android
Attachments
(1 file)
|
2.21 MB,
video/mp4
|
Details |
Environment:
Operating system: Android 16
Firefox version: Firefox Nightly 147.0a1 Build #2016130687
Steps to reproduce:
- Access: https://forum.dudu-auto.com/d/1250-introducing-duduos-36-beta4-250421-elevating-your-driving-experience/10
- Select Browser Menu
- Tap on "Find in page" option
- Try to type "checksum verification"
Expected Behavior:
The correct search results are returned
Actual Behavior:
The text box unexpectedly closes while typing
Notes:
- Reproduces regardless of the status of ETP
- Reproduces in firefox-nightly, and firefox-release
- Does not reproduce in chrome
Created from https://github.com/webcompat/web-bugs/issues/192807
|
Reporter | |
Updated•5 months ago
|
|
|
Reporter | |
Comment 1•5 months ago
|
||
|
||
Comment 2•5 months ago
|
||
This might be bug 1998404. Let's wait for this patch to land and re-confirm on Wednesday.
|
||
Updated•5 months ago
|
|
|
||
Comment 3•5 months ago
|
||
Seems to still be broken in today's Fenix Nightly, sadly. :petru, any ideas? :)
|
|
||
Updated•5 months ago
|
|
||
Comment 4•5 months ago
|
||
Seems like this website is not using url fragments but rather different paths for the particular post in the list.
Eg: we start with
then when GeckoView is scrolled to a particular post in that page (which contains the searched for text) the URL changes to
Which is a different URL so we abort the "find in page" UX.
We could try to avoid the last URL path containing just numbers from being considered a new URL but this avoids just a specific scenario, not all scenarios in which websites would use different URL paths for content in what seems the same page.
So this looks more like a real webcompat issue to me - paths are expected to be considered for new URLs - new pages and the find in page feature should not continue on different pages.
I see though that Chrome doesn't have this issue so maybe we can follow their logic.
Description
•