Closed Bug 1558866 Opened 1 year ago Closed 1 year ago

Change about page blocking to block specific Chrome URLS

Categories

(Firefox :: Enterprise Policies, defect, P3)

63 Branch
Unspecified
Windows 10
defect

Tracking

()

VERIFIED FIXED
Firefox 70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- verified
firefox68 --- wontfix
firefox69 --- verified
firefox70 --- verified

People

(Reporter: yfdyh000, Assigned: mkaply)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Steps to reproduce:

  1. Add the
    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Mozilla\Firefox]
    "DisableTelemetry"=dword:00000001
  1. Open an Firefox 32bit.
  2. Try to opening the 'chrome://browser/content/places/places.xul' page in tabs.

Actual results:

  1. The tab(s) becomes a blank page or remains loading.

Expected results:

  1. As usual, open normally. No effect on the "telemetry" outside.

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e738c5c8f5e2403b4708dc03d8079b84829fa212&tochange=7ba0b2abe799e6d8ed23e17e5b865d99811c5c6e

Why are you trying to load chrome://browser/content/places/places.xul in a tab?

(In reply to Mike Kaply [:mkaply] from comment #1)

Why are you trying to load chrome://browser/content/places/places.xul in a tab?

Some fans like to open Library in tab instead of window or sidebar.

Has Regression Range: --- → yes
Has STR: --- → yes

The issue is that currently when we block an about page, we block all chrome URLs so we didn't have to do one offs for all the about pages.

https://searchfox.org/mozilla-central/source/browser/components/enterprisepolicies/Policies.jsm#1403

We'll need to change that.

Status: NEW → RESOLVED
Closed: 1 year ago
Priority: -- → P3
Resolution: --- → WONTFIX
Summary: DisableTelemetry prevent loading the 'chrome://browser/content/places/places.xul' in tabs → Change about page blocking to block specific Chrome URLS

I did not mean to WONTFIX This.

Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: nobody → mozilla
Status: REOPENED → ASSIGNED

Mike, are you planning on landing this patch soon? It has r+.

Flags: needinfo?(mozilla)
Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/99a149a24c4e
Use a list of chrome URLs to block. r=jaws,Gijs
Status: ASSIGNED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70

Is this something we should consider for backport?

Comment on attachment 9072001 [details]
Bug 1558866 - Use a list of chrome URLs to block.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Makes policy code work better.
  • User impact if declined: More chrome URLs are blocked than necessary.
  • Fix Landed on Version: 69
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Policy only.
  • String or UUID changes made by this patch:
Flags: needinfo?(mozilla)
Attachment #9072001 - Flags: approval-mozilla-esr68?

Comment on attachment 9072001 [details]
Bug 1558866 - Use a list of chrome URLs to block.

Beta/Release Uplift Approval Request

  • User impact if declined: More pages are blocked by policy than necessary.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Lock about config via policy. Verify you can still go to chrome://browser/content/places/places.xul'
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Policy only.
  • String changes made/needed:
Attachment #9072001 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9072001 [details]
Bug 1558866 - Use a list of chrome URLs to block.

Be a little more careful about which chrome URLs we block. Approved for 69.0b9 and 68.1esr.

Attachment #9072001 - Flags: approval-mozilla-esr68?
Attachment #9072001 - Flags: approval-mozilla-esr68+
Attachment #9072001 - Flags: approval-mozilla-beta?
Attachment #9072001 - Flags: approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

I successfully reproduced the issue on Firefox 68.0.1 (x32) under Windows 10 (x64) using the STR from Comment 0.

The issue is no longer reproducible on latest Nightly 70.0a1 x32 (2019-07-28), on Firefox 69.0b9 x32 (20190727022937 Treeherder build) and 68.1.0esr x32 (20190726232722 Treeherder build) under Windows 10 (x64).

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.