826289 - Make default bookmarks customisable

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Browser, defect, P3)

Description

[Staś Małolepszy :stas]

+++ This bug was initially created as a clone of Bug #803328 +++

We should be able to customize init.json per locale/country/region/partner/other?.

Ideally, we would also have a default, unbranded version of this file checked into the repository.

Comment 1

[Staś Małolepszy :stas]

Oops, bb+ got cloned over.  Requesting properly now.

Comment 2

[David Scravaglieri [:scravag]]

What do you think about that Beatriz ? If the target market is different the bookmark will be different and it will be a non issue ?

Comment 3

[Alex Keybl [:akeybl]]

I'm wondering if this should be folded into bug 815517 as a partner customization.

Comment 4

[Axel Hecht [:Pike]]

I think that's a good concept. It rubs me backwards a bit that that bug is moco confidential. I don't think the general concept of doing bookmarks should be.

But yes, I think the bookmarks are more likely to be partner- than localization-dependent.

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB+, C4, P3

Comment 6

[Beatriz Rodríguez [:brg]]

Bookmarks should be customized per country-carrier-device type... not only localized.

Comment 7

[Ben Francis [:benfrancis]]

What exactly is the blocking-basecamp requirement here?

As we've agreed before and as has been discussed here again, these bookmarks don't really need to be localisable as described in the bug title, they just need to be customisable by partners.

They can already be customised by editing the init.json file, but this isn't yet generated at build time from applications-data.js. We could achieve this by base-64 encoding the favicons as data URLs and putting the bookmarks data in applications-data.js if this is the requirement?

Comment 8

[Ben Francis [:benfrancis]]

Changing title to what I understand the requirement to be.

Comment 9

[Ben Francis [:benfrancis]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/7292

Comment 10

[Donovan Preston [:fzzzy]]

This looks good to me. I would also like it if the file customize.json with the key bookmarks was present, that these bookmarks would get used instead of hardcoded bookmarks in applications-data.js but that can be added after.

Comment 11

[Staś Małolepszy :stas]

So the proposed patch simply moves these Brazil-specific bookmarks from apps/browser to build/.  It doesn't really make anything much more customizable than it is right now.  It's a step in the right direction, for sure.

Here's an outline of a solution I had in mind.  It can be implemented in this bug, or as a follow-up.

apps/browser/default_data/init.json should exist and have some unbranded default bookmarks in it. E.g. mozilla.org.

build/applications-data.js should also have a set of bookmarks in it, so that we can test that the build system correctly copies them to apps/browser/default_data/init.json.  This could be for instance mozilla.org/firefoxos.

Finally, separate config files per partner, possibly living in a separate write-protected repository, should exist.  When building Gaia, one would pass a variable specifying the customization file to use.

Comment 12

[Axel Hecht [:Pike]]

Looks good up to the last paragraph. most things in applications-data.js need to be hacked into oblivion by the people doing the builds to put on devices for partners, and I don't think we need to have all those variants in our repo.

Comment 13

[Ben Francis [:benfrancis]]

(In reply to Staś Małolepszy :stas from comment #11)
> Here's an outline of a solution I had in mind.  It can be implemented in
> this bug, or as a follow-up.
> 
> apps/browser/default_data/init.json should exist and have some unbranded
> default bookmarks in it. E.g. mozilla.org.

The only reason I haven't put any data there is because I'd need to know what the "unbranded" default bookmarks should be, and it took about 6 months to get an answer on what the current ones should be!

> Finally, separate config files per partner, possibly living in a separate
> write-protected repository, should exist.  When building Gaia, one would
> pass a variable specifying the customization file to use.

That's not how all the other customisations seem to currently work so that would be a wider issue. I agree with Axel. Let's not over-engineer this until we actually need this complexity. I doubt partners are going to want to check these files into our repository in general anyway.

Comment 14

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 697952 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/7292

This is probably good enough for now. Is is good to have as many things as possible in the build/application-data.js file in order to understand exactly what needs to be customize and to implement a decent customization strategy. 

We have more and more things that our partners want to customize and implementing a definitive solution probably require more or less a dedicated person for a few weeks. I have heard many things in the last few months, UX/Products has ideas / requirements, l10n has some, devs have some... so... I would say let's identify the needs by moving things out of applications first (like this patch) and let's build on top of that later.

Comment 15

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/b51c5e379c806f13558197d95db317f12f1d0e54

It would be nice to have a meta bug for tracking the customization infrastructure as well. (Ben, hint!)

Comment 16

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Bustage fix: https://github.com/mozilla-b2g/gaia/commit/cf0afeac572d529ef1cc2a8dca4de43417c2d767

Comment 17

[Daniel Coloma:dcoloma]

(In reply to Vivien Nicolas (:vingtetun) from comment #14)
> Comment on attachment 697952 [details] [review]
> https://github.com/mozilla-b2g/gaia/pull/7292
> 
> This is probably good enough for now. Is is good to have as many things as
> possible in the build/application-data.js file in order to understand
> exactly what needs to be customize and to implement a decent customization
> strategy. 
> 
> We have more and more things that our partners want to customize and
> implementing a definitive solution probably require more or less a dedicated
> person for a few weeks. I have heard many things in the last few months,
> UX/Products has ideas / requirements, l10n has some, devs have some... so...
> I would say let's identify the needs by moving things out of applications
> first (like this patch) and let's build on top of that later.

I agree with this approach, let's try to keep it as simple as we can for the short term.