Closed Bug 1538106 Opened 6 years ago Closed 6 years ago

RTAMO about:welcome page is not shown on first run when using a fresh virtual machine

Categories

(WebExtensions :: General, defect, P1)

Product:
WebExtensions
Component:
General
Version:
66 Branch
Platform:
Desktop
Unspecified
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: vlad.jiman, Assigned: andreio)

References

Details

Using a fresh instance of Windows 10 on a virtual machine we're not getting the expected about:welcome RTAMO page after downloading the Stable version of Fx 66. Also the postSigningData is not present in Appdata\Mozilla.

Steps to reproduce:

  1. Go to addons.mozilla.org and search for Ghostery extension or another one which is whitelisted.
  2. Click 'Only with Firefox' to download
  3. Install it using a machine that did not have Firefox on it prior to this

Expected:
First run should start RTAMO - ghostery

Actual:
Old about:welcome screen is shown.

Note: This was not reproducible on our test machines, only on Windows 10 virtual ones.

Have you noticed any issues related to this? I can fire up a Win VM but I'm not sure what to look for if postSigningData is not present.

Flags: needinfo?(mixedpuppy)

As long as the postSigningData file is there, and has the right data, then you could run the scripts we used on other related bugs to verify the data can be fetched. Beyond that, someone else would need to chime in.

One thing of note, when you download firefox, be sure that you have no mozilla cookies. Easiest way to do this is to run a browser in private mode. Otherwise the download server (or something in the process) remembers that it gave you the data in a prior download, and wont give you new data.

Flags: needinfo?(mixedpuppy)

Shane, when downloading Firefox I've used Edge in private mode, Lexa also confirmed this behavior on a different VM.

Priority: -- → P2

Marking as P1 until we know what's going on here (thank you, Andrei).

Priority: P2 → P1
Has STR: --- → yes

Update: The issue is reproducing on our local machines as well now, not only VM's, while reproducing it's important to remove the postSigningData and let the installer add it if possible.

This is happening due to a change on the bedrock attribution service side, which is currently (erroneously) not propagating utm parameters (resulting in no attribution) if utm_content is set at all. This should be resolved soon.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.