1471419 - Firefox 61 fails WPT due to unexpected network requests

Status: RESOLVED FIXED

(Testing :: General, defect)

Description

[Mike Pennisi [:jugglinmike]]

Firefox 61, released as "stable" today, makes unexpected network requests on
startup and fails WPT tests. Here is an example of such a failure:

    pid:16300 FATAL ERROR: Non-local network connections are disabled and a connection attempt to location.services.mozilla.com (52.17.111.251) was made.

Requests like these are expected to be prevented through the use of a custom
"preferences" file [which is retrieved by the `./wpt run`
command](https://github.com/web-platform-tests/wpt/blob/cf0bcea06bb26e51a3315013cbb55936ecd49a62/tools/wptrunner/wptrunner/browsers/firefox.py#L248-L270).
This is no longer working as expected because the layout of the profile
directory (which stores the preferences) has changed in version 61.

This was previously accounted for by bug 1459598. That resolved the problem for
Firefox 61.0 as a "Nightly" release, but now that it has been released on the
"stable" channel, the profiles directory no longer contains the expected
metadata--specifically, a file named `profiles.json`.

The following visualization of the `_venv/profiles` directory demonstrates the
distinction. The `stable/61.0` directory structure clearly differs from the
`stable/60.0.2` directory. However, it is missing the `profiles.json` file that
is present in the profile directory for `nightly/63.0`, which is required by
the patch mentioned above.

    $ tree _venv/profiles/
    _venv/profiles/
    ├── nightly
    │   └── 63.0
    │       ├── common
    │       │   ├── extensions
    │       │   │   └── README.txt
    │       │   └── user.js
    │       ├── moz.build
    │       ├── perf
    │       │   ├── extensions
    │       │   │   └── README.txt
    │       │   └── user.js
    │       ├── profile
    │       ├── profiles.json
    │       ├── raptor
    │       │   ├── extensions
    │       │   │   └── README.txt
    │       │   └── user.js
    │       ├── reftest
    │       │   ├── extensions
    │       │   │   └── README.txt
    │       │   └── user.js
    │       └── unittest
    │           ├── extensions
    │           │   └── README.txt
    │           └── user.js
    └── stable
        ├── 60.0.2
        │   ├── moz.build
        │   └── prefs_general.js
        └── 61.0
            ├── common
            │   ├── extensions
            │   │   └── README.txt
            │   └── user.js
            └── moz.build

Although local experiments suggest that simply using
`stable/61.0/common/user.js` corrects the problem in this case, I expect this
is not a viable solution. The patch in bug 1459598 was designed to support
merging multiple preferences files, and the absence of those files in the
"stable" profiles directory may indicate that we should be fetching a different
profile altogether.

Comment 1

[Mike Pennisi [:jugglinmike]]

I don't know anything about Mozilla's release process and the available
profiles, so I unfortunately can't suggest a solution. Under normal
circumstances, @jgraham would have resolved this before anyone even noticed,
but he's on vacation this week. My next guess would be the author of bug
1459598. Can you help us out, Andrew?

Comment 2

[Andrew Halberstadt [:ahal]]

My apologies. I think I see what happened:

1. When I initially landed the profile directory refactoring, I wasn't aware that prefs_general.js was being used out of context from mozilla-central and broke WPT with nightly.

2. James then temporarily fixed my mistake in https://github.com/web-platform-tests/wpt/pull/10855 by hardcoding the prefs path based on the version of Firefox.

3. I knew that this wouldn't scale (as I had plans to do even more refactoring), so devised the 'profiles.json' mapping so that we could modify or add preference files arbitrarily without needing to worry about breaking WPT in the future. This happened in https://github.com/web-platform-tests/wpt/commit/f88c70300f6bd14122213bcbaefc1743d14ae6e5

Unfortunately in-between steps 2 and 3, Firefox Nightly became version 62. Since my changes (purposefully) clobbered James' original fix, this meant Nightly 61 had neither James' fix in upstream WPT, nor my fix in Firefox 62. This issue will fix itself when 62 becomes stable (but I know waiting isn't an option :)).

To solve this we have two options:
A) Uplift a minimal version of profiles.json to mozilla-release
B) Do the same thing we do for prefs_general.js, except also add common/user.js here:
https://github.com/web-platform-tests/wpt/blob/master/tools/wptrunner/wptrunner/browsers/firefox.py#L252

If you need to get this fixed ASAP, B) is probably your best bet. I'm also not 100% sure A) will work (though pretty sure it will). Either way, let me know what you prefer and I can either help with a review or getting the file uplifted to release.

Comment 3

[Andrew Halberstadt [:ahal]]

Attachment: Fix in WPT

Normally I'd submit a PR, but it's late here and I don't have WPT cloned (nor do I have my phone handy to log into github with 2FA).

So here's the fix in the mozilla-central copy of WPT, feel free to apply this directly to WPT in github. I think it should work, though note that it is untested :).

Comment 4

[Andrew Halberstadt [:ahal]]

Attachment: Fix in WPT

Minor tweak to prevent setting prefs twice.

Comment 5

[Mike Pennisi [:jugglinmike]]

Thank you very much, Andrew! I've submitted your patch to WPT via https://github.com/web-platform-tests/wpt/issues/11679. I don't believe any action is required within Mozilla's infrastructure, so I'll close this bug.

Comment 6

[Andrew Halberstadt [:ahal]]

Np, thanks for getting it landed and sorry for the inconvenience.