Closed Bug 1479769 Opened 3 years ago Closed 3 years ago
ESR group policy homepage removing anchor link from URL
212.79 KB, image/png
151.39 KB, image/png
46 bytes, text/x-phabricator-request
|Details | Review|
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180704003137 Steps to reproduce: I am setting the homepage via the new group policy templates in ESR 60.1.0 (64-bit en-US). The URL has an anchor link at the end which is required in this instance. I can see that the value is being set via the GPO in the windows registry at HKLM\Software\Policies\Mozilla\Firefox\Homepage\URL with the correct value. Actual results: When firefox is launched, the path is loaded from the registry but the # and everthing afterwards (the anchor link) is being removed. This is visible within Options in Firefox as well where the URL is incomplete. Expected results: The value should have been read as-is from the registry and applied to the homepage value in Firefox on first launch. Instead, the string appears to be cleaned and removes the anchor link.
Can you test this using Nightly to see if the same problem happens? If so, please go to about:support and click on the Active policies link (this is only available on nightly at the moment) to see if the anchor shows up in the parsed JSON
Screenshot of testing bug against nightly as requested
Hi Felipe, Unfortunately, the behavior is the same. I removed ESR 60.1, installed nightly 63.0a1 and deleted the user profile to clear any cached settings. Because the Options page(s) have change since the last ESR release, the location of the value in the interface has moved and doesn't seemed to be presented as yet. I presume it will appear as a custom URL by release. Screenshot is attached as before. Thanks, Shaun
Assignee: nobody → ksaini
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I tried reproduce this error and coincidentally, I had set the "Locked" property to be true. And to my surprise, it worked fine. Then I removed the value of Locked and I got this error. Therefore, it becomes easier to find the bug in the code. Here at https://searchfox.org/mozilla-central/source/browser/components/enterprisepolicies/Policies.jsm#531,539-541 we can see the difference between two conditional blocks. In the "else" block, prefvalue is being prefixed with "data:text/plain,browser.startup.homepage=". On removing this extra string, the homepage is set as expected. I couldn't figure out what this string value is changing in the else block and breaking the code as well. Felipe, any inputs?
Ok, so I did some code history investigation here. When the Homepage policy was written, setting the default homepage required setting a "complex" pref value. This wasn't initially noticed, but was fixed in bug 1448085. I just did some tests with these complex pref values and it turns out it has some encoding problems and does not support the # character. (at least not easily, there's probably a way to fix it but it won't be necessary) Turns out that, luckily, very recently the Firefox code that handles the homepage was refactored and it now supports having it as a normal string pref (bug 721211). So all that we need to do to fix this is to revert the code change done in bug 1448085, and go back to using setDefaultPref which will just call setStringPref. (no need to revert the test changes) And we should add a new testcase in the test browser_policy_set_homepage.js to make sure this is covered.
[Tracking Requested - why for this release]: This might be another nice to have if we get it done in time. Just a bug fix.
Comment on attachment 8999150 [details] Bug 1479769 - Policy: Homepage now correctly sets homepage URLs with anchors :Felipe Gomes (needinfo me!) has approved the revision.
Attachment #8999150 - Flags: review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/44e8eb2860b6 Homepage Policy no longer needs to use complex prefs. r=felipe
Please nominate this for Beta/ESR60 approval if you feel it appropriate to do so.
Thanks for the reminder. It'd be nice if this was fixed on ESR but unfortunately it relies on bug 721211 and I don't think we should try to uplift that.
You need to log in before you can comment on or make changes to this bug.