Closed Bug 1067270 Opened 10 years ago Closed 10 years ago

[Calendar] Add Google calendar via OAUTH always show something wrong.

Categories

(Firefox OS Graveyard :: Gaia::Calendar, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.1+, firefox33 wontfix, firefox34 fixed, firefox35 fixed, b2g-v1.4 unaffected, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 fixed)

VERIFIED FIXED
2.1 S6 (10oct)
blocking-b2g 2.1+
Tracking Status
firefox33 --- wontfix
firefox34 --- fixed
firefox35 --- fixed
b2g-v1.4 --- unaffected
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- fixed

People

(Reporter: edchen, Assigned: gaye)

References

Details

(Keywords: regression, Whiteboard: [spdy])

Attachments

(3 files)

Attached file calendar_logcat.txt
[Device]
Flame

[Environment]
Gaia      944e5b4582c4efa1b67cd33245dbb8f6aa25d09f
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/7546fedad918
BuildID   20140914160203
Version   34.0a2
ro.build.date   Fri Jun 27 15:57:58 CST 2014
ro.bootloader   L1TC00011230
ro.build.version.incremental   110


[STR]
1. Launch calendar
2. Tap drop down menu 
3. Tap setting icon
4. Tap add account
5. Tap Google
6. Enter account/ password after OAUTH page is displayed
7. Show "something wrong"

[Attachment]
calendar_logcat.txt
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
Component: Gaia::E-Mail → Gaia::Calendar
i can reproduce also on google account.   did bug 1059100 regress this?   

Repro
1) install 2.1 mozilla aurora on Flame KK image

Gaia      944e5b4582c4efa1b67cd33245dbb8f6aa25d09f
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/7546fedad918
BuildID   20140914183011
Version   34.0a2
ro.build.date   Sun Sep 14 23:38:55 EDT 2014
ro.bootloader   L1TC10011800
ro.build.version.incremental   eng.cltbld.20140914.233843

2) launch Calendar, select Gmail, and add an account
3) after entering google credentials, validate the Mozilla Firefox OS note of having offline access
4) hit accept, and verify the "Something is wrong" note.

