592249 - firefox sync breaks gmail

Status: RESOLVED FIXED

(Cloud Services :: General, defect)

Description

[joe]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4) Gecko/20100818 Firefox/4.0b4
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4) Gecko/20100818 Firefox/4.0b4

Issue started after I set up the firefox Sync (using firefox server) after the first sync, gmail stops working properly: when I hit 'send' on a new email it just sits showing 'sending' and stays on that page forever, if i try to go to 'sent mail' it will not go to that page. However if i close out of gmail and go back in it shows that the emails DID send, it just never refreshed the page. I disabled all the addons and uninstalled and reinstalled beta 4 several times,  and gmail works but the issue repeats as soon as I set up and run the sync. I backed up my profile and then uninstalled firefox, reinstalled it and then copied the profile folder into the newly created one and gmail was not affected, but as soon as i set up sync, gmail stopped working properly again.

Reproducible: Always

Steps to Reproduce:
1.set up firefox sync
2.open gmail
3.try to send an email or reply to an email
Actual Results:  
hangs on 'sending' showing the email, never refreshes to go back to inbox and then will not let me navigate to the inbox manually or to any of the folders s.a send etc.

Expected Results:  
refreshed the page and showed the email as sent and taken me back to the inbox screen

I did a full uninstall/reinstall of the beta, used gmail w/o setting up sync and it worked, then set up sync and gmail stopped working. I have reproduced this issue on my computer several times.

Comment 1

[Philipp von Weitershausen [:philikon]]

I can reproduce this. I'm actually witnessing this in my personal browsing profile on Firefox 4.0b4, I always assumed it was a 4.0b4 bug and not related to Sync at all. Taking a fresh profile, however, I see that it works fine until I set up Sync. -- Very very weird.

I tested this with the latest nightly as well and that doesn't exhibit the problem. Can you verify that? If a Sync-related fix did indeed resolve this, it must've been one of

* Bug 587215 - Sync UI: Error notifications aren't displayed
* Bug 587436 - Sync doesn't display last sync time
* Bug 589962 - Sync UI: gBrowser is not defined

all of which don't strike as particularly relevant.

Comment 2

[Ed Lee :Mardak]

Ragavan, I believe you hit this issue running beta 4?

This got fixed on trunk between 08/16 68b886f9b3c3 and 08/17 116f2046b9ef

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=68b886f9b3c3&tochange=116f2046b9ef

Comment 3

[Philipp von Weitershausen [:philikon]]

(In reply to comment #2)
> This got fixed on trunk between 08/16 68b886f9b3c3 and 08/17 116f2046b9ef
> 
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=68b886f9b3c3&tochange=116f2046b9ef

Thanks for finding the, uh, progression range for this :). The only change that seems related to Sync would be bug 552828. It changes/fixes satchel observers notifications. Sync registers such an observer if an account has been set up.

Comment 4

[Ed Lee :Mardak]

Not super urgent, but any idea if bug 552828 would have fixed this problem?

Comment 5

[Ed Lee :Mardak]

Ah yup, it's definitely bug 552828.

hg up -C b51b190b9fcc && make -f client.mk -> FAILURE
hg up -C 116f2046b9ef && make -f client.mk -> SUCCESS

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b51b190b9fcc&tochange=116f2046b9ef

Comment 7

[Sean]

As a question to this issue, is there/will there be a way to disable sync functionality? Can uninstall/reinstall the b4 without any big issues, but in the future I can see a need for sometimes wanting to just disable sync all together.

Comment 8

[Philipp von Weitershausen [:philikon]]

If you don't have Sync set up, it is disabled and has no impact on the rest of Firefox (including this bug found in 4.0b4).

Comment 9

[Sean]

But If I *do* have Sync set up, couldn't there be a way to wholly disable it if I wanted to without Uninstalling/Reinstalling? I ask only out of curiosity, not out of prodding or anger, so sorry if this comes up with a bad tone.

Comment 10

[Philipp von Weitershausen [:philikon]]

