* Description: As you are using calendar and stay in day view or week view, the calendar will automatically go back to month view after turning on/off airplane mode. Demo video: CALENDAR_VIEW IS AUTOMATICALLY CHANGED.mp4 This defect is reported from our partner, and it causes failure of Gaia UI test. * Reproduce Steps: 1. Launch calendar app 2. Go to any view except calendar's Month view 3. Turn on airplane mode 4. Turn off airplane mode 5. After 2~5 seconds, you can see that the view will automatically go back to Month view * Expected result: The view still stays on Day view or Week view.. * Actual result: The view goes back to Month view. * Build information: @ Flame 2.0 (Can be reproduced) - Gaia-Rev 7b8df9941700c1f6d6d51ff464f0c8ae32008cd2 - Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/82a6ed695964 - Build-ID 20141102000201 - Version 32.0 - Device-Name flame @ Flame 2.2 (Can be reproduced) - image:2014-09-18-16-02-02-mozilla-central-flame-eng)
[Blocking Requested - why for this release]: This defect is reported from our partner, and it caused a failure of Gaia UI test on v2.0. - test_calendar_new_event_appears_on_all_calendar_views.py
blocking-b2g: --- → 2.0?
Hi William, you mention a "demo video" on the first comment but I couldn't see any attachment on this bug report. Do you have the video file? I could not reproduce it on Flame-KK build 20141029040208
one thing that is worth noticing is that the calendar app will restart during `moztimechange` (happens whenever the system time is set), so maybe that is what is going on.
Created attachment 8516425 [details] CALENDAR_VIEW IS AUTOMATICALLY CHANGED.mp4
My bad. I forgot to attach the demo video. Attached. :)
[Blocking Requested - why for this release]: Pushing this to 2.1 given where we are with 2.0 already, a little too late
blocking-b2g: 2.0? → 2.1?
too risky for 2.1 at this stage. Will mark as priority fix for master.
blocking-b2g: 2.1? → backlog
tracking-b2g: --- → +
By the way, this problem cause a failed test case when we ran Gaia UI test on Tako v2.1. - test_calendar_new_event_appears_on_all_calendar_views.py Thanks.
This is actually "tricky" to fix.. there are many things on the app that relies on the current date/time and unless we rebuild all the time views (month/week/day) there will be inconsistencies. eg: - current day button might display wrong day. - current time on week/day views will display wrong time. - if timezone is changed all the currently displayed events will have the wrong time. - border around current day on month view might highlight the wrong day. we are planning to add a better abstraction for listening to current time on Bug 1118850 (to avoid mistakes) so after that lands it might be easier to fix this but it will still require some extra logic to rebuild the events. PS: there might be other things in the calendar logic that are affected by the timezone/time change but that I'm overlooking.
Depends on: 1118850
the view/add/modify event views also needs to be re-rendered when the timezone changes since they display the event start/end time. there is the option to only restart the app if "timezone" changed (that would take care of all the views that display events). and when just the "date" or "time" changes we just update anywhere that shows current day/time (which could ideally be handled by the Bug 1118850 refactor).
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.