Brogan Zumwalt [Inactive] Reporter
	Description • 10 years ago

Description:
If user creates an event that spans multiple days in the Calendar app, the event listing will appear outside of the table boundaries in week and day view when the event starts at 11:03 pm or later

Repro Steps:
1) Updated Buri to BuildID: 20140408000202
2) Launch calendar app
3) Create new event
3a) Set start time between 11:03 PM and 11:59 PM on any day 
3b) Set end time for any time and day after start time
4) Select "Done" to finish event creation and view event in Week view

Actual:
First day of event appears at least partially outside table boundaries in week or day view.

Expected:
Event is always displayed within table boundaries.

Environmental Variables:
Device: Buri v1.4 Mozilla RIL
BuildID: 20140408000202
Gaia: 26983f356ecb1bcf30e862d334b5de790071803e
Gecko: 70b076fc7558
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: 3/3, 100%
See attached: screenshots

	Jason Smith [:jsmith]
	Comment 2 • 10 years ago

Pretty sure this is a regression.

Can we confirm this isn't happening on 1.3?

	Tony Nguyen
	Comment 3 • 10 years ago

This issue does reproduce on the latest Buri v1.3 mozRIL BuildID: 20140409004002. To clarify, the screenshot that the reporter attached is representing the behavior from the STR in comment 0 for when an event has been set to start at 11:59 PM.

Gaia: 100a159af11281d965e9d70d0f3d3111a38775ee
Gecko: ea2a473b122f
Version: 28.0
Firmware Version: v1.2-device.cfg

	Jason Smith [:jsmith]
	Comment 4 • 10 years ago

Does this happen on 1.1?

	Josh Schmitt [Joshs]
	Comment 5 • 10 years ago

(In reply to Jason Smith [:jsmith] from comment #4)
> Does this happen on 1.1?

I was able to repro this issue on 1.1 Buri build

1.1 Environmental Variables:
Device: Buri 1.1 MOZ
BuildID: 20140331041208
Gaia: 44a2ddf63373f8e95c784faf4ed4d60081699c61
Gecko: 170d87349060
Version: 18.0
Firmware Version: V1.2-device.cfg

	Preeti Raghunath(:Preeti)
	Comment 6 • 10 years ago

Misleading calendar. Hence 1.4+

	Evan Tseng [:evanxd]
	Comment 7 • 10 years ago

I could not reproduce this bug on the below build.

Device: Buri v1.4
Gaia: 8dff633372022723e2ebad17fe3c826436b3b258
Gecko: https://hg.mozilla.org/releases/mozilla-aurora/rev/bc14179fc49c
BuildID: 20140414000201
Version: 30.0a2

	Evan Tseng [:evanxd]
	Comment 8 • 10 years ago

Hi Brogan,
Could you reproduce the on the build at Comment 7 currently?

	Rachel Pribble [:rpribble]
	Comment 9 • 10 years ago

I am able to reproduce this issue on the Buri v1.4 MOZ ril.

Environmental Variables:
Device: Buri v1.4 MOZ ril
BuildID: 20140414000201
Gaia: 8dff633372022723e2ebad17fe3c826436b3b258
Gecko: bc14179fc49c
Version: 30.0a2
Firmware Version: v1.2-device.cfg

An event that starts at 11:20pm and ends the next day at 1:00am displays outside the table boundaries as seen in the original image attachments.

	Evan Tseng [:evanxd]
	Comment 10 • 10 years ago

We could reproduce the bug with follow Comment 9 currently.
Thanks, Rachel. :)

	Jason Smith [:jsmith]
	Comment 11 • 10 years ago

Renoming - we've already shipped with this in past releases.

	Evan Tseng [:evanxd]
	Comment 16 • 10 years ago

I think the week-view.png attachment and day-view.png attachment is what we want after we add a event like the event-view.png attachment.

But this bug might conflict with Bug 824835. Currently if the event is cross next day, the event element's height is fixed. So this bug is happened. See the logic at https://github.com/mozilla-b2g/gaia/blob/master/apps/calendar/js/views/day_based.js#L295-L305.

	Evan Tseng [:evanxd]
	Comment 17 • 10 years ago

Hi Harly,

For Comment 16, I think this bug is also about UX issue.
How do you think?

Thanks.

	Harly Hsu[:harly]
	Comment 18 • 10 years ago

I think for event that crosses to the next day, it is really strange to display event outside the border. The fix height of event element may need to be removed and display the actual height of the event from start to 12:00. Needinfo Miller as he has done some modifications to day/week view for visual refresh, which might be able to help on this.

	Miller Medeiros [:millermedeiros] Assignee
	Comment 19 • 10 years ago

I agree that expected behavior is what the image attachments show. On visual refresh the month view will have a different design (Bug 951069), which should bypass the problem shown on Bug 824835. And I also think that not showing the location is better than the bug it introduced. - if location is not displayed app doesn't look broken, most users won't even notice it.

PS: We need tests to avoid regressions (can be unit or integration). Maybe an integration test that checks if event is overflowing the "hour" would be enough.

	Evan Tseng [:evanxd]
	Comment 20 • 10 years ago

I think we could do this bug in the visual refresh works.

	Miller Medeiros [:millermedeiros] Assignee
	Comment 21 • 10 years ago

this was fixed on 2.0 and 2.1

	Miller Medeiros [:millermedeiros] Assignee
	Comment 22 • 10 years ago

my bad, this still happens for day view on 2.0 and 2.1 - it should be fixed as soon as we land Bug 1052960

	Dylan Oliver [:doliver]
	Comment 23 • 10 years ago

[priority] --> tracking-b2g:+ conversion

	Miller Medeiros [:millermedeiros] Assignee
	Comment 24 • 10 years ago

fixed on Day View together with Bug 1052960