Closed Bug 1865975 Opened 2 years ago Closed 2 years ago

v119+ marionette raises sync failure

Categories

(Firefox :: Sync, defect)

Product:
Firefox
Component:
Sync
Version:
Firefox 112
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: kilimra, Unassigned)

Details

Attachments

(1 file)

error-sync-1700610935355.txt
25.63 KB, text/plain
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

I am using V112 and am able to log into my Mozilla account and sync normally.
When I upgraded to v121, I noticed that the sync was failing, although it was still possible to log in to the Mozilla account normally (it just didn't sync).

Actual results:

I tested versions after 112 one by one and found that the problem started with v119 and the reason that triggered it was the "-marionette" in the startup parameter, once this parameter was removed, the Mozilla account synchronized normally.
I checked the update log for v119 and didn't find anything about it.

Expected results:

Synchronizing normally in a marionette environment.

The Bugbug bot thinks this bug should belong to the 'Firefox::Sync' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Sync

Why are you trying to use sync via marionette?

Regardless though, all the errors here are reporting a network failure looking up the sync hosts. It's possible this is a side-effect of using -marionette. If you can help me understand what you are trying to do I might be able to help.

Thank you. Do you mean that if I use marionette to manipulate the page, you will help to achieve the same functionality without marionette, instead of solving this synchronization problem?

I mean that if I can understand why you are using marionette and sync at the same time I might be able to offer some help. Without understanding what you are trying to do I can't predict how exactly I might be able to help.

I don't think marionette has a property conflict with synchronization, it's just a tool to manipulate firefox, no different than using extensions. In fact I use marionette instead of many extensions. It also bridges my global mouse gestures with firefox.

First I want to say that Marionette as part of our WebDriver classic implementation is targeted for website automation and is not a replacement for extensions in Firefox. While WebExtensions are safe to use with Marionette remote execution is possible, which means that every part of the browser can be instrumented. As such we display the robot icon and the striped location bar to make that prominent.

Nevertheless on bug 1821981 we changed a preference (security.remote_settings.intermediates.enabled to false by default) to stop downloading intermediate certificates. Not sure if that could have caused the problem?

It depends on how you look at "automation". If it's automated to be completely unmanned, then it's not automated to use the system mouse gestures to control firefox to close the left tab?
I still can't log in after removing the 1821981 changes.

(In reply to kil from comment #7)

It depends on how you look at "automation". If it's automated to be completely unmanned, then it's not automated to use the system mouse gestures to control firefox to close the left tab?
I still can't log in after removing the 1821981 changes.

To find out what is broken here, it'd probably be helpful if you were able to find a narrower regression window using https://mozilla.github.io/mozregression/ to bisect in the 118-119 range. It's not particularly straightforward for us to mirror your setup to find the issue ourselves, as the failure may be due to particularities in your network or automation environment (presumably you don't "just" run with marionette enabled, and some of the issue may be related to whatever is taking advantage of marionette's API to talk to Firefox).

Flags: needinfo?(kilimra)

Okay, thanks for the advice.
I am very interested in determining two things.
1, with marionette enabled in V119, are you guys synchronizing properly.
2, Is it officially allowed to use sync in a marionette environment.

Flags: needinfo?(kilimra)

(In reply to kil from comment #9)

1, with marionette enabled in V119, are you guys synchronizing properly.

For automation it is advised to turn off all the features that are not crucial, and which could influence performance of tests eg. due to unwanted remote network access. As such we maintain the following list of recommended preferences:

https://searchfox.org/mozilla-central/source/remote/shared/RecommendedPreferences.sys.mjs

And sync is a feature that accesses remote addresses so it should be turned off for a while, at least we didn't land any change for the 119 range as far as I can see.

2, Is it officially allowed to use sync in a marionette environment.

We don't restrict that and users should be able to turn it on by themselves via preferences. Also it's not specifically tested so you can run it on your own risk. Again we strongly do not recommend it for a daily Firefox profile!

I've been using firefox since 2015 and I've been manipulating firefox via AutoHotkey calling marionette.
When I need to manage cookies, 1, install an extension with a super low probability of use, and 2, do it with a few dozen lines of code, via AutoHotkey+marionette. There's no reason why I shouldn't choose the latter.

I really don't understand, nobody sees this feedback as a problem, you guys just keep emphasizing "insecurity" and "risk".

QA Whiteboard: qa-not-actionable

From the log:

1700610935354 Sync.Service DEBUG verifyLogin failed: {"error":{},"errorString":"[Exception... "NS_ERROR_UNKNOWN_HOST" nsresult: "0x804b001e (NS_ERROR_UNKNOWN_HOST)" location: "JS frame :: resource://services-common/rest.sys.mjs :: onStopRequest :: line 479" data: no]","message":null,"code":null,"errno":null}

1700610935354 Services.Common.RESTResponse DEBUG Caught exception processing response headers: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.visitResponseHeaders]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: resource://services-common/rest.sys.mjs :: get headers :: line 663" data: no] Stack trace: get headers()@resource://services-common/rest.sys.mjs:663

Sounds to me like you're using a default set of preferences from marionette that points the sync service to a non-existing or localhost location, which then fails (no sync server there). If you used Firefox with marionette and avoided the "recommended preferences" altogether or overrode the ones for sync back to their "usual" (non-marionette) defaults, off-hand I assume that should work. If it doesn't, presumably the error messages would be different and we could try to look at this.

(In reply to kil from comment #11)

I really don't understand, nobody sees this feedback as a problem, you guys just keep emphasizing "insecurity" and "risk".

Marionette is primarily intended for usecases where browser use is fully automated, for testing frameworks or processing web input or something like that. Less for "I want to script the browser while using it manually". I don't think anyone has talked about "insecurity". The only use of "risk" is around "We don't test for this configuration", and is less to say "this is risky" and more to say "we don't test this kind of setup regularly (unlike "normal" Firefox use and typical marionette full-automation scenarios) so we can't give you any guarantees about what works and what doesn't".

So to be clear, nobody is saying "it's insecure/dangerous to do this". We're just saying, we're not in a good position to help because this isn't a scenario we specifically work towards enabling.

So has anyone tried to reproduce the problem? Starting it once with the "-marionette" parameter is pretty simple, but I don't see anyone trying that because that's not the point, the point of the discussion has always been, why use synchronization in a marionette environment, and whether it makes sense and is necessary.
Seriously, how this feedback deserves attention, please try to reproduce it. Otherwise please close thisissues.

I copied the RecommendedPreferences.sys.mjs file from 118 to 121 and the synchronization became normal.

The severity field is not set for this bug.
:markh, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(markh)

I'm glad you got it working, but using marionette and sync together is unsupported, so I'll close this.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(markh)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: