[B2G][Calendar] Events can still be tapped on and viewed when no calendar accounts are activated

VERIFIED FIXED in 1.4 S6 (25apr)

Status

Firefox OS
Gaia::Calendar
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: Tony Nguyen, Assigned: millermedeiros)

Tracking

unspecified
1.4 S6 (25apr)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

(Whiteboard: [priority][p=5], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 years ago
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
(Reporter)

Updated

4 years ago
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.
Flags: needinfo?(doliver)
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.
blocking-b2g: --- → 1.4?
Flags: needinfo?(doliver) → needinfo?(bbajaj)
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.
Flags: needinfo?(bbajaj)
Can someone check if this reproduces on 1.1? That will confirm if it's a regression or not.
Keywords: qawanted

Updated

4 years ago
QA Contact: pfield

Comment 5

4 years ago
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

Updated

4 years ago
Keywords: qawanted
blocking-b2g: 1.4? → backlog
Whiteboard: [priority]
(Assignee)

Comment 6

4 years ago
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.
(Assignee)

Updated

4 years ago
Assignee: nobody → mmedeiros
Whiteboard: [priority] → [priority][p=5]
Target Milestone: --- → 1.4 S4 (28mar)
(Assignee)

Updated

4 years ago
Blocks: 982240
(Assignee)

Comment 7

4 years ago
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.
Attachment #8389354 - Flags: review?(gaye)
Comment on attachment 8389354 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17089

Very nice!
Attachment #8389354 - Flags: review?(gaye) → review+
(Assignee)

Comment 9

4 years ago
landed into master: https://github.com/mozilla-b2g/gaia/commit/ec28d9dcf57ca8da142f9f2fea33bc288b76ed59
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → REOPENED
Flags: needinfo?(mmedeiros)
Resolution: FIXED → ---
(Assignee)

Comment 11

4 years ago
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.
Flags: needinfo?(mmedeiros)
(Assignee)

Comment 12

4 years ago
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.
(Assignee)

Comment 13

4 years ago
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.
Attachment #8389354 - Attachment is obsolete: true
Attachment #8393147 - Flags: review?(gaye)
(Assignee)

Comment 14

4 years ago
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)
Attachment #8393147 - Flags: review?(gaye)
Target Milestone: 1.4 S4 (28mar) → 1.4 S5 (11apr)
(Assignee)

Updated

4 years ago
Depends on: 987351
(Assignee)

Comment 15

4 years ago
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.
Attachment #8393147 - Flags: review?(gaye)
(Assignee)

Comment 16

4 years ago
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.
Target Milestone: 1.4 S5 (11apr) → 1.4 S6 (25apr)
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!
Attachment #8393147 - Flags: review?(gaye) → review+
(Assignee)

Comment 18

4 years ago
landed into master! https://github.com/mozilla-b2g/gaia/commit/034050e5fb962c3cbdaf834b0f73a08ed25da2b4
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
[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
Status: RESOLVED → VERIFIED
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.