1477338 - Sync fails silently

Status: RESOLVED DUPLICATE of bug 1474201

(Firefox :: Sync, defect)

Description

[Yuri Khan]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180716192826

Steps to reproduce:

1. Unknowingly have IP addresses corresponding to some of *.sync.services.mozilla.com blocked by your provider at request of your government in a futile attempt to censor an unrelated piece of software.
2. Expect Sync to just work as usual.


Actual results:

After wondering for a few days why bookmarks do not sync and then looking at about:sync-log, I found this:

GET request to https://sync-588-us-west-2.sync.services.mozilla.com/1.5/89978324/info/collections failed: [Exception... "The connection has timed out"  nsresult: "0x804b000e (NS_ERROR_NET_TIMEOUT)"  location: "<unknown>"  data: no] No traceback available


Expected results:

As soon as Sync encountered a network error when talking to a storage server, Firefox should have reported the error in an unobtrusive but visible way. (Doorhanger on sandwich button would be good.)

Comment 1

[Mark Hammond [:markh] [:mhammond]]

Thanks for the report - we are tracking this issue in bug 1474201

Comment 2

[Yuri Khan]

(In reply to Mark Hammond [:markh] from comment #1)
> Thanks for the report - we are tracking this issue in bug 1474201

I don’t think so. That issue is about blocking as such, and what can be done to circumvent it. This issue is about failing loudly instead of silently.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

(In reply to Yuri Khan from comment #2)
> (In reply to Mark Hammond [:markh] from comment #1)
> > Thanks for the report - we are tracking this issue in bug 1474201
> 
> I don’t think so. That issue is about blocking as such, and what can be done
> to circumvent it. This issue is about failing loudly instead of silently.

They are related - if we work out a way to mitigate the blocking, we will not need to fail loudly. Failing loudly is probably the least-preferred option as it's unclear what a good UI is for this - we can show a doorhanger, but then what? What will we suggest the user do? We'd almost certainly also need to do something smarter than "network errors for a few days" - how can we tell a local network error that will resolve itself at some point vs a permanent failure? It would be a very bad outcome to give the user scary messages with no suggestion for fixing the issue if it's a false-positive.

Comment 4

[Yuri Khan]

(In reply to Mark Hammond [:markh] from comment #3)
> What will we suggest the user do?

What do you suggest the user do when they go to an HTTPS web site and it times out?

> The connection has timed out
>
> The server at 123.45.67.89 is taking too long to respond.
>
> * The site could be temporarily unavailable or too busy. Try again in a few moments.
> * If you are unable to load any pages, check your computer’s network connection.
> * If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.

In case of Sync servers, the messages could be made more specific but generally these same recommendations would have the same level of helpfulness.


For me, Sync failed silently at home but worked just fine at work (as the ISP at my job is less fervent in following the blocking orders). So when I noticed missing bookmarks, I could not determine the cause of the problem right then and there. If I got a connection timeout message at the first failed sync, I could have fixed it immediately.

Comment 5

[Mark Hammond [:markh] [:mhammond]]

(In reply to Yuri Khan from comment #4)
> (In reply to Mark Hammond [:markh] from comment #3)
> > What will we suggest the user do?
> 
> What do you suggest the user do when they go to an HTTPS web site and it
> times out?

When the https sync server times out? We suggest nothing and show no UI.

> In case of Sync servers, the messages could be made more specific but
> generally these same recommendations would have the same level of
> helpfulness.

I disagree and our UX team disagrees. We show nothing.

> For me, Sync failed silently at home but worked just fine at work (as the
> ISP at my job is less fervent in following the blocking orders). So when I
> noticed missing bookmarks, I could not determine the cause of the problem
> right then and there. If I got a connection timeout message at the first
> failed sync, I could have fixed it immediately.

I'm sorry to hear that, but there is no way we are going to start showing UI on the first failed sync.

Also, if you could have fixed it immediately, please update bug 1474201 with how - there are a few people in that bug who would love to know.

Comment 6

[Yuri Khan]

(In reply to Mark Hammond [:markh] from comment #5)

> I disagree and our UX team disagrees. We show nothing.

> there is no way we are going to start showing UI on the first failed sync.

This is not a helpful response. I would like to see a convincing argument why connection errors have to be hidden.

Comment 7

[Mark Hammond [:markh] [:mhammond]]

There are many years of history around error UI for sync with ample evidence that such UI is bad for most users. Please also consider the fact that you are raising this because of a country-wide block that the average user in that country is unable to resolve with or without UI. I understand you may not find this convincing, but there's not much I can do to help with that.

Comment 8

[Yuri Khan]

(In reply to Mark Hammond [:markh] from comment #7)

> Please also consider the fact that you
> are raising this because of a country-wide block that the average user in
> that country is unable to resolve with or without UI.

Those who are unable to resolve this problem have two options.

With silent failure, they will blame Firefox for broken sync, and some will migrate to other browsers.

With loud failure, they will blame the government for breaking Firefox sync. Some will learn to evade blocking. Some will migrate to other governments.

I find the latter outcome more desirable.

> I understand you may
> not find this convincing, but there's not much I can do to help with that.

You could help with that by pointing me to a published article that summarizes the aforementioned ample evidence.

What about showing error UI on explicit actions, such as “Tools|Sync Now” and “Sandwich|Two Semicircular Arrows”? Maybe just coloring the Two Semicircular Arrows icon red if last sync failed?