my logcat is similar to the one attached.
Blocks: 1059100
Keywords: qaurgent
No longer blocks: 1059100
See Also: → 1059100
Clearing the QA Urgent keyword - the keyword needs to be used in conjunction with another keyword to have meaning.
Keywords: qaurgent
QA Wanted for branch checks.
Keywords: qawanted
(In reply to Tony Chung [:tchung] from comment #2)
> i can reproduce also on google account.   did bug 1059100 regress this?   

No.  There is no interaction between email and calendar and I have confirmed that our Google OAuth credentials for Calendar remain intact via the console.  Bug 1063487 recently fixed Calendar OAuth, so it is a good thing to blame, or just a thing that could have been hiding other code regressions since you can't see a regression if you can't add the account, etc. etc.
See Also: 10591001063487
Assignee: nobody → gaye
When I tried to repro earlier tonight, I got a 400 Bad Request response with the following body from https://apidata.googleusercontent.com/caldav/v2/ after authenticating with oauth:


<html><title>Error 400 (Bad Request)!!1</title></html>

This is a bug (or perhaps a change) on google's end. Sent an email to a google calendar developer and waiting on a response..
major regression. Needs to fix
blocking-b2g: 2.1? → 2.1+
Target Milestone: --- → 2.1 S5 (26sep)
QA Contact: edchen → aalldredge
This issue occurs on 2.2 Flame and 2.1 Flame.

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20140916162300
Gaia: 50666fa8bbbf3d346faff24f92ad8140a44a49d0
Gecko: 49ef7b18963d
Version: 35.0a1 (2.2 Master)
Firmware: v165
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Device: Flame 2.1
BuildID: 20140917092802
Gaia: 987645cd189790e27ceb49497028ed32e8d00c90
Gecko: 9a8082b71c95
Version: 34.0a2 (2.1)
Firmware: v165
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Result:
"something is wrong" message is displayed after OAUTH page.

----------------------------------------------------------
This issue does not occur on 2.2 Open_C, 2.0 Flame, or 1.4 Flame.


Environmental Variables:
Device: Open_C 2.2 Master
BuildID: 20140917114258
Gaia: 72262d054ffa5d0d2b5a0033f713149281511aea
Gecko: d2c01d77b9d0
Version: 35.0a1 (2.2 Master)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Device: Flame 2.0
BuildID: 20140917073857
Gaia: 31434a3949556171f3565ca47ac2b44e810e95e6
Gecko: e02fe140c0d5
Version: 32.0 (2.0)
Firmware: v165
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 1.4 (Base)
BuildID: 20140814202332
Firmware: v165
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Result:
User is able to sign in successfully.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [COM=Gaia::Calendar][QAnalyst-Triage+]
This is still happening on 2.1 and master. Gareth, can you provide an update on what's happening with Google?
Flags: needinfo?(gaye)
Google calendar developer says he cannot reproduce... still digging...
Flags: needinfo?(gaye)
Google calendar developer asked me to create a fake account, reproduce, and send him credentials which I went ahead and did. Waiting for news / followup..
See Also: → 1059074
After some amazing help from :asuth, I have a fix here (or at least a root cause). Setting

user_pref("network.http.spdy.enabled.http2draft", false);

in prefs.js fixes the issue on both master and 2.1. While investigating, I noticed that Google was responding to our various sync requests with gobbledygook. I figured this was an application-level, google calendar server issue and followed up with a developer there. After some back-and-forth, we both felt that there was nothing outstandingly wrong with what we thought we were sending each other. It turns out, there is a networking issue since Google is sending us back the caldav data over SPDY and the network layer isn't properly reconstructing the traffic from Google into what the calendar application is expecting (a lot of xml). Going to triage accordingly and also needinfo people that :asuth suggested would be in the know.
Flags: needinfo?(mcmanus)
Flags: needinfo?(hurley)
Whiteboard: spdy
it appears google.com has some DAV problems with h2-14 - see 1068950 comment 10
Flags: needinfo?(mcmanus)
Whiteboard: spdy → [spdy]
Hi Gareth,

This might be a Gecko issue.

After we enabled http2 and alpn in this[1] commit, then we had this bug.
I also could not reproduce this bug after Gecko is without the commit[1].

And I think this bug might be duplicated of Bug 1068950.

[1] http://hg.mozilla.org/mozilla-central/rev/72f85a52a2ca
Oh, thanks for Patrick's explanation.
Depends on: 1072525
Flags: needinfo?(hurley)
Target Milestone: 2.1 S5 (26sep) → 2.1 S6 (10oct)
So the plan is to turn off the pref for http2 for b2g 2.1. I'm going to send a patch to apply that pref to the b2g prefs file in mozilla-central and fabrice has kindly offered to review.
Hey Fabrice,

Here's the patch we were talking about to pref off http2 in b2g 2.1. Thanks for your help with this!
Attachment #8503250 - Flags: review?(fabrice)
I'm not that up to date on b2g release management details.. does this patch just apply to 2.1 or to all b2g until changed or something else?

the h2 support you're running is for a draft protocol. If a server implementation is giving you the blues, turning it off is reasonable in the interim.

I just want to make sure that it is back on for b2g when we hit the final revision of h2.. which ought to be in the next few weeks. because the imapct of your patch goes way beyond google calendaring, and h2 is meant to be extremely well suited to the b2g use case because of how it deals with higher latency connections.
(In reply to Patrick McManus [:mcmanus] from comment #21)
> I'm not that up to date on b2g release management details.. does this patch
> just apply to 2.1 or to all b2g until changed or something else?
> 
> the h2 support you're running is for a draft protocol. If a server
> implementation is giving you the blues, turning it off is reasonable in the
> interim.
> 
> I just want to make sure that it is back on for b2g when we hit the final
> revision of h2.. which ought to be in the next few weeks. because the imapct
> of your patch goes way beyond google calendaring, and h2 is meant to be
> extremely well suited to the b2g use case because of how it deals with
> higher latency connections.

Ok. If we land that patch it will be on m-c (currently b2g 2.2) and we'll uplift to 2.1.
We will keep it disabled on 2.1, and re-enable on m-c once h2 is final.
Comment on attachment 8503250 [details] [diff] [review]
bug-1067270.patch

Review of attachment 8503250 [details] [diff] [review]:
-----------------------------------------------------------------

Gareth, can you file a bug to re-enable that once h2 is final?
Attachment #8503250 - Flags: review?(fabrice) → review+
Comment on attachment 8503250 [details] [diff] [review]
bug-1067270.patch

Approval Request Comment
[Feature/regressing bug #]: HTTP2 support
[User impact if declined]: Google calendar via OAUTH doesn't work anymore
[Describe test coverage new/current, TBPL]:
[Risks and why]: No risk, we revert a previous change. It's a bit sad to have to disable globally when a single provider breaks us, but we have no choice for 2.1
[String/UUID change made/needed]: None
Attachment #8503250 - Flags: approval-mozilla-aurora?
Gareth, can you format your patch to be pushed on hg? thanks!
Comment on attachment 8503250 [details] [diff] [review]
bug-1067270.patch

Approving and NI :fabrice for the hg patch.
Attachment #8503250 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Flags: needinfo?(fabrice)
Flags: needinfo?(fabrice)
https://hg.mozilla.org/mozilla-central/rev/bd568cea1478
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Will file a bug to re-enable h2 and thank you Fabrice for pushing to hg!
[Environment]
Gaia-Rev        d51956f84ebec0dd8998654f01f9f24fe8527f51
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/a0647b2686eb
Build-ID        20141013161204
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20140925.192608
FW-Date         Thu Sep 25 19:26:18 EDT 2014
Bootloader      L1TC10011800


[Result]
PASS
Status: RESOLVED → VERIFIED
Attached video video of verify issue
This issue can't repro on Flame 2.1
See attachment: verify_video.mp4
Reproducing rate: 0/5
Flame 2.1 versions:
Gaia-Rev        1b231b87aad384842dfc79614b2a9ca68a4b4ff3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/95fbd7635152
Build-ID        20141118001204
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141118.035447
FW-Date         Tue Nov 18 03:54:58 EST 2014
Bootloader      L1TC00011880
(In reply to Gareth Aye [:gaye] from comment #30)
> Will file a bug to re-enable h2 and thank you Fabrice for pushing to hg!

I can't find this bug.. is it out there?

I believe bug 1128038 is the root cause here and it has been fixed, so the re-enabling can commence.
Flags: needinfo?(gaye)
(In reply to Patrick McManus [:mcmanus] from comment #34)
> (In reply to Gareth Aye [:gaye] from comment #30)
> > Will file a bug to re-enable h2 and thank you Fabrice for pushing to hg!
> 
> I can't find this bug.. is it out there?
> 
> I believe bug 1128038 is the root cause here and it has been fixed, so the
> re-enabling can commence.

I did that in bug 1132830
Flags: needinfo?(gaye)
You need to log in before you can comment on or make changes to this bug.