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)

Product:
Firefox OS Graveyard
Component:
Gaia::Calendar
Platform:
ARM
Gonk (Firefox OS)
Type:
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)

Status:
VERIFIED FIXED
Milestone:
2.1 S6 (10oct)
Project Flags:
blocking-b2g 2.1+
Tracking Flags:
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)

calendar_logcat.txt
386.95 KB, text/plain
Details
bug-1067270.patch
387 bytes, patch
fabrice
: review+
bajaj
: approval-mozilla-aurora+
Details | Diff | Splinter Review
video of verify issue
4.24 MB, video/mp4
Details
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: 1059100 → 1063487
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?]
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted → regression
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
status-b2g-v2.1: fixed → 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.

Attachment

General

Creator:
Created:
Updated:
Size: