Change enterprise policy that sets homepage to set it as the default rather than the user value for the pref

RESOLVED FIXED in Firefox 60

Status

()

defect
RESOLVED FIXED
Last year
Last year

People

(Reporter: bytesized, Assigned: bytesized)

Tracking

unspecified
Firefox 61
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox60+ fixed, firefox61 fixed)

Details

Attachments

(1 attachment)

It makes more sense for a homepage that is set by policy (and not locked) to be the default homepage. This would make it so that restoring the default value would restore the value that is the default for that company rather than the default for Firefox.
Comment hidden (mozreview-request)
Assignee: nobody → ksteuber
Attachment #8960692 - Flags: review?(felipc)
[Tracking Requested - why for this release]:
Enterprise Policies
Status: NEW → ASSIGNED

Comment 3

Last year
mozreview-review
Comment on attachment 8960692 [details]
Bug 1447345 - Change enterprise policy that sets homepage to set it as the default rather than the user value for the pref

https://reviewboard.mozilla.org/r/229446/#review235180
Attachment #8960692 - Flags: review?(felipc) → review+

Comment 4

Last year
Pushed by ksteuber@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1fce5707743a
Change enterprise policy that sets homepage to set it as the default rather than the user value for the pref r=Felipe
https://hg.mozilla.org/mozilla-central/rev/1fce5707743a
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
Comment on attachment 8960692 [details]
Bug 1447345 - Change enterprise policy that sets homepage to set it as the default rather than the user value for the pref

Approval Request Comment
[Feature/Bug causing the regression]: Enterprise Policy Manager
[User impact if declined]: Default homepage will be set to Firefox's default rather than the organization's default.
[Is this code covered by automated tests?]: Setting homepage by policy is covered by tests
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: Will be tested by Abe
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Slightly changes the behavior of the homepage policy. Will not affect users that do not use the policy engine or that policy.
[String changes made/needed]:
Attachment #8960692 - Flags: approval-mozilla-beta?
Actually we forgot something about this.

Because homepage is a complex pref, you have to set it as default differently.

See:

https://mike.kaply.com/2012/08/29/setting-the-default-firefox-homepage-with-autoconfig/

The policy is broken right now:

[Exception... "Component returned failure code: 0x80004004 (NS_ERROR_ABORT) [nsIPrefBranch.getComplexValue]"  nsresult: "0x80004004 (NS_ERROR_ABORT)"  location: "JS frame :: jar:file:///C:/Program%20Files/Nightly/64bits/testNightly/newer/coffee2/browser/omni.ja!/components/nsBrowserContentHandler.js :: get startPage :: line 592"  data: no]

this should be the only pref we have to do this weirdness with.
Attachment #8960692 - Flags: approval-mozilla-beta?
Hmm that's a very strange, how does the Locked case worked?  And did the previous version (before this change) worked too?

If so, I think we should just wontfix this bug and let it be as initial way. One less thing to uplift :)
Before he was setting the user pref, but my guess is locking it was broke as well.

But I agree with Kirk. We should be setting the default value.
Gah. Since this patch has merged to mozilla-central but not mozilla-beta, it puts me in a weird state for fixing it up. I don't really want to update the patch since merging it to mozilla-central wouldn't work (as the current version has already merged.

So I want to write the fix as a second patch. But I want to rebase because of changes to the homepage UI in about:preferences that just merged. And I cannot rebase the current patch on the tip of mozilla-central since it has already merged to mozilla-central. But if I write my patch without rebasing the current patch, mozreview will get rid of the current patch when I upload the new one.

I think it is simplest if I just file a new bug for the fix.
Blocks: 1448085
Comment on attachment 8960692 [details]
Bug 1447345 - Change enterprise policy that sets homepage to set it as the default rather than the user value for the pref

Approval Request Comment
[Feature/Bug causing the regression]: Enterprise Policy Engine
[User impact if declined]: Setting homepage via policy will set the page once, but resetting to default will reset to the Firefox default rather than the organization default.
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: To be tested by Abe
[List of other uplifts needed for the feature/fix]: The patch from Bug 1448085 must be merged after this patch
[Is the change risky?]: Minimal Risk
[Why is the change risky/not risky?]: Makes a minor change to the way that the enterprise policy works. Should not affect users not using enterprise policies
[String changes made/needed]: None
Attachment #8960692 - Flags: approval-mozilla-beta?
Comment on attachment 8960692 [details]
Bug 1447345 - Change enterprise policy that sets homepage to set it as the default rather than the user value for the pref

enterprise policy fix, approved for 60.0b8
Attachment #8960692 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.