979961 - [B2G][Calendar] Multi-hour events are incorrectly displayed as one-hour in Month and Day view

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Calendar, defect)

Description

[Natalya Kot [:nkot]]

Attachment: screenshot

Description:
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: 20140305040204
2) Open Calendar app
3) Tap "+" in top right corner
4) Create an event span several hours in a single day
5) View event in agenda section of Month view
6) View event in Day view

Actual:
Multi-hour events incorrectly displayed as one-hour in Month and Day view.

Expected:
Multi-hour events are displayed correctly

Environmental Variables:
Device: Buri master (v1.4) build, Mozilla RIL
BuildID: 20140305040204
Gaia: 6781459a49642ca0eb7ec3e95667808d5d77b656
Gecko: e5b09585215f
Version: 30.0a1
Firmware Version: v1.2-devices.cfg

Notes: Evens are shown correctly in Week view

Repro frequency: 100%
See attached screenshot

Comment 1

[Dylan Oliver [:doliver]]

smoketest blocker, cc'ed relevant calendar people

Comment 2

[Miller Medeiros [:millermedeiros]]

this was caused because https://bugzilla.mozilla.org/show_bug.cgi?id=972666 was backed out after https://bugzilla.mozilla.org/show_bug.cgi?id=968478 was already merged.

The latest pull request on Bug 972666 should fix the problem.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Miller Medeiros [:millermedeiros] from comment #2)
> this was caused because https://bugzilla.mozilla.org/show_bug.cgi?id=972666
> was backed out after https://bugzilla.mozilla.org/show_bug.cgi?id=968478 was
> already merged.
> 
> The latest pull request on Bug 972666 should fix the problem.

I don't think so. bug 968478 landed on 2/28, which means we would have saw this in the smoketest runs after that date. However, yesterday's smoketest run had everything passing, so something that landed yesterday must have caused this regression. A window will help diagnose what the problem is.

Comment 4

[Peter Bylenga [:PBylenga]]

Was unable to use Inbound builds due to being outside of the window range we have available.  Also was blocked due to the crashing bug 978450 for a period of a few builds limiting the granularity of the window range.

Last working Tinderbox Build

v1.4 Environmental Variables:
Device: Buri v1.4 MOZ
BuildID: 20140228124458
Gaia: a980b8f54956ed470667033630b02492efdf4a07
Gecko: 74cf230995da
Version: 30.0a1
Firmware Version: v1.2-device.cfg

First blocked Tinderbox Build due to app crashing bug

v1.4 Environmental Variables:
Device: Buri v1.4 MOZ
BuildID: 20140228130531
Gaia: a980b8f54956ed470667033630b02492efdf4a07
Gecko: 8abc76dedec2
Version: 30.0a1
Firmware Version: v1.2-device.cfg

First Broken Tinderbox Build that isn't blocked by app crashing bug

v1.4 Environmental Variables:
Device: Buri v1.4 MOZ
BuildID: 20140303064730
Gaia: dfae3744607257206e37483dc3f431108baf70fb
Gecko: 22d263f6edc4
Version: 30.0a1
Firmware Version: v1.2-device.cfg

Last Working Gaia/First Broken Gecko: Issue Does NOT Reproduce
Gaia: a980b8f54956ed470667033630b02492efdf4a07
Gecko: 22d263f6edc4

First Broken Gaia/Last Working Gecko: Issue DOES Reproduce
Gaia: dfae3744607257206e37483dc3f431108baf70fb
Gecko: 74cf230995da

Gaia Pushlog:
https://github.com/mozilla-b2g/gaia/compare/a980b8f54956ed470667033630b02492efdf4a07...dfae3744607257206e37483dc3f431108baf70fb

Comment 5

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #3)
> (In reply to Miller Medeiros [:millermedeiros] from comment #2)
> > this was caused because https://bugzilla.mozilla.org/show_bug.cgi?id=972666
> > was backed out after https://bugzilla.mozilla.org/show_bug.cgi?id=968478 was
> > already merged.
> > 
> > The latest pull request on Bug 972666 should fix the problem.
> 
> I don't think so. bug 968478 landed on 2/28, which means we would have saw
> this in the smoketest runs after that date. However, yesterday's smoketest
> run had everything passing, so something that landed yesterday must have
> caused this regression. A window will help diagnose what the problem is.

Looks like I'm not right. The window above actually shows this reproducing yesterday. I can confirm this reproduces on the 3/4 build as well.

Comment 6

[Jason Smith [:jsmith]]

Can someone try pulling the latest master & seeing if this still reproduces?

https://github.com/mozilla-b2g/gaia.git

Comment 7

[Peter Bylenga [:PBylenga]]

I can confirm issue does not reproduce pulling the latest master as described in Comment 6:

v1.4 Environmental Variables:
Device: Buri v1.4 MOZ
BuildID: 20140305040204
Gaia: c68dfe5bf0ac51c71047c4470000cd760f74e349
Gecko: e5b09585215f
Version: 30.0a1
Firmware Version: v1.2-device.cfg

Comment 8

[Natalya Kot [:nkot]]

The issue still appears in today's latest master build (production), so reopening bug until we get clear confirmation it is fixed.  

Device: Buri master (v1.4) build, Mozilla RI
BuildID: 20140306040204
Gaia: 9cb35e701df44766d9b3560b0defe0a401a0ecdd
Gecko: 8122ffa9e1aa
Version: 30.0a1
v1.2-devices.cfg

Comment 9

[Miller Medeiros [:millermedeiros]]

the gaia commit 9cb35e701df44766d9b3560b0defe0a401a0ecdd happened 2014-03-05 15:41:06; the commit that fixes this bug was ef64aa12b65723a29b3d5dbe115820a557763fab which only happened on 2014-03-05 17:23:05. that's why you can't confirm it was fixed. If you use latest from master it work fine.

Comment 10

[Natalya Kot [:nkot]]

Verified Fixed.
Multi-hour events are now displayed correctly.

BuildID: 20140307040203
Gaia: 04eb7996543f114133d1367f834a4d88b68c60ac
Gecko: b0e7f63c2138
Version: 30.0a1