1502134 - Enterprise Profiles: Need support for multiple URLs in OverrideFirstRunPage policy

Status: VERIFIED FIXED

(Firefox :: Enterprise Policies, defect, P2)

Description

[sdowdy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce:

Similar to HomePage policy, OverrideFirstRunPage policy should allow for multiple URLs.
I want 3 important URLs loaded in tabs for my users on their first Firefox run, rather than 3 URLs loaded into tabs in each new window.  (I then want NO additional tabs to load in subsequent new windows, or on subsequent activations of firefox)


Actual results:

I'm just gonna cut/paste a conversation thread from "[e-mail]" here.:
(uh, there MUST be a "SMARTER" "New Bug" interface somewhere that i'm missing, because i'm not allowed to select Product/Component in this very limited dumbed-down Web UI (sigh) so hopefully this gets into the "Enterprise Policies" component section.

----------------------------------------------------------------------
Felipe Gomes <[e-mail]> writes:
Ah yes, this is working as expected. The Homepage policy is tied to the set
of tabs that open for every new window  (or also when you click the "Home"
button in the toolbar).

The policy that you're looking for is OverrideFirstRunPage, which will do
exactly what you want.  The only problem with that is that it only supports
one URL right now (to be honest I never knew the
startup.homepage_welcome_url pref supported more than one)

If you file a bug in the Firefox :: Enterprise Policies component about
supporting more than one, we can get that support added for you.

Best,
Felipe

On Wed, Oct 24, 2018 at 8:12 PM Stephen Dowdy <[e-mail]> wrote:

> On 10/24/18 4:44 PM, Felipe Gomes wrote:
>> The first implementation of the Homepage policy also forced the setting
> of
>> browser.startup.page to 1, because some users were getting confused if it
>> didn't force the homepage to open.  This was intentional at that time,
> but
>> we realized that it was a mistake, so we fixed that with bug
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1469951, which means that
> this
>> fix will be released with Firefox 64.
>>
>> (In the meantime, for Firefox 63, as long as you don't use the "Locked"
>> setting of the Homepage policy, and don't make any more changes to it,
> your
>> choice of browser.startup.page=3 will remain)
>
> I think you are referring to my current situation where i manually reset
> sessionrestore.
> (i.e. it's going to stay unless i change my policies to use locked home
> pages)
>
>> Apologies for the confusion it might have caused. As for your lost
> session,
>> there are backups! In your profile directory, look for a
>> sessionstore-backups folder, and follow the instructions here to recover:
>> https://support.mozilla.org/en-US/questions/1221836
>>
>> Hope that helps!
>
> Thanks for the bit about recovering sessionstore-backups.  I'll check that
> out.
>
> Another unexpected thing... I'm getting the 3 homepages for each new
> window opened.
> I don't recall if that was a prefs change i'd made or not.
>
> I operate from the "defaultPref()" model in mozilla.cfg (i want to help
> you have a "sane" (as defined by me  ) default, but feel free to change
> it), so maybe the Policy Engine is changing the defaults, but wouldn't
> alter those set with "pref()" (aka user_pref()).
>
> I haven't had much chance to debug at this point.
>
> Hmm, i'd just grep'd before in initial post, but here's the actual
> relevant bits from mozilla.cfg:
>
>     defaultPref("browser.startup.homepage",
> "data:text/plain,browser.startup.homepage=http://...|http://...|http://
> ...");
>     ...
>     //  if ( getPref("browser.startup.homepage_override.mstone") === null
> ) {
>       defaultPref("startup.homepage_welcome_url",
> "data:text/plain,startup.homepage_welcome_url=http:...|http:...|http:....");
>     //  }
>       defaultPref("browser.startup.homepage",
> "data:text/plain,browser.startup.homepage=about:blank");
> **hmm, i'm replacing what i used before likely due to figuring out the
> diff between these settings**
>       defaultPref("ui.use_activity_cursor",true);
>     //  defaultPref("browser.startup.homepage_override.mstone", "ignore");
>     defaultPref("browser.sessionstore.enabled", true);
>     defaultPref("browser.sessionstore.resume_from_crash", true);
>     // 0=<blank>, 1=HomePage, 2=<lastvisited> , 3=SessionRestore
>     defaultPref("browser.startup.page", 3);
>
> I've got some stuff commented out there.  IIRC (it's been like 10 years
> since i worked on that section), the commented parts were about milestone
> changes (i think that changed every udpate) overwriting stuff.
>
> Since it's commented, i'm now apparently setting the
> 'browser.startup.homepage' pref to about:blank, but the
> 'startup.homepage_welcome_url' pref to the list i want my users to have
> initially.
>
> I guess the HomePage Policy is then more likely tied to the
> 'browser.startup.homepage' pref, which opens homepages per new window,
> whereas i want it to be more like the 'startup.homepage_welcome_url'.
> Keeping track of this stuff is getting confusing.   Any guidance you can
> give me is welcome.
> I'm thinking right now, that as long as you keep the above preferences,
> that i want to use those, and NOT the Homepage policy, as it is going to
> open those homepages for every new window, which is certainly NOT what i
> want.
>
> I just want to setup default first-time homepages for new profiles for new
> users, and let them do what they want with them, but not have them recur
> for every new window they open.
>
> thanks,
> --stephen
> --
> Stephen Dowdy  -  Systems Administrator  -  NCAR/RAL
> 303.497.2869   -  [e-mail]        -
> http://www.ral.ucar.edu/~sdowdy/


Expected results:

I get three tabs open on new firefox profile first run, but new windows get only a single empty (or fallback about:blank) tab.

Comment 1

[Pablo Lluch]

Hi sdowdy. I arrived to this bug by reference of Felipe and reading through it seems quite interesting. I'm a newbie and I would like to take this on as a GFB but I'm not 100% percent sure how to approach it -as I find the message log slightly confusing and can't really understand what the actual intended result is.

Comment 2

[:Felipe Gomes (needinfo for replies!)]

Hello Pablo,

so, right now the OverrideFirstRunPage policy accepts an URL [1]. What was requested here is to make it accept an array instead of an URL.

We can't just switch it from URL to Array because that would break backwards compatibility. Luckily, the policy engine semi-recently added support for accepting more than 1 type. It hasn't been used yet, but here's a test that demonstrates it: [2]

To do that, you'll need to change the schema definition (link 1), and then add the support for it in the code that implements this policy. [3]



[1] https://searchfox.org/mozilla-central/rev/7f7c353e969e61a6a85201cc8ad3c3de12ac30d8/browser/components/enterprisepolicies/schemas/policies-schema.json#389-393

[2] https://searchfox.org/mozilla-central/rev/7f7c353e969e61a6a85201cc8ad3c3de12ac30d8/toolkit/components/utils/test/browser/browser_JsonSchemaValidator.js#372-379

https://searchfox.org/mozilla-central/rev/7f7c353e969e61a6a85201cc8ad3c3de12ac30d8/browser/components/enterprisepolicies/Policies.jsm#679-684

Comment 3

[Pablo Lluch]

Great! Thanks Felipe, I'll have a look at it and will let you know when I fix it.

Comment 4

[Pablo Lluch]

Hi Felipe, so I've changed the schema definition as mentioned in your last comment.
However, in order to add the support in the code that implements this policy I'm not sure what to do. 

[1] I could check the parameters of onProfileAfterChange so that if the second param is an array I would call setAndLockPref with the first element of that array. Conversely, if param were to be a single url I would just call setAndLockPref with that.

[2] The other option is to call setAndLockPref for every element of the param array -in the case that param is an array and not a single URL.

I'm not entirely sure which one of those I'm meant to implement. 

Thanks,

Comment 5

[trushita]

can I work on this if no one is working?

Comment 6

[Mike Kaply [:mkaply]]

Sure.

Comment 7

[trushita]

Thanks! I'll check it out.

Comment 8

[Mike Kaply [:mkaply]]

There's a much simpler way to support this. The first run pref supports multiple pages separated by a vertical bar. We can switch the policy to allow for a string, then you can just put https://www.example.org|https://www.example.com

This also means we don't have to change a lot of code.

Comment 9

[Mike Kaply [:mkaply]]

Attachment: Bug 1502134 - Allow for multiple firstrun pages in policy. r?emalysz!

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5ea38b8c1175
Allow for multiple firstrun pages in policy. r=emalysz

Comment 11

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/5ea38b8c1175

Comment 12

[Mike Kaply [:mkaply]]

Comment on attachment 9180271 [details]
Bug 1502134 - Allow for multiple firstrun pages in policy. r?emalysz!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Policy improvement
• User impact if declined: Can't specify multiple firstrun pages for policy
• Fix Landed on Version: 83
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Policy only.
  There is no test because this specific behavior is built into Firefox and tested elsewhere
• String or UUID changes made by this patch:

Comment 13

[Julien Cristau [:jcristau]]

I guess you'll have this |-splitting documented elsewhere?

Comment 14

[Mike Kaply [:mkaply]]

(In reply to Julien Cristau [:jcristau] from comment #13)

I guess you'll have this |-splitting documented elsewhere?

Yes, i'll be updating the policy documentation.

Comment 15

[Julien Cristau [:jcristau]]

Comment on attachment 9180271 [details]
Bug 1502134 - Allow for multiple firstrun pages in policy. r?emalysz!

approved for 78.5

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/5b4fab7994d2

Comment 17

[Emil Ghitta, QA [:emilghitta]]

This is verified fixed using Firefox 83.0b4 (BuilId:20201025174155) and Firefox esr 78.5 (provided in comment 16) on Windows 10 64bit, macOS 10.15 and Ubuntu 20.04.

Verified by using the following policies.json file content:

{ "policies": { "OverrideFirstRunPage": "http://www.cnislavici.ro/univ/|https://edu.ro/|https://www.utcluj.ro/|https://www.ubbcluj.ro/ro/" } }

All 4 URL's that were specified inside the OverrideFirstRunPage policy are successfully visible on fresh profiles in 4 different tabs on the same Firefox window.