When trying to create a new calendar event that is all day, I see a big black box around the area of the all day event switch. Screenshot attached. Steps to reproduce: 1) Create a new calendar event 2) Push the tab that says "All Day Event" Gecko: 202128:47c9418fbc28 Gaia: d670bd6efa6aa0e135b972810fe57cb071919e81

Interestingly, if I push the power button on the phone, unlock the phone again, the reloaded event looks normal until I create another new all day event.

Miller Medeiros tried it on today's builds: Gaia: 3a838afca295c9db32e1a3ec76d49fb7fe7fd2d2 Gecko: 3be45b58fc47 BuildID 20140828040204

Miller just tried with gecko 3be45b58fc47, gaia d670bd6efa6aa0e135b972810fe57cb071919e81. Looks like a Gecko regression.

Nevermind, it's intermittent. all gecko / gaias listed previously show the bug.

this is really weird.. It was not reproducing on BuildID 20140828040204, but now after a few tries it started happening.. The weird thing is that if I turn the screen of (while still visualizing the add event screen) the problem disappears (I can toggle the "all day" as many times as I want), but if I go back to month view and try to add a new event the problem reappears randomly. We did change the "add/edit event" screens on Aug 16 (Bug 977050), but it did not change any CSS, it is only setting the end time/date based on the start time. I reverted the patch and it seems the problem is not related to it (I was still able to reproduce the bug). I'm assuming this is a Gecko regression, but can also be something else that changed recently on gaia. PS: I was also able to reproduce it while selecting the date/time. I could see the "caret" for the input field for a brief moment, maybe it's related to that... (since it also changed recently)

[Blocking Requested - why for this release]: this is pretty bad UX, and a regression. User can still interact but it looks/feels broken. We should not ship with a bug like this.

If it's Gecko, it's probably invalidation, and Markus may have thoughts on the subject.

I don't have any thoughts on it, except that the black boxes seems familiar from bug 1050468. I haven't had any luck reproducing this bug on my Flame.

I don't think this is a Calendar issue; I'm seeing this in the email app too -- in the New Account setup page, enter Manual setup mode and then scroll that page up & down. Lots of black boxing on the right half of the screen.

Is overflow: hidden what exposes this issue here as well? (see https://bugzilla.mozilla.org/show_bug.cgi?id=1050468#c9)

(In reply to Milan Sreckovic [:milan] from comment #10) > Is overflow: hidden what exposes this issue here as well? (see > https://bugzilla.mozilla.org/show_bug.cgi?id=1050468#c9) Milan, since this isn't limited to the calendar app...can we assume this is a GFX issue and needs to be moved to a different component?

A regression window would be the first thing to get here. It is either platform side, or we use the same pattern on the Gaia side between different apps, so we end up with the same bug.

B2G Inbound Window Last Working Device: Flame Master Build ID: 20140828023248 Gaia: 03d26d72f1235796e1e60ebb9e6c00da9421e80f Gecko: e1db9407c8ec Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 First Broken Device: Flame Master Build ID: 20140828031150 Gaia: 85cd1af363fc0dc3d38adff6ef3e1c6425dc6583 Gecko: 2525f7bee6cd Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Last Working Gaia and First Broken Gecko Issue DOES NOT occur here. Gaia: 03d26d72f1235796e1e60ebb9e6c00da9421e80f Gecko: 2525f7bee6cd Last Working Gecko and First Broken Gaia Issue DOES occur here. Gaia: 85cd1af363fc0dc3d38adff6ef3e1c6425dc6583 Gecko: e1db9407c8ec Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/03d26d72f1235796e1e60ebb9e6c00da9421e80f...85cd1af363fc0dc3d38adff6ef3e1c6425dc6583 Possible Cause: Bug 1015292 - [Calendar] Update to use gaia-header

broken by Bug 1015292 ?

the weird thing is that according to :jrburke the email app doesn't use gaia-header and we are seeing the same thing there as well.. maybe there is something on the CSS or markup structure that is similar and triggers the weird behavior.

I think bug 1063046 is basically same issue as well

the problem is, bug 1063046 and this issue have 2 completely different regression windows - so unless one is completely wrong (not saying that isn't possible) then these are not dupes

I encountered this issue in the ringtones app (bug 1015296) when implementing gaia-header. I was able to fix the problem by making some elments position: absolute [1]. I'd guess that it's something to do with scrollable layers and shadow-dom as the issue didn't exist with the old header building block. I could take a look at this bug and try to implement a similar fix, but then that wouldn't address the platform bug at the root of the problem. [1] https://github.com/mozilla-b2g/gaia/pull/23103/files?diff=unified#diff-99a0b01270e086f8d62bc12b2657d09cR17

(In reply to Joshua Mitchell [:Joshua_M] from comment #18) > the problem is, bug 1063046 and this issue have 2 completely different > regression windows - so unless one is completely wrong (not saying that > isn't possible) then these are not dupes The graphical artifacts are occurring because of tiling. It sounds like a calendar change incidentally may have affected whether something is tiled or not. There's definitely no action that should be taken on this bug prior to bug 1063046 being resolved; workarounds would be a bad use of everyone's time.

triage: 2.1+ for terrible visual regression.

Milan, we got a regression window. Can you help find someone on our team to take a look please?

We're assuming this is a duplicate of bug 1063046. Due to scheduling conflicts, we will probably only look at that first thing next week.