This bug is a follow up to bug 971195, the issue still occurs on master (1.4) Description: Online and offline calendars show events that are longer than one hour as occupying a single hour's worth of space in Month and Day view. User is able to select times that the event occupies in Day view, bringing up new event creation page. Repro Steps: 1) Updated Buri to BuildID: 20140211040200 2) Open Calendar app 3) Tap + icon in top right corner 4) Have event span several hours in a single day, then save event 5) View event in agenda section of month view 6) View event in day view Actual: Multi-hour events display incorrectly in Month and Day view. Expected: Multi-hour events display correctly. Buri master build (1.4), mozRIL BuildID: 20140211040200 Gaia: 9fc36dde3a4a3c5ca200275b68ffb56b4173bec3 Gecko: d812f80a0f1d Version: 30.0a1 Firmware Version: V1.2-device.cfg ---------------------------------------------- Regression window for 1.4: ~First broken~ BuildID: 20140211040200 Gaia: 9fc36dde3a4a3c5ca200275b68ffb56b4173bec3 Gecko: d812f80a0f1d Version: 30.0a1 ~Last working~ BuildID: 20140210040202 Gaia: c273bd6525f7f295539592ce74d5e6b225d53be1 Gecko: ecf20a2484b6 Version: 30.0a1

the bug now is different from before. the previous case the event "border" was being cropped.. (not displaying at all). now that the events doesn't have a background color anymore (since patch was reverted: https://bugzilla.mozilla.org/show_bug.cgi?id=968478#c9), the event is displayed under the next hours "rows" (so borders are above it). and I just found out the real cause of the bug: https://github.com/mozilla-b2g/gaia/commit/44174c8032b77d304f7abf933b4d5d527baa98af (Bug 942854) the bug doesn't exist on the v1.2 branch and does on v1.3 and master. if we revert the commit (or add z-index to `.event`) we can re-merge the other patch https://github.com/mozilla-b2g/gaia/pull/16127/files

Strange - the patch cited there targets 1.3+, but we've only been able to reproduce this on 1.4, not 1.3.

I'm sure it affects v1.3 as well, just used the B2G-flash-tool and updated gecko + gaia to "PVT.v130.hamachi". - it is supposed to look like the image on the left: https://bug971195.bugzilla.mozilla.org/attachment.cgi?id=8374420 (but currently looks like image on the right) I also tested v1.3 branch inside Firefox and can see the lines going over the event.

(In reply to Miller Medeiros [:millermedeiros] from comment #3) > I'm sure it affects v1.3 as well, just used the B2G-flash-tool and updated > gecko + gaia to "PVT.v130.hamachi". - it is supposed to look like the image > on the left: > https://bug971195.bugzilla.mozilla.org/attachment.cgi?id=8374420 (but > currently looks like image on the right) > > I also tested v1.3 branch inside Firefox and can see the lines going over > the event. I'm not sure if that's the same bug here. Let me double check. nkot - can you get a screenshot of the behavior from 1.3 & 1.4 here?

My bug is about events longer than two hours being displayed as one hour event - currently it displays fine on 1.3 and displays wrong on 1.4 The other issues that is brought up here - that events longer than two hours have lines going over the events. This happens on 1.3 for sure, and probably on 1.4 as well - as of now we cannot say anything about that because we cannot see the event in its full view. STR: 1. open Calendar 2. create an event longer that two hours (3-6) 3. view event in Day view See attached screenshot for the results in 1.3 and 1.4

Is there a bug open about the extra lines problem? We should get that filed in a separate bug.

(In reply to Jason Smith [:jsmith] from comment #6) > Is there a bug open about the extra lines problem? We should get that filed > in a separate bug. Both are caused by the "same" thing. The event doesn't have a z-index and is going behind the next hours rows. The reason why one is "cropped" and the other one isn't, is because on the v1.4 builds 20140211040200 and 20140212040203 the ".day-events > .hour" still have a white background color. - the patch for Bug 968478 is still at the end of the "calendar.css" file. I'm 100% sure the z-index removed by Bug 942854 is the real cause for the problem. We could fix it by simply adding a `z-index:1` + a comment explaining why it's important. PS: if I run `DEVICE_DEBUG=1 make reset-gaia` from the master branch (commit 3c54aed) I get the same behavior as the v1.3 branch (lines over the event).

(In reply to Miller Medeiros [:millermedeiros] from comment #7) > (In reply to Jason Smith [:jsmith] from comment #6) > > Is there a bug open about the extra lines problem? We should get that filed > > in a separate bug. > > Both are caused by the "same" thing. The event doesn't have a z-index and is > going behind the next hours rows. The reason why one is "cropped" and the > other one isn't, is because on the v1.4 builds 20140211040200 and > 20140212040203 the ".day-events > .hour" still have a white background > color. - the patch for Bug 968478 is still at the end of the "calendar.css" > file. > > I'm 100% sure the z-index removed by Bug 942854 is the real cause for the > problem. We could fix it by simply adding a `z-index:1` + a comment > explaining why it's important. > > PS: if I run `DEVICE_DEBUG=1 make reset-gaia` from the master branch (commit > 3c54aed) I get the same behavior as the v1.3 branch (lines over the event). Okay - can put a patch together to fix this then?

Uhm.. it is not so simple as reverting the commit 88b00fd1.. I was not able to reproduce the APZ glitches described on Bug 942854, but if I add z-index greater than 0 to the ".event", it slows down the scroll performance drastically on the Hamachi (tested only on v1.4 build 20140212040203). Maybe we will need to change the calendar markup structure to avoid overflows - which is not a simple task; or someone else will need to identify what is causing the slowdown when APZ is enabled. If I disable APZ and relaunch the app the performance goes back to "normal". Jason, do you know who could help to investigate the perf problem on APZ? (or at least give some insight about how things work). - It is not "unusable", but it feels like FPS dropped by 50%. Thanks.

Bug does not appear to occur in today's 1.4 build Environmental Variables: Device: Buri v1.4 Master Mozilla RIL BuildID: 20140213040203 Gaia: a403bdf3cf2a09b5ed0ed5aee362d8b7b31810b3 Gecko: a62bde1d6efe Version: 30.0a1 Firmware Version: V1.2-device.cfg

I can confirm that two or longer hours events do not appear cropped anymore on today's master build. We are only seeing extra lines issue. I think this is good enough to pass the smoketests, so I remove the keyword but leave this bug open until we get clarification on how to move on with the major issue stated here (and whether we track it here or open a new bug)

The bug as filed here was focused on the smoketest blocker, which is now working fine. So I'm closing this out. Miller - For the issue you are seeing with being unable to switch the z-index due to the FPS regression risk, we should open a separate bug tracking that. We should open a new bug for the lines issue as well. Can you take care of that?

It is not a bug but I still keep monitor this situation. I mark it to "VERIFIED".