See description in user story field

Hey Albert, I was wondering what the status was on this since we are looking to have a configuration in for search providers in 2.0, which should probably use this, Cheers

What is the idea? Reuse this bug to add a list of preconfigured search providers?

Just talked to Albert, it should be finished along next week

Marcelino, yup, we will have the same requirements of configuration for the search providers as the top sites and we obviously dont want multiple configuration mechanisms, so most of the work for configuring search providers will be part of this bug, happy to help out if this wasnt planned until later, but landing next week sounds good

Work In Progress patch. It implements the population of browser top sites for global configuration. Tomorrow I'm going to implement the single variant part, so I think I'll have a full working patch on Monday or Tuesday.

While implementing the global population of topsites I found something that can be improved in the default.json, where we have the browser settings. The thing is that we can have the same sites in bookmarks and topsites, in that case we have for example: "000000": { "bookmarks": [ { "title": "Mozilla", "uri": "http://mozilla.org", "iconUri": "........." } ], .... "topSites": [ { "title": "Mozilla", "uri": "http://mozilla.org", "iconUri": "........." } ], .... As you can see, we have the same object two times and the image is duplicated. To avoid it we can create an external sites object and then put a reference in 'bookmarks' and 'topSites', thus the size of the file will be reduced a half. I propose something like that: "sites": [ mozilla: { "title": "Mozilla", "uri": "http://mozilla.org", "iconUri": "........." }, .... ], "000000": { "bookmarks": ["mozilla"], .... "topSites": ["mozilla"], .... I'm not saying to modify it just now, but it would be great to do this change when both bug 1009633 and bug 1009353 are fixed and ready for 2.0 Dale, what do you think?

Albert, just to be clear, from your patch it looks like you're implementing default top sites for the browser app for version 2.0. Is that right? Please note that bug 1009353 is for the Rocketbar. We already have a configuration of search engines for the browser app. If this bug is just for the browser app then it does not block bug 1009353 as the Rocketbar may be configured separately.

(In reply to Ben Francis [:benfrancis] from comment #7) > Albert, just to be clear, from your patch it looks like you're implementing > default top sites for the browser app for version 2.0. Is that right? > > Please note that bug 1009353 is for the Rocketbar. We already have a > configuration of search engines for the browser app. > > If this bug is just for the browser app then it does not block bug 1009353 > as the Rocketbar may be configured separately. Yes, you are right, I'm working on browser app and I have seen code related with search engines. I also don't understannd the relation with bug 1009353. However there is one thing to keep in mind with current implementation of single variant, if the SIM card is inserted after launching the browser then single variant will not work. I'll fix it for top sites, shall I fix also for bookmarks and share engines?

No problem to help on customizing search engine, not sure if it should be in this bug or we should open other one. Other question is that apparently it is already implemented, so we should clarity it. Anyway I would suggest to write a user story with the details, even in case it could be implemented it same patch as browser top sites, so that QA people can test it.

Yup this was my mistake, when you said you were working on customisation of top sites I assumed you meant the rocketbar / 2.1 top sites, not the browser app, we can use https://bugzilla.mozilla.org/show_bug.cgi?id=1009353 for that, thanks.

And as for https://bugzilla.mozilla.org/show_bug.cgi?id=1009633#c6, you can fix it if you want to and your plan is sound, as this functionality will be getting replaced at some point I would hesitate to work on too many improvements, but if it has an improvement as you implement this top sites patch then go for it

(In reply to Albert [:albert] from comment #8) > However there is one thing to keep in mind with current implementation of > single variant, if the SIM card is inserted after launching the browser then > single variant will not work. I'll fix it for top sites, shall I fix also > for bookmarks and share engines? This was by design. The requirements were that the customisations only applied to the SIM card that was present on first launch of browser. The settings should not change if you change your SIM card at a later date. Do you have different requirements?

(In reply to Ben Francis [:benfrancis] from comment #12) > (In reply to Albert [:albert] from comment #8) > > However there is one thing to keep in mind with current implementation of > > single variant, if the SIM card is inserted after launching the browser then > > single variant will not work. I'll fix it for top sites, shall I fix also > > for bookmarks and share engines? > > This was by design. The requirements were that the customisations only > applied to the SIM card that was present on first launch of browser. The > settings should not change if you change your SIM card at a later date. > > Do you have different requirements? Yes, I do. The user story says that 'local browser top sites to be configured per MCC/MNC the fist time to insert a SIM card of an operator that is defined in the device'. So, if user pass the ftu with no sim, open the browser and then inserts a SIM, current implementation won't work.

Comment on attachment 8427144 [details] Patch Added mechanism to configure topsites in the same way as the other single variant resources. I kept bookmarks and search engine configuration, so patch does not look very clean, I will change bookmarks and search engine also if you like the new process, in bug 1015930. The way it works is: - There is a global config file generated during build time. - The custom mcc-mnc is set in variant.json (https://github.com/acperez/firefoxos-gaia-testsbuild) - At run time, the operatorvariant application process single variant configuration when available and set a setting with the content of the 'topsites' based on mcc/mnc. - When the browser application is launched the first time, it loads global file, add global topsites to the database and check the setting. - If the setting exists, also adds the custom config to the database. - If the setting does not exist, it will add an observer to the setting.

After having looked over this patch I'd like to confirm some requirements with Product: * "And also local browser top sites to be configured per MCC/MNC the fist time to insert a SIM card of an operator that is defined in the device" * "Local browser top sites will be added on top of existing ones, even the ones owed to browser usage" So there are top sites customised at build time which take effect the first time the browser is launched, but there are also top sites customised the first time a SIM card is entered (if that is after the first time the browser is launched). Not only that, but the SIM card top sites can actually overwrite the user's own organic top sites? Peter, can you confirm that we should configure bookmarks on SIM card entry in addition to at build time? Can you also confirm that these should overwrite the user's own top sites? Neither of these are currently done for any of the other browser app build-time customisations and it complicates the implementation significantly. The requirement to overwrite user top sites means that the patch looks for the URL in the places database which has the highest frecency score and gives the SIM card top sites a frecency score one higher than that. That means the users' own organic top sites have an artificially high frecency threshold to meet in order to displace the artificial customised ones. That doesn't seem right. The requirement to change top sites after the first launch of the browser (on SIM card entry) also complicates the implementation significantly and means the browser app requires read/write access permission to settings which it didn't require before. I would like be sure the added risk of complexity and additional permissions is justified and confirm the intended frecency behaviour before reviewing this patch further :)

(In reply to Albert [:albert] from comment #6) > While implementing the global population of topsites I found something that > can be improved in the default.json, where we have the browser settings. The > thing is that we can have the same sites in bookmarks and topsites, in that > case we have for example: > > "000000": { > "bookmarks": [ > { "title": "Mozilla", > "uri": "http://mozilla.org", > "iconUri": "........." > } > ], > .... > "topSites": [ > { "title": "Mozilla", > "uri": "http://mozilla.org", > "iconUri": "........." > } > ], > .... > > As you can see, we have the same object two times and the image is > duplicated. To avoid it we can create an external sites object and then put > a reference in 'bookmarks' and 'topSites', thus the size of the file will be > reduced a half. I propose something like that: > > "sites": [ > mozilla: { > "title": "Mozilla", > "uri": "http://mozilla.org", > "iconUri": "........." > }, > .... > ], > "000000": { > "bookmarks": ["mozilla"], > .... > "topSites": ["mozilla"], > .... > > I'm not saying to modify it just now, but it would be great to do this > change when both bug 1009633 and bug 1009353 are fixed and ready for 2.0 BTW, this seems like a good idea. I would call them "places" instead of "sites" and use the URL as a key for bookmarks rather than an arbitrary string, to mirror the way the places database works. Also, you could specify top sites as just "places" with a frecency score of "1" which is populated when the place is created so that it gets entered into the frecency index and will appear in top sites. So for example: "000000": { "places": [ { "title": "Mozilla", "uri": "http://mozilla.org", "iconUri": ".........", "frecency": 1 // makes it a top site } ], .... "bookmarks": [ "http://mozilla.org" // makes it a bookmark ], }

(In reply to Ben Francis [:benfrancis] from comment #15) > Peter, can you confirm that we should configure bookmarks on SIM card entry > in addition to at build time? Can you also confirm that these should > overwrite the user's own top sites? Neither of these are currently done for > any of the other browser app build-time customisations and it complicates > the implementation significantly. > > The requirement to overwrite user top sites means that the patch looks for > the URL in the places database which has the highest frecency score and > gives the SIM card top sites a frecency score one higher than that. That > means the users' own organic top sites have an artificially high frecency > threshold to meet in order to displace the artificial customised ones. That > doesn't seem right. > > The requirement to change top sites after the first launch of the browser > (on SIM card entry) also complicates the implementation significantly and > means the browser app requires read/write access permission to settings > which it didn't require before. > > I would like be sure the added risk of complexity and additional permissions > is justified and confirm the intended frecency behaviour before reviewing > this patch further :) Thanks for calling it out Ben. I missed the line in the requirements about surfacing top sites above ones created by user browsing when the SIM is inserted later. I agree that this likely isn't the right approach. I'd prefer if we surface the preloaded sites after a SIM is entered ONLY if there are blank tiles (or globally configured ones) to do so. So, for example: - I start using a device without a SIM and two top sites are configured - I browse until I have I have no blank tiles left - I insert a SIM which has two new top sites configured - These replace the two globally configured tiles Another example: - I start using a device without a SIM and browse until the point that all tiles are filled with my personal websites - I insert a SIM which has two new top sites configured - Nothing happens to the top sites Another example (with one blank tile): - I start using a device without a SIM and browse until the point that all but one tile is filled with my personal websites - I insert a SIM which has two new top sites configured - The first of the new configured top sites is placed in the position of the blank tile Marce, what do you think of this approach? I think the current approach can inadvertently overwrite the user's data (top sites they like to visit), which is not great.

Francis, let me know if you agree with the approach I described above.

We were discussing internally, and it works for us, maybe implementation is a bit more complicated, but doable

And if everybody agrees, I can update acceptance criteria of the user story according to these new requirements

Thanks Peter. Most of that sounds more straightforward in that if the top sites get pre-populated by just inserting places with a frecency of 1 you would get almost the behaviour you describe. However... (In reply to Peter Dolanjski [:pdol] from comment #17) > So, for example: > - I start using a device without a SIM and two top sites are configured > - I browse until I have I have no blank tiles left > - I insert a SIM which has two new top sites configured > - These replace the two globally configured tiles This part is going to get really messy, particularly if the user visits the global top sites (turning them into organic top sites) before a SIM card is entered and the user's own top sites and browsing history are then overwritten. See EXAMPLE 1 below. My preferred solution would be that default top sites can not be added if the browser has already been opened and used, because they are no longer just defaults filling an empty space, they could actually be over-writing organic user top sites and modifying browsing history. However, if replacing global top sites with local top sites (in the edge case where a user inserts their SIM card after booting the browser) is a hard requirement then the simplest solution I can think of (see EXAMPLE 2) is: * Global default top sites are defined as default "places" with a frecency of 1. * If the operator wants local defaults added later to be given precedence over global defaults then they should be given a frecency of 2. That way they will appear above global defaults, unless the user has visited the global defaults turning them into organic top sites, in which case they will appear lower in the list. * Optionally global top sites can be removed if they still have a frecency of 1 at the time a SIM card is entered and new local top sites are added. EXAMPLE 1 Imagine my top four sites are: 1. a.com - frecency 4 - visited by user 2. b.com - frecency 3 - global default, visited by user 3. c.com - frecency 2 - visited by user 4. d.com - frecency 1 - global default, not visited by user where the user has visited one of the global top sites, turning it into an organic top site. Then a SIM card is entered with two new local default sites: e.com - frecency 1 - local default f.com - frecency 1 - local default We replace b.com and d.com with e.com and f.com. We shouldn't give the local defaults the organic frecency score the global defaults had acquired because that would be wrong, so the local defaults appear further down the list and the (now organic) global defaults are removed completely, including removing them from the user's browsing history, which doesn't seem right either. 1. a.com - frecency 4 - visited by user 2. c.com - frecency 2 - visited by user 3. e.com - frecency 1 - local default 4. f.com - frecency 1 - local default EXAMPLE 2 1. a.com - frecency 4 - visited by user 2. b.com - frecency 3 - global default, visited by user 3. c.com - frecency 2 - visited by user 4. d.com - frecency 1 - global default, not visited by user Then a SIM card is entered with two new local default sites: e.com - frecency 2 - local default f.com - frecency 2 - local default The global default which has become an organic top site keeps its place, but the new local default now gets appended to the end. 1. a.com - frecency 4 - visited by user 2. b.com - frecency 3 - global default, visited by user 3. c.com - frecency 2 - visited by user 4. e.com - frecency 2 - local default There are still edge cases where the users' organic top sites could get knocked off the top spots by the artificially inserted local top sites, but that should self-correct fairly quickly.

We currently give artificial listings a -1 frecency, if we wanted to prioritise local / global defaults we can use -1 and -2. And I fully agree the configured sites should never override users generated data.

(In reply to Ben Francis [:benfrancis] from comment #21) > * Global default top sites are defined as default "places" with a frecency > of 1. > * If the operator wants local defaults added later to be given precedence > over global defaults then they should be given a frecency of 2. That way > they will appear above global defaults, unless the user has visited the > global defaults turning them into organic top sites, in which case they will > appear lower in the list. This is the best option that matches our needs, so just to summarize: * Global defaults will take frecency of 1 * Local defaults will take frecency of 2 * User visited sites always take precedence Do you agree?

I'll defer to Peter on whether new artificial top sites can ever be added after the browser app has been used, but if they can then I think Dale's suggestion of using -2 for global and -1 for local is a good one.

I am not sure about the meaning of -1 and -2, what is the difference from 1 and 2?

Just guessing, from bottom to top of the list, -2 would be the first one, -1 would be next, and then 0, 1, 2, 3, ..., and in case a user visit a site, score will be updated the same way for any kind of value (-2 & -1 included). Am I right?

A higher frecency score means a higher position in the top sites list. Every time a site is visited the frecency score gets incremented. By starting global defaults on -2 and local defaults on -1 you can ensure that local defaults always have a higher initial score (therefore a higher position in top sites) than global defaults, but a lower initial score than organic top sites. Both artificial (default) top sites and organic ones will increment their frecency when the user visits them. We could allow default top sites to have any frecency value less than 0 which would also allow customisations to set the initial order of their top sites if they wish to.

Understood, so agree to set global defaults to -2 and local defaults to -1

(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #28) > Understood, so agree to set global defaults to -2 and local defaults to -1 I'm good with this approach, but at this point whatever is the simplest is also fine with me just so we can deliver in 2.0. If it is simpler to implement no new top site additions after the user has started using the browser (as Ben described), then that option is okay too.

OK, agree then, and after talking to Albert, inserting local top sites after FTU is already implemented, just needing to change frecency to -1, so no problem to finish the whole functionality

User story updated according to latest comments

Patch modified according to the new user story. Can you have a look?

Comment on attachment 8427144 [details] Patch Thanks for the patch, and for your patience Albert. This code looks generally good, but there are some points I'd like to discuss before landing: * Travis is failing, there seems to be a failing unit test. It would be nice to add some tests for this new functionality too though I recognise the existing test coverage in this area is patchy! * This use of the Settings API as a temporary data store troubles me. Is this pattern being used by operator variant features elsewhere? As general feedback it seems like this would seem like more of a use case for an operator variant DataStore than the Settings API. * Pre-populated top sites won't get thumbnails until the user navigates to them. That's OK with me as long as that's the intended behaviour? * It looks like we will always be listening for changes to a setting, even after customization has happened. It might be nice to set the setting to something to tell the browser app it can stop listening? * I can see why you want to apply this same approach to bookmarks and search engines for consistency. I'm not sure if it's worth the effort given that the browser app is going away, and we would need to discuss whether it's right for bookmarks to be added and search engine setting to be changed after the user has already used the app.

(In reply to Ben Francis [:benfrancis] from comment #33) > * Pre-populated top sites won't get thumbnails until the user navigates to > them. That's OK with me as long as that's the intended behaviour? Yes, this is the intended behaviour for us

(In reply to Ben Francis [:benfrancis] from comment #33) > Comment on attachment 8427144 [details] > Patch > > Thanks for the patch, and for your patience Albert. This code looks > generally good, but there are some points I'd like to discuss before landing: > > * Travis is failing, there seems to be a failing unit test. It would be nice > to add some tests for this new functionality too though I recognise the > existing test coverage in this area is patchy! > * This use of the Settings API as a temporary data store troubles me. Is > this pattern being used by operator variant features elsewhere? As general > feedback it seems like this would seem like more of a use case for an > operator variant DataStore than the Settings API. We have different kind of patterns depending on the feature, for example: - ringtone, wallpaper, keyboard, nfc, power, sms, support_contacts. These ones set single variant configuration to a setting because is how the configuration works, using a setting. - default_contacts, known_networks. Both add the configuration using a gecko API. - network_types, topsites, data_ftu. These ones are using a setting to pass data to other apps. > * Pre-populated top sites won't get thumbnails until the user navigates to > them. That's OK with me as long as that's the intended behaviour? > * It looks like we will always be listening for changes to a setting, even > after customization has happened. It might be nice to set the setting to > something to tell the browser app it can stop listening? Do you mean to use one setting for data an another for 'sync'? > * I can see why you want to apply this same approach to bookmarks and search > engines for consistency. I'm not sure if it's worth the effort given that > the browser app is going away, and we would need to discuss whether it's > right for bookmarks to be added and search engine setting to be changed > after the user has already used the app.

(In reply to Albert [:albert] from comment #35) > > * This use of the Settings API as a temporary data store troubles me. Is > > this pattern being used by operator variant features elsewhere? As general > > feedback it seems like this would seem like more of a use case for an > > operator variant DataStore than the Settings API. > > We have different kind of patterns depending on the feature, for example: ... > - network_types, topsites, data_ftu. > These ones are using a setting to pass data to other apps. The Settings API is being used as a temporary data store until the data gets populated in IndexedDB, which seems like a mis-use of the Settings API. Maybe if/when we implement this for system browser we can use the Places DataStore directly. > > * Pre-populated top sites won't get thumbnails until the user navigates to > > them. That's OK with me as long as that's the intended behaviour? > > * It looks like we will always be listening for changes to a setting, even > > after customization has happened. It might be nice to set the setting to > > something to tell the browser app it can stop listening? > > Do you mean to use one setting for data an another for 'sync'? I'm not sure really, it's just that this is a one time thing and it would be nice if the browser app didn't have to keep listening to the default top sites setting after they have been populated. But I guess that state has to be stored somewhere which might just add complexity.

(In reply to Ben Francis [:benfrancis] from comment #36) > (In reply to Albert [:albert] from comment #35) > > > * This use of the Settings API as a temporary data store troubles me. Is > > > this pattern being used by operator variant features elsewhere? As general > > > feedback it seems like this would seem like more of a use case for an > > > operator variant DataStore than the Settings API. > > > > We have different kind of patterns depending on the feature, for example: > ... > > - network_types, topsites, data_ftu. > > These ones are using a setting to pass data to other apps. > > The Settings API is being used as a temporary data store until the data gets > populated in IndexedDB, which seems like a mis-use of the Settings API. > Maybe if/when we implement this for system browser we can use the Places > DataStore directly. > I agree with the datastore approach, we will change 'settings store' by datastore. So do you want to change now it just for topsites or can I left it as it is? > > > * Pre-populated top sites won't get thumbnails until the user navigates to > > > them. That's OK with me as long as that's the intended behaviour? > > > * It looks like we will always be listening for changes to a setting, even > > > after customization has happened. It might be nice to set the setting to > > > something to tell the browser app it can stop listening? > > > > Do you mean to use one setting for data an another for 'sync'? > > I'm not sure really, it's just that this is a one time thing and it would be > nice if the browser app didn't have to keep listening to the default top > sites setting after they have been populated. But I guess that state has to > be stored somewhere which might just add complexity. I also don't like the idea of being listening always but I tried to avoid adding some field in the database for that, at least it is not wasting resources, the browser only gives a reference to a function to the settings API. By the way, same thing will happen with datastore, right?

(In reply to Albert [:albert] from comment #37) > I agree with the datastore approach, we will change 'settings store' by > datastore. So do you want to change now it just for topsites or can I left > it as it is? I think it's probably OK to leave it as it is for 2.0 as it's a temporary solution, in 2.1 the browser app will go away and there is already a Places DataStore that can be used for this purpose. > I also don't like the idea of being listening always but I tried to avoid > adding some field in the database for that, at least it is not wasting > resources, the browser only gives a reference to a function to the settings > API. By the way, same thing will happen with datastore, right? OK fair enough, let's keep this as is. Let's create some tests, make Travis happy and get this landed :)

Comment on attachment 8427144 [details] Patch Yuren can you review the build part?

Fixed and added tests.

Comment on attachment 8427144 [details] Patch Thanks!

Comment on attachment 8427144 [details] Patch Albert, I left some comments on github, majar issue is datauri which was used for wallpaper and ringtone but it's inconvenience since we need to use command to generate it for customization, so I hope we can't avoid to use datauri.

(In reply to Yuren [:yurenju] from comment #42) > Comment on attachment 8427144 [details] > Patch > > Albert, I left some comments on github, majar issue is datauri which was > used for wallpaper and ringtone but it's inconvenience since we need to use > command to generate it for customization, so I hope we can't avoid to use > datauri. The main problem of using an url instead of a datauri is that icon can't be downloaded if there is no connection. I know that do not make sense to open the browser if you don't have connection but I have to check it with product people.

how about use a local icon file like icons for RocketBar[1] customization? [1] https://github.com/benfrancis/gaia/blob/a200ce149086cbc1cff549ea119d82f7a234e5fc/customization/search/providers.json

(In reply to Yuren [:yurenju] from comment #44) > how about use a local icon file like icons for RocketBar[1] customization? > > [1] > https://github.com/benfrancis/gaia/blob/ > a200ce149086cbc1cff549ea119d82f7a234e5fc/customization/search/providers.json That's fine for default icons, which are included in browser app. But for single variant we can't use the app://operatorvariant.gaiamobile.org/resources/icon.ico approach because browser doesn't have webapp-mange permission.

I think we still can convert a icon path to datauri in build.js, for example we can have "iconPath" field in topsites.json and convert to uri to "iconUri" field (and delete iconPath) then write the file to build_stage. here is a example to convert nsIFile to datauri. https://developer.mozilla.org/en-US/docs/Web/HTTP/data_URIs#Converting_an_nsIFile_to_a_data_URI

(In reply to Yuren [:yurenju] from comment #46) > I think we still can convert a icon path to datauri in build.js, for example > we can have "iconPath" field in topsites.json and convert to uri to > "iconUri" field (and delete iconPath) then write the file to build_stage. > > here is a example to convert nsIFile to datauri. > https://developer.mozilla.org/en-US/docs/Web/HTTP/ > data_URIs#Converting_an_nsIFile_to_a_data_URI Ok, that's fine.

(In reply to Yuren [:yurenju] from comment #46) > I think we still can convert a icon path to datauri in build.js, for example > we can have "iconPath" field in topsites.json and convert to uri to > "iconUri" field (and delete iconPath) then write the file to build_stage. > > here is a example to convert nsIFile to datauri. > https://developer.mozilla.org/en-US/docs/Web/HTTP/ > data_URIs#Converting_an_nsIFile_to_a_data_URI The btoa function used in your snippet is not available at build time.

we have btoa in utils-xpc, you can export it. https://github.com/mozilla-b2g/gaia/blob/master/build/utils-xpc.js#L167

and we have getFileAsDataURI for converting to datauri in utils module. https://github.com/mozilla-b2g/gaia/blob/master/build/utils-xpc.js#L157-L169

Comment on attachment 8427144 [details] Patch Changes from comment 42

Comment on attachment 8427144 [details] Patch that's great, thank you!

Master: https://github.com/mozilla-b2g/gaia/commit/8cee6e0e1b8037ec22c010399d7f2d06f3d9b0d2

Reverted for multiple TBPL test bustages. Master: https://github.com/mozilla-b2g/gaia/commit/50940146e7576bb1dfd38b428caffa4227fbc2cd https://tbpl.mozilla.org/php/getParsedLog.php?id=41269663&tree=B2g-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=41269646&tree=B2g-Inbound

I had problems with the 'utils.getFileAsDataURI' during build time. First, travis report an error because different content type than the expected for '.ico' file types in 'build/test/integration/distribution.test.js'. In my laptop the content type returned is 'vnd.microsoft.icon' but the integration environment returns 'image/x-icon'. Then, TBPL failed also due to 'utils.getFileAsDataURI' function in 'apps/browser/build/build.js'. In TBPL environment happened a segmentation fault when trying to get the content type for a '.ico' file at https://github.com/mozilla-b2g/gaia/blob/master/build/utils-xpc.js#L158. Also in my laptop is working fine (ubuntu64). When dealing with '.ico' files 'utils.getFileAsDataURI' depends on the operating system where the build process is running. At run time everything works fine. In order to fix it I converted '.ico' files to '.png', then all goes green.

Comment on attachment 8436453 [details] Patch v2 Fix 'Browser shows the same icon for all single variant topsites'. Just changed data[0].iconUri by topSite.iconUri https://github.com/mozilla-b2g/gaia/pull/20188/files#diff-f7be9381c0825f353c4c8046d30fa35bR67

Travis: https://travis-ci.org/mozilla-b2g/gaia/builds/27051305 TBPL: https://tbpl.mozilla.org/?tree=Try&rev=d4b9ce081747

Comment on attachment 8436453 [details] Patch v2 I think that is a gecko bug, thanks for fixed it with png files and please file a follow up bug for gecko.

Master: https://github.com/mozilla-b2g/gaia/commit/02638038f50c3d98a7ac7a2e9a68ab65581c779c

(In reply to Yuren [:yurenju] from comment #58) > Comment on attachment 8436453 [details] > Patch v2 > > I think that is a gecko bug, thanks for fixed it with png files and please > file a follow up bug for gecko. Created bug 1023054.

All my tests executed in v2.0 with satisfactory results. I will send the test for import into moztrap