(In reply to comment #9)
> But If I *do* have Sync set up, couldn't there be a way to wholly disable it if
> I wanted to without Uninstalling/Reinstalling?

There is. Go to Sync preferences -> Manage Account -> Use a Different Account and choose "Reset All Information". Reinstalling Firefox wouldn't help at all since the Sync prefs are stored in your profile.

Comment 11

[Sean]

Hate to drag this bug report on longer, but thanks for that Philipp!

Comment 12

[Justin Dolske [:Dolske]]

(In reply to comment #4)
> Not super urgent, but any idea if bug 552828 would have fixed this problem?

Baroo? 552828 shouldn't have fixed anything (other than changing things to work with E10S). 

The only thing that comes to mind is that I think that changed things so that more form submission observer code is wrapped in a try/catch, because failures there can cancel the form submission.

So, I suspect that's just masking a Sync failure, it would be good to reproduce with an older build and see what's showing up in the error console (I suppose a newer build should log it too, but I didn't check). Try flipping on browser.formfill.debug to get extra output.

Comment 13

[Philipp von Weitershausen [:philikon]]

I enabled logging for satchel via browser.formfill.debug as well as for the form engine tracker in Sync. The logs didn't reveal any anomaly. Except on recent nightlies (where the problem is fixed) I get this oddball in the error console:

Error: (void 0) is undefined
Source File: resource://services-sync/engines/forms.js
Line: 79

See http://mxr.mozilla.org/services-central/source/fx-sync/services/sync/modules/engines/forms.js#79

Perhaps the query is now failing due to the asynchronous nature of the satchel notifications? According to the logs the tracker tracks the new form data just fine, though. And it's happening with the build that *works*...

Comment 14

[Ed Lee :Mardak]

Nothing too interesting yet, but I noticed this when finding the regression range: it only breaks if you submit a *new* entry i.e. formhistory does an INSERT instead of UPDATE.

failure:

FormAutoComplete: AutoCompleteSearch invoked. Search is: hi9
FormAutoComplete: Creating new autocomplete search result.
FormAutoComplete: AutoCompleteSearch invoked. Search is: hi99
FormAutoComplete: Using previous autocomplete result
FormHistory: Form submit observer notified.
FormHistory: addEntry for subject=hi99
FormHistory: Creating new statement for query: SELECT id, guid FROM moz_formhistory WHERE fieldname = :fieldname AND value = :value
FormHistory: Creating new statement for query: INSERT INTO moz_formhistory (fieldname, value, timesUsed, firstUsed, lastUsed, guid) VALUES (:fieldname, :value, :timesUsed, :firstUsed, :lastUsed, :guid)

success:

FormAutoComplete: AutoCompleteSearch invoked. Search is: hi9
FormAutoComplete: Using previous autocomplete result
FormAutoComplete: Reusing autocomplete entry 'hi9' (25 / 750)
FormAutoComplete: Reusing autocomplete entry 'hi99' (25 / 750)
FormAutoComplete: AutoCompleteSearch invoked. Search is: hi99
FormAutoComplete: Using previous autocomplete result
FormAutoComplete: Reusing autocomplete entry 'hi99' (25 / 750)
FormHistory: Form submit observer notified.
FormHistory: addEntry for subject=hi99
FormHistory: Creating new statement for query: SELECT id, guid FROM moz_formhistory WHERE fieldname = :fieldname AND value = :value
FormHistory: Creating new statement for query: UPDATE moz_formhistory SET timesUsed = timesUsed + 1, lastUsed = :lastUsed WHERE id = :id
FormHistory: Form submit observer notified.

Comment 15

[Justin Dolske [:Dolske]]

Hmm, I wonder if there could be oddness from us sending the notifications from within a transaction. That hasn't changed, though. Hopefully not, because it would be a bit of a pain to separate the addEntry() calls from the notification sending. Maybe a new, not-not-yet-invented nsIFormHistory3 needs a way to allow adding multiple values with a single API call.

I suppose you could test that theory by removing the transaction from nsFormHistory's receiveMessage(). It's only there for performance reasons.

Comment 16

[Philipp von Weitershausen [:philikon]]

(In reply to comment #13)
> Error: (void 0) is undefined
> Source File: resource://services-sync/engines/forms.js
> Line: 79

Filed bug 597400 for this.