Open Bug 2031974 Opened 4 months ago Updated 26 days ago

www.ozon.ru - Review videos are not playing

Categories

(Web Compatibility :: Site Reports, defect, P2)

ARM
Android

Tracking

(Webcompat Priority:P3, Webcompat Score:3, firefox-esr115 unaffected, firefox-esr140 fix-optional, firefox149 wontfix, firefox150 wontfix, firefox151 wontfix, firefox152 wontfix, firefox153 fixed)

REOPENED
153 Branch
Webcompat Priority P3
Webcompat Score 3
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:

  1. Navigate to: https://www.ozon.ru/product/tochilka-dlya-nozhey-i-nozhnits-elektricheskaya-besprovodnaya-2705059921/reviews/?itemId=2705059921
  2. 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

Attached video chr vs ff 147 android

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Whiteboard: [webcompat-source:web-bugs] → [webcompat-source:web-bugs][webcompat:sightline][webcompat:core]

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?!

Severity: -- → S3
User Story: (updated)
Webcompat Priority: --- → P2
Webcompat Score: --- → 6
Priority: -- → P2
User Story: (updated)

(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.

User Story: (updated)

It might be worth doing a bit of investigation to figure out what is happening differently depending on the UA sniffing

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

(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.

Flags: needinfo?(ltenenbaum)

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

Flags: needinfo?(ltenenbaum)

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.

Keywords: regression
Regressed by: 1917177

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.

Flags: needinfo?(valentin.gosu)
Flags: needinfo?(valentin.gosu)

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: nobody → ltenenbaum
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 153 Branch

The patch landed in nightly and beta is affected.
:ltenenbaum, is this bug important enough to require an uplift?

For more information, please visit BugBot documentation.

Flags: needinfo?(ltenenbaum)

Oops, this was meant to be kept open for tracking.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
User Story: (updated)
Webcompat Priority: P2 → P3
Webcompat Score: 6 → 3
See Also: → 2056835
Duplicate of this bug: 2056835
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: