www.ozon.ru - Review videos are not playing
Categories
(Web Compatibility :: Site Reports, defect, P2)
Tracking
(Webcompat Priority:P3, Webcompat Score:3, firefox-esr115 unaffected, firefox-esr140 fix-optional, firefox149 wontfix, firefox150 wontfix, firefox151 wontfix, firefox152 wontfix, firefox153 fixed)
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr140 | --- | fix-optional |
| firefox149 | --- | wontfix |
| firefox150 | --- | wontfix |
| firefox151 | --- | wontfix |
| firefox152 | --- | wontfix |
| firefox153 | --- | fixed |
People
(Reporter: rbucata, Assigned: ltenenbaum)
References
(Regression, )
Details
(5 keywords, Whiteboard: [webcompat-source:web-bugs][webcompat:sightline][webcompat:core])
User Story
platform:android impact:feature-broken configuration:general affects:all branch:release diagnosis-team:networking user-impact-score:45
Attachments
(2 files)
Environment:
Operating system: Android 16
Firefox version: Firefox Mobile 149.0
Steps to reproduce:
- Navigate to: https://www.ozon.ru/product/tochilka-dlya-nozhey-i-nozhnits-elektricheskaya-besprovodnaya-2705059921/reviews/?itemId=2705059921
- Click on the "Play" button from a video and observe
Expected Behavior:
A player is triggered and the video plays
Actual Behavior:
Nothing happens
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/216192
| Reporter | ||
Comment 1•4 months ago
|
||
| Reporter | ||
Updated•4 months ago
|
Comment 2•4 months ago
|
||
Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.
Updated•4 months ago
|
Comment 3•4 months ago
|
||
We've previously had bug 1901691, but couldn't reproduce. This time, though, I can reproduce - it seems like it's not responding to any touch events, not even the toggle thingie in the top.
It works if I spoof as Chrome?!
Updated•4 months ago
|
Comment 4•4 months ago
|
||
(In reply to Dennis Schubert [:denschub] from comment #3)
We've previously had bug 1901691, but couldn't reproduce. This time, though, I can reproduce - it seems like it's not responding to any touch events, not even the toggle thingie in the top.
It works if I spoof as Chrome?!
Also, enabling "Desktop site => on" (will obviously show different site) but then input starts working.
Comment 5•3 months ago
|
||
It might be worth doing a bit of investigation to figure out what is happening differently depending on the UA sniffing
Comment 6•3 months ago
|
||
On android nightly, I can reproduce, but I also see a content difference - when spoofing I get a gallery near the top of video thumbnails; when as firefox I don't get that gallery
Comment 7•3 months ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)
It might be worth doing a bit of investigation to figure out what is happening differently depending on the UA sniffing
Hi Leo, care to give another deeper look at this? Thank you.
| Assignee | ||
Comment 8•3 months ago
|
||
Also reproduces on Firefox Desktop with a Firefox Android user agent, but interestingly not Chrome with the same user agent. Difference seems to be that the click event listener is not being set on the video preview. I'll look at this more tomorrow
| Assignee | ||
Comment 9•3 months ago
|
||
Okay it does seem to just be an issue with the HTML that the server is returning (the <div data-widget="webToAppBanner"> is replaced with a comment which screws up Vue hydration). The reason it's not broken on Chrome with a Firefox Android UA is that the Accept header includes image types. Either setting network.http.accept_include_images = true or using a Chrome UA fixes the problem. Probably it's easiest to just override the UA with a webcompat intervention.
Comment 10•3 months ago
|
||
Set release status flags based on info from the regressing bug 1917177
:valentin, since you are the author of the regressor, bug 1917177, could you take a look?
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Comment 11•3 months ago
|
||
Either setting network.http.accept_include_images = true or using a Chrome UA fixes the problem. Probably it's easiest to just override the UA with a webcompat intervention.
This is quite weird. That means the website specifically chooses the wrong behaviour for Firefox?
We have considered reverting bug 1917177, but we're waiting on https://github.com/whatwg/fetch/issues/274 to be resolved to avoid flip-flopping again in the future. If this is becoming a much bigger webcompat issue we could definitely ship it as a fix.
Probably it's easiest to just override the UA with a webcompat intervention.
I agree.
| Assignee | ||
Comment 12•3 months ago
|
||
Updated•3 months ago
|
Comment 13•3 months ago
|
||
Comment 14•3 months ago
|
||
| bugherder | ||
Comment 15•3 months ago
|
||
The patch landed in nightly and beta is affected.
:ltenenbaum, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
- If no, please set
status-firefox152towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•3 months ago
|
Comment 16•2 months ago
|
||
Oops, this was meant to be kept open for tracking.
Updated•2 months ago
|
Description
•