With APZ turned on and a <meta name="viewport" content="device-width=width, height=device-height, minimum-scale=1, initial-scale=1, user-scalable=1"> scrolling the week view of the calendar app results into some visual artifacts on top of the header (and the panning itself seems jumpy). Steps to reproduce: - If you have a Gaia without any data (calls, messages, contacts, ..), go into the gaia directory and do |make reference-workload-medium| - Open the calendar app - click on the 'Week' view - pan the view to the top until there are some events - continue to pan Actual result: - the events orange square are drawn on top of the header and panning seems 'jumpy'. Expected result: - no orange square above the header and a smooth panning

This shows up even with fixes to bug 942995 and bug 942799.

Vivien, you obviously think this is on Gecko side?

(In reply to Milan Sreckovic [:milan] from comment #2) > Vivien, you obviously think this is on Gecko side? Yes :) It doesn't show up without APZ.

Kats, what's your take on this? Where should we start looking?

From the video it's not obvious to me what's causing it. My usual place to start would be to enable the APZ logging and try to see where the first wrong value is coming from.

The overlapping is still there, but the bad interaction from the video seems to be gone in the latest trunk.

(In reply to Milan Sreckovic [:milan] from comment #6) > The overlapping is still there, but the bad interaction from the video seems > to be gone in the latest trunk. Not sure if this is related, but panning this view seems slow as well.

It seems like a z-index related issue. If I change the z-index to be 0 instead of 10 at https://github.com/mozilla-b2g/gaia/blob/master/apps/calendar/style/week_view.css#L171 and https://github.com/mozilla-b2g/gaia/blob/master/apps/calendar/style/day_views.css#L56 then the artifacts are gone and the scroll is smooth again. With or without this I see an other issue in Calendar where you can't scroll anymore into the week/day view once you have clicked on the '+' to create a new event and then it has been closed. I will open a separate bug for that. Milan for the first issue I don't mind to workaround it in Gaia since this bug is likely something that has lurked forever in the code but was not exposed too much since sub frames where not used to be async scrollable before B2G (at least that what I understood). What do you think ?

The workaround if we decide to use it.

Comment on attachment 8345246 [details] [diff] [review] calendar.artifacts.workaround.bug942854.patch I don't think I need 2 review but this is like a race. I'm asking r? in advance just because I would like to be ready in advance if we decide to use those and fix the Gecko issue later. Does those z-indexes have any real use or can I remove them entirely ?

Comment on attachment 8345246 [details] [diff] [review] calendar.artifacts.workaround.bug942854.patch Review of attachment 8345246 [details] [diff] [review]: ----------------------------------------------------------------- Looks good! I went and tested and I think we can simply remove the z-index definitions all together. (It would be good if we can fix the platform issue though as won't this appear in web content as well?) ::: apps/calendar/style/day_views.css @@ +53,4 @@ > position: absolute; > height: 6rem; > top: 0; > + z-index: 0; nit: Please just remove this line instead. I don't think it's needed anymore. ::: apps/calendar/style/week_view.css @@ +168,4 @@ > #week-view .week-events > ol li.event { > position: absolute; > width: 100%; > + z-index: 0; nit: Please just remove this line instead. I don't think it's needed anymore.

(In reply to Kevin Grandon :kgrandon from comment #11) > Comment on attachment 8345246 [details] [diff] [review] > calendar.artifacts.workaround.bug942854.patch > > Review of attachment 8345246 [details] [diff] [review]: > ----------------------------------------------------------------- > > Looks good! I went and tested and I think we can simply remove the z-index > definitions all together. (It would be good if we can fix the platform issue > though as won't this appear in web content as well?) The platform issue will eventually be fixed, but since this is not a regression. It has lived here forever, that's probably OK for 1.3.

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #8) > ... > > Milan for the first issue I don't mind to workaround it in Gaia since this > bug is likely something that has lurked forever in the code but was not > exposed too much since sub frames where not used to be async scrollable > before B2G (at least that what I understood). > > What do you think ? I agree. We leave this one as 1.3 to land the Gaia workaround and open another (non-regression) bug for the later release to fix the Gecko issue.

https://github.com/mozilla-b2g/gaia/commit/44174c8032b77d304f7abf933b4d5d527baa98af This patch needs to land on 1.3. I will open a followup to fix the real gecko issue for 1.4.

Pushed in 1.3 https://github.com/mozilla-b2g/gaia/commit/88b00fd100620a5dd48ae7661ccd5170de421576

I reverted the patch on master: https://github.com/mozilla-b2g/gaia/commit/05450d1f75937a76e612268e02fe5718afa84ae4 It introduced Bug 972666 and I fixed the performance problem on another commit. I was not able to reproduce the problem described here.