https-everywhere icon indicating copy to clipboard operation
https-everywhere copied to clipboard

Firefox Sync failure (TypeError: json is null)

Open Xiyng opened this issue 7 years ago • 6 comments

Type: code issue

Sometimes, Firefox Sync fails with the following error message (from the sync log file):

Sync.Engine.Extension-Storage	ERROR	Syncing [email protected]: request failed: TypeError: json is null (resource://services-common/kinto-http-client.js:838:9) JS Stack trace: [email protected]:838:9 < [email protected]:851:12

This seems to usually happen several times before going away at some point and working just fine for some time. Typically, the duration of the problem is at least hours, possibly days (I haven't kept track accurately).

Xiyng avatar Jan 11 '18 21:01 Xiyng

Does this actually cause HTTPS Everywhere to not function? Offhand it looks like a Firefox bug.

strugee avatar Feb 20 '18 03:02 strugee

I haven't actually tested whether this affects HTTPS Everywhere's functionality, but it sounds like it's caused by a null value from HTTPS Everywhere, breaking Firefox's sync functionality. To me, this kind of sounds like a bug with HTTP Everywhere and a design flaw or a bug with Firefox. It sounds like HTTPS Everywhere is, in some situation, trying to pass null somewhere it shouldn't, which would make it a bug in HTTPS Everywhere if that's actually the case.

Xiyng avatar Feb 20 '18 18:02 Xiyng

@Xiyng lol, sorry I forgot about this issue.

I am 99.99% sure this is a bug in Firefox Sync code. Certainly the stack trace is coming from there (here's the relevant file in the Mozilla tree). AFAIK there really should be no situation in which the Sync engine is directly calling into HTTPS Everywhere code, which is the only situation in which HTTPS Everywhere passing null would trigger something like this. Plus handleResponse is probably handling some HTTP response from the Sync server which would have nothing to do with HTTPS Everywhere.

I feel very very confident that this is not a bug in HTTPS Everywhere and can be closed.

strugee avatar Mar 07 '18 00:03 strugee

@strugee Heh, no problem. At any rate, even if this is a bug in Firefox Sync, it sounds like the problem could potentially be evaded with what's probably a small change in HTTPS Everywhere, improving the user experience for HTTPS Everywhere users. Of course this is all assuming that some value set by HTTPS Everywhere is what Firefox Sync can't handle.

I agree this sounds like it's more of an issue with Firefox Sync though, but I just want to point out that it's not like it doesn't seems like this particular instance of this issue can't be fixed in HTTPS Eveywhere either. I don't particularly care which decision gets made here, but I think this is nevertheless a valid point to consider.

That said, I haven't encountered the problem again in a while, so it's possible it's already fixed in Firefox Sync. Either way, it's not exactly a huge problem anyway.

Xiyng avatar Mar 07 '18 00:03 Xiyng

@Xiyng so, again, I'm clearly not an expert in Firefox Sync internals but looking at the function the error comes from, it's handling a response from a server. It seems pretty clear to me that something in the Sync server's response is triggering this error. Not something in HTTPS Everywhere.

strugee avatar Mar 07 '18 15:03 strugee

@stugee Oops, I forgot to answer. Anyway I didn't look at the sync code so I'm obviously not qualified to make any claims about what it does or doesn't. I just wanted to offer one point of view to this issue, which is that it might be possible to find a workaround in HTTPS Everywhere even if this is actually a Firefox Sync issue. I don't know if it's possible, and if it is something that can't really be fixed in HTTPS Everywhere, so be it.

Xiyng avatar Mar 12 '18 17:03 Xiyng