Closed Bug 1400140 Opened 7 years ago Closed 1 year ago

Make window.content chrome-only

Categories

(Core :: DOM: Core & HTML, enhancement, P3)

Product:
Core
Component:
DOM: Core & HTML
Version:
53 Branch
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
117 Branch
Tracking Flags:
Tracking Status
firefox117 --- fixed

People

(Reporter: bzbarsky, Assigned: gregp)

References

(Blocks 1 open bug)

Details

(Keywords: site-compat)

Attachments

(1 file, 2 obsolete files)

Bug 1400140 - Make window.content chrome-only, remove dom.window.content.untrusted.enabled r?saschanaz!
(deleted), text/x-phabricator-request
Details 
This is a followup to bug 864845, once we gather some data in bug 1400139.
Priority: -- → P3
MozReview-Commit-ID: LFMK7lxs46Z
Attachment #8908948 - Flags: review?(michael)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #8908948 - Attachment is obsolete: true
Attachment #8908948 - Flags: review?(michael)
Assignee: bzbarsky → nobody
Status: ASSIGNED → NEW
Component: DOM → DOM: Core & HTML

Telemetry says currently only 0.08% of pages use this method: https://telemetry.mozilla.org/new-pipeline/dist.html#!measure=USE_COUNTER2_DEPRECATED_WindowContentUntrusted_PAGE&max_channel_version=beta%252F76 Since this has been disabled in Nightly for more than two years and there has been no relevant regression report so far, it's time to try disabling this on stable Firefox.

Assignee: nobody → krosylight
Status: NEW → ASSIGNED

It’s not a good time to ship this. Because of the COVID-19 pandemic, any breaking changes are being reviewed on Slack and avoided. 0.08% is not really a small number.

Ah, understood.

Then I'll modify the patch to only introduce the flag without actually disabling it, does this sound good?

Flags: needinfo?(emilio)

Sure, sounds fine.

Flags: needinfo?(emilio)

It's probably also fine to disable it on Nightly. That way we catch potential fallout sooner.

It's probably also fine to disable it on Nightly.

It's already disabled in Nightly via preprecessor. IMO it's cleaner to disable it by a flag, though.

Comment on attachment 9142077 [details]
Bug 1400140 - Put window.content behind dom.window.content.enabled

Revision D71775 was moved to bug 1632116. Setting attachment 9142077 [details] to obsolete.

Attachment #9142077 - Attachment is obsolete: true

How about disabling it in the early beta channel as well if a new flag is introduced this time? @IS_EARLY_BETA_OR_EARLIER@ is often used.

That sounds good, as early beta users know breakages can happen.

Assignee: krosylight → nobody
Status: ASSIGNED → NEW
Severity: normal → S3

dom.window.content.untrusted.enabled = false since FF101 via Bug 1764339, maybe time to remove the pref/code?

Assignee: nobody → gp3033
Status: NEW → ASSIGNED
Pushed by gp3033@protonmail.com:
https://hg.mozilla.org/integration/autoland/rev/3177eee3a850
Make window.content chrome-only, remove dom.window.content.untrusted.enabled r=saschanaz,webidl,smaug

https://hg.mozilla.org/mozilla-central/rev/3177eee3a850

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox117: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 117 Branch

Is this something we should call out in the Fx117 relnotes?

Flags: needinfo?(gp3033)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #17)

Is this something we should call out in the Fx117 relnotes?

Probably not. For untrusted content, window.content is (was) an alias for window.top, it's also been unavailable to web content for about a year, so this change didn't really change the behavior much.

Flags: needinfo?(gp3033)

As this isn't needed to be called out in the release notes, I'm removing the dev-doc-needed keyword - feel free to re-apply if anyone thinks necessary

Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: