Closed Bug 1691431 Opened 8 months ago Closed 7 months ago

Differences in Remote Settings top-sites order with dump false / true


(Firefox :: Top Sites, defect)

Firefox 87



Tracking Status
firefox85 --- disabled
firefox86 --- disabled
firefox87 --- verified


(Reporter: aflorinescu, Unassigned)


(Blocks 2 open bugs)


(Whiteboard: fixed by 1691478)


Windows 10
87.0a1 20210208092848


Running new profile with services.settings.load_dump false produce different results that running it with services.settings.load_dump true. This has been noted to happen only when there's a search shortcut involved in the default topsites (amazon).


Since production environment has the dump true on default, this report might end to be a low severity/priority, however the concern would be that this behavior suggests that it might be a different code-path that is triggered when data is taken from dump vs when it's updated from RS pipeline. This might have possible unwanted behaviours when updating from RS directly.

  1. Download Firefox en-US
  2. Create two profiles and do not initialize them.
  3. In 1st profile folder place an user.js that has: user_pref("services.settings.load_dump", false);
  4. Second profile has services.settings.load_dump to true, so no user.js is needed.
  5. Start Firefox with both profiles and compare the results.
[Actual Result:]

The topsites order for dump-false profile is:
1)Youtube , 2), 3)Facebook, 4)Reddit, 5)wikipedia, 6)Twitter

The topsites order for dump-true profile is:
1), 2)Youtube, 3)Facebook, 4)Reddit, 5)wikipedia, 6)Twitter

[Expected Result:]

Dump true or false should make no difference in the topsites order.

  1. Interesting enough, for the dump false, when you change the default search engine from google to something else (let's say bing), the @google search shortcut would be inserted in the topsites, but this will also cause the topsites to get arraged correctly:
    1), 2)google(shortcut), 3)Youtube, 4)Facebook, 5)Reddit, 6)wikipedia, 7)Twitter

I think bug 1691478 may have fixed this. Adrian, could you please check?

Blocks: 1690537
Depends on: 1691478
Flags: needinfo?(adrian.florinescu)

(In reply to Dão Gottwald [::dao] from comment #1)

I think bug 1691478 may have fixed this. Adrian, could you please check?

Will do as soon as soon as I get a Nightly with the fix.

Flags: needinfo?(adrian.florinescu)
Flags: needinfo?(adrian.florinescu)

Verified as fixed on 87.0a1 2021-02-12.
Leaving the NI still active and not marking as verified until we cover mac and ubuntu also + adding a test for this kind of scenario.

Closed: 7 months ago
Flags: in-qa-testsuite?(adrian.florinescu)
Resolution: --- → FIXED
Whiteboard: fixed by 1691478
Flags: needinfo?(adrian.florinescu)
Flags: in-qa-testsuite?(adrian.florinescu)
Flags: in-qa-testsuite+

Excluding the scenario in which the dump and the RS data is not synced, this issue is verified on 87.0b9 containing the fix for bug 1696187.

You need to log in before you can comment on or make changes to this bug.