1589833 - [conditioned-profile] Document Firefox profile-version-mismatch error

Status: RESOLVED WORKSFORME

(Testing :: Raptor, task, P2)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: firefox profile-version error-dialog screenshot

Summary: Investigate and fix/address Firefox profile-version-mismatch error

I don't actually know at this point whether it's my (mis)-use of code, or a genuine issue to be addressed in a lower level, but we need to get this unblocked.

With my current (and otherwise running + passing test, pending this issue) proposed patch for bug 1537944 (which I'll attach once I can submit to Phab viz moz-phab, again...), I get the following Firefox profile-version mismatch error/warning dialog (see 1st attached screenshot), which is complaining under the hood about user_pref("browser.migration.version", 87); in the post-merged conditioned-profile'sprefs.js` (see 2nd attached screenshot).

This emanates from https://searchfox.org/mozilla-central/rev/696cf3b52a9aa04aa5013008a8b448904a298356/browser/components/BrowserGlue.jsm#2758-2779.

Per https://groups.google.com/forum/#!msg/mozilla.dev.platform/N1atxmAOlrE/CIa9Djc0AwAJ, and my own testing, setting environment variable via export MOZ_ALLOW_DOWNGRADE bypasses this check and permits all tests to run (per shell instance, unless you set it globally), after which they all currently pass.

So far, I've tested (full suites too, just used these for brevity):
./mach raptor-test --test raptor-tp6-1-cold --page-cycles 1 --browser-cycles 1
./mach raptor -t raptor-tp6-1 --page-cycles 1 --browser-cycles 1
./mach raptor -t raptor-speedometer

They are all affected (understandably) and "fixed" by setting that, but that's obviously not a solution, or even a stopgap I'd want in-tree, so we need to fix it/figure it out.

Suggestions for where to poke further are welcome, in case anyone beats me to it.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: sleuthing

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

So, from what I've gathered so far, I think we have a few viable options (with varying degrees of difficulty/scope, and likely preference):

1. read in the prefs.js file containing user_pref("browser.migration.version", 87) and either:
   a) set it to 9999999, which has precedent in other in-tree tests: https://searchfox.org/mozilla-central/search?q=browser.migration.version%3D9999999&case=false&regexp=false&path=
   b) delete that pref entirely, like is currently done in Browsertime to remove mozprofile's delimiters, in Raptor.py: https://searchfox.org/mozilla-central/rev/088e2cf29c59d733d57af43903eb0267dbf72e2a/testing/raptor/raptor/raptor.py#369-383
2. add a new, passed-in --allow-downgrade argument to Raptor (as a default in https://searchfox.org/mozilla-central/rev/088e2cf29c59d733d57af43903eb0267dbf72e2a/taskcluster/ci/test/raptor.yml, since this affects both cold and warm page-load paths?)
3. somewhere, set the environment variable MOZ_ALLOW_DOWNGRADE=1?

Are there other options I'm missing?

Comment 3

[Robert Wood [:rwood]]

Hey Stephen, is this issue still a P1/actively being worked on? Thanks :)

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Robert Wood [:rwood] from comment #3)

Hey Stephen, is this issue still a P1/actively being worked on? Thanks :)

We'll need to document this for the local-testing case, but after talking with Tarek, I don't believe this will affect CI, nor will we need to add code to Raptor or harnesses to work-around this.

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

Updating summary and changing to a task, rather than defect, to reflect the above.

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

Looking back through gists of mine from (much) earlier hacking attempts (now that conditioned-profile has landed on desktop for both Raptor and Browsertime for Firefox), I realized that it's a resulting artifact/problem of me trying, back then, to delete the temp file for the downloaded profile, which I now do here: https://searchfox.org/mozilla-central/rev/04d8e7629354bab9e6a285183e763410860c5006/testing/raptor/raptor/raptor.py#203.

While there is still further cleanup work to go, this isn't a problem, even locally now, with my development setup - closing out. If it resurfaces, I'll happily document a specific context (for landed code).