Description: Events that are added onto the Calendar app, either from an online account or an offline account, will not show up when they're not being tracked. The user is still able to tap on events when they're not visible and view or edit them. Repro Steps: 1) Updated Buri to BuildID: 20140207004002 2) Navigate to Calendar App 3) Have a Gmail account setup 4) Create an event for both Gmail and Offline account with same date and time 5) Navigate to account settings by tapping on icon on top left corner of screen 6) Tap on calendar accounts to uncheck and stop tracking them 7) Return to the calendar and tap on the date that the events were set for Actual Result: Events for calendar events that are not being tracked can be viewed and edited Expected Results: Events for calendar events that are not being tracked cannot be seen or edited Environmental Variables: Device: Buri v1.3 mozRIL BuildID: 20140207004002 Gaia: 1527d1e450364e383eeb95ff898dca2042e2b4b5 Gecko: 0a6d83aabb02 Version: 28.0 v1.2-device.cfg Attached: video
NI on :doliver to help find a right assignee. Dylan this was on the new issues found in today's build when QA was doing the 1.3 smoketesting.
Is this a regression and/or qablocker? Nominating for 1.4? to get it on the radar but please escalate if it's more urgent.
Switching NI to QA, :marcia to see if this is a regression on 1.3 from a recent landing or if this is an old bug that was recently caught.
Can someone check if this reproduces on 1.1? That will confirm if it's a regression or not.
Issue occurs on 1.1 in the same manner as listed above in the STR Environmental Variables: Device: BURI 1.1 MOZ BuildID: 20140207041202 Gaia: c5cb252e5d1aa45d14f3a2ea182e73e2271e4496 Gecko: adaf8883268e Version: 18.0 Firmware Version: V1.2-device.cfg
On the week view it seems that problem is caused because only the `li.event > .container` is `display:none` and click listener is on `li.event`. on the Day View something "worse" happens. The hour that contains an event disappears - if event was at 9am the 9am "row" will disappear. - It is the correct behavior for the "month view" tho.
Created attachment 8389354 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17089 I created the integration tests before fixing the problem, the bug described only happened on week view; but I also found a separate bug that is also related to it on Day View (Bug 982240) and will fix as a separate pull request.
Comment on attachment 8389354 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17089 Very nice!
landed into master: https://github.com/mozilla-b2g/gaia/commit/ec28d9dcf57ca8da142f9f2fea33bc288b76ed59
Sorry Miller, had to back this one out due to an intermittent failure. Looking forward to the day we get screenshots for js marionette.. Failure details: 1) toggle calendar "before each" hook: Error: timeout exceeded! at Object.Client.waitForSync (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:679:16) at Object.Client.waitFor (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:648:60) at Object.Calendar.waitForTransitionEnd (/home/travis/build/mozilla-b2g/gaia/apps/calendar/test/marionette/calendar.js:534:12) at Object.Calendar._toggleSettingsView (/home/travis/build/mozilla-b2g/gaia/apps/calendar/test/marionette/calendar.js:578:10) at Object.Calendar.goToSettingsView (/home/travis/build/mozilla-b2g/gaia/apps/calendar/test/marionette/calendar.js:564:10) at toggleLocalCalendar (/home/travis/build/mozilla-b2g/gaia/apps/calendar/test/marionette/toggle_calendar_test.js:23:9) at Context.<anonymous> (/home/travis/build/mozilla-b2g/gaia/apps/calendar/test/marionette/toggle_calendar_test.js:19:5) at Hook.Runnable.run (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:211:32) at next (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:257:10) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:269:7 at done (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:185:5) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:197:9 at Object.executeHook (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:370:18) at process._tickCallback (node.js:415:13) Backed out: https://github.com/mozilla-b2g/gaia/commit/cbaabd36454162ec3ea397c1e7121ba8ad7a85ce
I reused the logic that :evanxd had to detect the "transitionend"; right now I'm trying to change it a little bit to see if that fixes things, but if that doesn't work, I'm thinking to replace the logic and instead of checking for "transtionend" I would check if the "#time-views" is still on top of "a[href='/select-preset/']" (add calendar button) - probably using `document.elementFromPoint`, I'm assuming that it should be way harder to fail. Problem could also be caused if for some reason the click did not trigger the transition. I'm not sure if that is possible (and/or makes any sense) but I'm starting to believe that slowdowns on Travis might cause clicks to be "lost" (blocked thread?) - not the first time I see weird intermittent errors just after clicks.
every since I started tweaking the transitionend logic I could not replicate the timeout, but I was able to reproduce another bug way more often.. now `app.findElement('monthViewDayEvent').displayed()` is returning the wrong value sometimes.. like if the calendar was not disabled/enabled. I'm still trying to find the root cause for it since it doesn't make any sense.
Created attachment 8393147 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17301 changed the test structure to avoid intermittent failures, executed tests more than 20 times with success (https://travis-ci.org/mozilla-b2g/gaia/builds/21050964) problem was caused because the UI takes a few milliseconds to reflect the checkbox value (storage is async and has a delay). Fixed by pooling for the expected value and added a few methods to make code cleaner and avoid errors.
Comment on attachment 8393147 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17301 don't review it for now.. I'll rewrite the marionette tests to follow the new test structure and will r? when done. (that will avoid rework in the future)
Comment on attachment 8393147 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17301 updated the tests to follow new structure. still waiting travis to run a few more times to make sure we won't have intermittent failures.
moving it to next sprint since blocker only landed over the weekend and patch was not reviewed yet. I just rebased the PR to reflect latest code on master. :gaye, please feel free to review it.
Comment on attachment 8393147 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17301 Just a few nits on GH. Otherwise this is great. Thanks!
landed into master! https://github.com/mozilla-b2g/gaia/commit/034050e5fb962c3cbdaf834b0f73a08ed25da2b4
[Environment] Gaia 3d47c0627017ef77b1adf179792c6543a349af72 Gecko https://hg.mozilla.org/mozilla-central/rev/1f932e462b84 BuildID 20140415160202 Version 31.0a1 ro.build.version.incremental=eng.archermind.20131114.105818 ro.build.date=Thu Nov 14 10:58:33 CST 2013 [Result] PASS