Closed Bug 1972600 Opened 2 months ago Closed 2 months ago

Spoof network status for media element

Categories

(Core :: Privacy: Anti-Tracking, enhancement)

Product:
Core
Component:
Privacy: Anti-Tracking
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
142 Branch
Tracking Flags:
Tracking Status
firefox-esr140 --- fixed
firefox142 --- fixed

People

(Reporter: fkilic, Assigned: fkilic)

References

Details

Attachments

(2 files)

Bug 1972600 - Spoof network connection for HTMLMediaElement preload. r?tjr
48 bytes, text/x-phabricator-request
Details | Review
Bug 1972600 - Spoof network connection for HTMLMediaElement preload. r?tjr
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-esr140+
Details | Review

Creating a new bug to move conversation about RFP from bug 1969210 and attach a patch.

but how do we measure the loading behavior? We/TZP still needs to check all methods of obtaining a value. thx

I think this is hard to achieve on client side and without consuming bandwidth. AFAICT, if you use auto instead of metadata, we load "more" video (around 2mb if the video is not playing, but it could be dependent on video's size/length ratio, I don't know).

I tried

<html>
<body>

<video width="320" height="240" id="my_video" controls preload="metadata">
  <source src="big_buck_bunny_360p_30mb.mp4" type="video/mp4">
</video>

<script>
  const videoElement = document.getElementById("my_video");
  videoElement.addEventListener('loadeddata', (e) => {
    console.log(videoElement.readyState);
  });
</script>

</body>
</html>

and I still got HTMLMediaElement.HAVE_ENOUGH_DATA (4), so I'm not sure if it is possible to only get HTMLMediaElement.HAVE_METADATA (1).

(there's also loadedmetadata event but this is just to show I was never able to ONLY load the metadata, firefox always loaded some data)

preload="none" will behave differently.

The behavior with "metadata" depends on network speed and response size.
This can be controlled client side with a ServiceWorker.
readyState could currently be HAVE_CURRENT_DATA, HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA in the situation of comment 1.

If bug 1969224 were fixed, HAVE_FUTURE_DATA would not happen.
There are other reasons to skip HAVE_CURRENT_DATA too.

See Also: → 1967092

https://hg.mozilla.org/mozilla-central/rev/de2e57b5f0b8

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
status-firefox142: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 142 Branch
Attachment #9498406 - Flags: approval-mozilla-esr140?

firefox-esr140 Uplift Approval Request

  • User impact if declined: Only affects "Resist Fingerprinting" users' UX. Firefox doesn't support this configuration. We are requesting the uplift for Tor Browser.
  • Code covered by automated testing: yes
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: Set media.preload.default.cellular, media.preload.default, media.preload.auto.cellular, media.preload.auto to 1. Load any media element with preload="auto" and make sure loadeddata event is fired. Do the same for no preload attribute.
  • Risk associated with taking this patch: None
  • Explanation of risk level: N/A
  • String changes made/needed: No
  • Is Android affected?: yes
Attachment #9498406 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+
QA Whiteboard: [qa-triage-done-c142/b141]
QA Whiteboard: [qa-triage-done-c142/b141] → [qa-triage-done-c143/b142]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: