Closed Bug 1209275 Opened 4 years ago Closed 4 years ago

Week/day view. Wrong time is displayed while a user adds a new event

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)

VERIFIED FIXED
blocking-b2g 2.5+
Tracking Status
b2g-v2.2 --- unaffected
b2g-master --- verified

People

(Reporter: MaxIvanov, Assigned: gaye)

References

()

Details

(Keywords: regression, Whiteboard: [2.5-Daily-Testing][Spark])

Attachments

(4 files)

Description:
When a user adds a new event in Week or Day mode they specify a time when the event will start just tapping on appropriate hours.But whatever time user choose it will show them start time at 08:00 or 15:00.

Repro Steps:
1) Update a Aries to 20150928133112
2) Open the Calendar app
3) Tap on the Week button
4) Double tap on any date and time
5) Observe the event starting time

Actual:
The event start time 8:00 or 15:00

Expected:
The event start time according to the selected by user

Environmental Variables:
Device: Aries Master
Build ID: 20150928133112
Gaia: 01ffe82cf088ca8fda9fe6783dc5cad2c3dde01c
Gecko: 031db40e2b558c7e4dd0b4c565db4a992c1627c8
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (Master)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Repro frequency: (10/10)
See attached: (video clip, logcat)
https://youtu.be/8jsUgFmU3IA
This issue DOES occur on Aries 2.5 and Flame 2.5 and NOT on Flame 2.2 
Result: The event start time 8:00 or 15:00

Device: Aries Master
Build ID: 20150928133112
Gaia: 01ffe82cf088ca8fda9fe6783dc5cad2c3dde01c
Gecko: 031db40e2b558c7e4dd0b4c565db4a992c1627c8
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (Master)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44
--------------------------------------------------------------------

Device: Flame Master
Build ID: 20150928030224
Gaia: 285486b417f1cb8316b19c0698a6655fc053fbd6
Gecko: 6256ec9113c115141aab089c45ee69438884b680
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (Master)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
---------------------------------------------------------------------

Device: Flame 2.2
Build ID: 20150923003003
Gaia: 5dd95cfb9f1d6501ce0e34414596ef3dd9c2f583
Gecko: 65ddad73ad6b
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regression
Whiteboard: [2.5-Daily-Testing][Spark]
Attached file logs.txt
Let's check the regression window found for bug 1209304 to see if this is the same issue.
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
blocking-b2g: 2.5? → 2.5+
Priority: -- → P2
Assignee: nobody → gaye
Duplicate of this bug: 1209304
Copied from commit message:

This fixes a regression introduced in f13c650. In that patch, we changed calendar's url scheme to use url fragments so that we could prevent our client-side routing from breaking view source (which expects each url to correspond to an HTML file). However, event creation was using urls (particularly location.search ie ?startDate=...&endDate=...&startTime=...&endDate=...&title=...). The pref we flipped on page.js (hashbang = true) to enable the fragment usage made it so that our urls for event creation now look like http://calendar.gaiamobile.org/index.html/#!/event/add/?startDate=09-29-15. We were using location.search previously to access the urlparams which only looks for urlparams which come before the # (which indicates the start of the fragment id location.hash). With our new url scheme, these parameters weren't being picked up, so calendar ignored the url and assumed that all events should be created starting at the top of the next hour. The change here modifies the way that we pull the querystring so that we don't ignore those event parameters.
Attachment #8667390 - Flags: review?(jrburke)
Comment on attachment 8667390 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/32109

Looking at location.hash on MDN:
https://developer.mozilla.org/en-US/docs/Web/API/URLUtils/hash

It used to auto-URL decode (undesirable), but the bug related to that issue was fixed just this June, and trying in 42.0a seems to retain the URL encoding. So that should be OK as long as calendar runs on a version of Gecko since that fix.

Part of me feels like the ? in the fragment ID should also be encoded, as it gets confusing to parse when there is an actual querystring. It works out since querstrings needs to occur before the #fragmentId in URLs, so the browser and newURL are not confused. However, leaving that alone as I am not sure how that affects URL generation in calendar.

I have not tested this, just going on inspection and that you tried it in dev to prove it has been solved.
Attachment #8667390 - Flags: review?(jrburke) → review+
Duplicate of this bug: 1209304
B2g Inbound Regression Window

Last Working
Environmental Variables:
Device: Flame 2.5
BuildID: 20150917152754
Gaia: 750334a998ffc4b2d29fbd04e394d8cdd14fd29c
Gecko: fc7b5864d8f528131f3a1b89b850eb0a82037b72
Version: 43.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

First Broken
Environmental Variables:
Device: Flame 2.5
BuildID: 20150917154053
Gaia: f13c650f765d0df385f9a7cb0b4bf2eb8b666fe4
Gecko: a2cdbc280c4e039bce305d6b1bf7458d74a154b0
Version: 43.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Last Working gaia / First Broken gecko - This issue does NOT occur with broken gecko.
Gaia: 750334a998ffc4b2d29fbd04e394d8cdd14fd29c
Gecko: a2cdbc280c4e039bce305d6b1bf7458d74a154b0

Last Working gecko / First Broken gaia - This issue DOES occur with broken gaia.
Gecko: fc7b5864d8f528131f3a1b89b850eb0a82037b72
Gaia: f13c650f765d0df385f9a7cb0b4bf2eb8b666fe4

B2G Inbound Pushlog: 
https://github.com/mozilla-b2g/gaia/compare/750334a998ffc4b2d29fbd04e394d8cdd14fd29c...f13c650f765d0df385f9a7cb0b4bf2eb8b666fe4

This issue is caused by Bug 1204002
Blocks: 1204002
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Thanks for review James! Landed on master https://github.com/mozilla-b2g/gaia/commit/dc08670f216fc9bc13568f74db8550035c055f14
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jmercado)
Resolution: --- → FIXED
This bug has been verified as "pass" on the latest build of Flame KK 2.5 and Aires KK 2.5 by the STR in comment 0.

Actual results: The event start date/time is displayed normally and according to the selected date/time when user adds a new event on Week/Day view.
See attachment: verified_Flame_v2.5.3gp
Reproduce rate: 0/10


Device: Flame KK 2.5 (Pass)
Build ID               20151007150205
Gaia Revision          b99837aa2294348317bcae68acabe71d9a83d774
Gaia Date              2015-10-07 13:04:16
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1e1fa696e2b626ead6817b7c5bd871fec5d5ab5a
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151007.183338
Firmware Date          Wed Oct  7 18:33:51 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK 2.5 (Pass)
Build ID               20151008002716
Gaia Revision          b99837aa2294348317bcae68acabe71d9a83d774
Gaia Date              2015-10-07 13:04:16
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/c6ede6f30f3dc886543bb1c76fd7c8b5a151786b
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151007.234555
Firmware Date          Wed Oct  7 23:46:03 UTC 2015
Bootloader             s1
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?][MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.