Closed Bug 1428302 Opened 7 years ago Closed 1 year ago

Remove window.sidebar

Categories

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

task

Tracking

()

RESOLVED FIXED
119 Branch
Tracking Status
firefox119 --- fixed

People

(Reporter: bruant.d, Assigned: gregp)

References

(Blocks 3 open bugs)

Details

(Keywords: dev-doc-complete, site-compat, webcompat:platform-bug)

Attachments

(1 file)

Rising from the ashes of bug 862147, the return of window.sidebar > Telemetry data shows that window.sidebar is accessed by about 1.62% of page loads, that's too high to remove. https://bugzilla.mozilla.org/show_bug.cgi?id=862147#c47 Standard discussion: https://github.com/whatwg/html/issues/3325
Priority: -- → P3
Depends on: 1503551
Component: DOM → DOM: Core & HTML
Type: enhancement → task
Depends on: 1632448, 1632447

Telemtry still seems to show a relative high rate of access to this property: https://mzl.la/32GgRiQ. Probably some kind of browser detection. Should we try removing it Nightly?

Yeah, putting this behind a preference and disabling it on Nightly/early Beta sounds good.

Summary: Remove or standardize window.sidebar → Remove window.sidebar
No longer blocks: stdglobal

It's not safe to remove window.sidebar at all. Yeah, this is used for browser detection, as always on Browserhacks, which explains its high internet usage. It is clear that if we remove that, a lot of sites will break.

Webcompat Priority: --- → ?
Depends on: 1768345

(In reply to janestrapper from comment #4)

It's not safe to remove window.sidebar at all. Yeah, this is used for browser detection, as always on Browserhacks, which explains its high internet usage. It is clear that if we remove that, a lot of sites will break.

Citation needed. Browserhacks mentions a lot of hacks that are not up-to-date anymore (like appearance or moz-tree-row-based hacks). Looking at telemetry it seems like usage is ~0, and we've gotten no issues reported in 11 months. Kagami, do you think we should proceed?

Flags: needinfo?(krosylight)

Hmm, I lie, it's more like ~0.5% (link) which is non-trivial. Then again if usages are like the ones in bug 1768345 (causing compat issues rather than fixing them) maybe it's worth a try. It's been disabled for 11 months on Nightly / early-beta after all.

Agreed, I believe many of existing browser detection cases are now invalid. I'll write a patch to disable it.

Flags: needinfo?(krosylight)

We will be monitoring for site breakage here, as there are signs that it might be bad to both keep or remove sidebar, from a webcompat perspective. But for now, we'll unset the webcompat priority flag on this bug until we have more info.

Webcompat Priority: ? → ---
Severity: normal → S3
Blocks: old-prefs
Assignee: nobody → gregp
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 119 Branch
No longer depends on: 1768345

FF119 docs work for this can be tracked in https://github.com/mdn/content/issues/29306. Note that compatibility shows the removal in 102 when the feature was disabled behind a flag (that's how things are done when preferences are removed at end of feature life)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: