803378 - Month view agenda portion and day view - Events always take up a full hour's worth of space, which causes problems with multiple non-conflicting events within the same hour

Status: VERIFIED FIXED

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

Description

[Jason Smith [:jsmith]]

Attachment: 30 minute calendar event

Build:

Device - Otoro
Hashes

  <project name="gaia" path="gaia" remote="b2g" revision="e3efbd0411218762cf9a62278bf58ee513ff331f"/>
  <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="38c06c8b4f8f8a6a513a66ab62c9421835017c9f"/>

Steps:

1. Create an event that lasts 30 minutes or less for a particular day
2. View the event on the agenda view of the month view or the day view

Expected:

The event details (even if the information size is reduced) should still fit within the block given in a 30 minute event use case.

Actual:

The event details appears to always assume that it has a 1 hour block at a minimum, which results in the event title and location to be shown outside of the block of the event. See screenshot for example.

Comment 1

[Jason Smith [:jsmith]]

Likely use case, so noming.

Comment 2

[Jason Smith [:jsmith]]

Needs context as to why this does not block. 

Somebody is likely to complain about this, as the web piece were supposed to strive at, so I don't think we should be leaving obvious likely use case issues in the product. The bar is too low here on the quality side. Renoming.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Somebody will definitely complain about this, but it is a polish only bug. It does not affect the calendar feature. An event right after the "30 minute" event will overwrite the "outside the box" text.

Comment 4

[Jason Smith [:jsmith]]

(In reply to Mark Finkle (:mfinkle) from comment #3)
> Somebody will definitely complain about this, but it is a polish only bug.
> It does not affect the calendar feature. An event right after the "30
> minute" event will overwrite the "outside the box" text.

Nope! I just tested this - what actually happens is that if you have two 30 min events right after each other in the same hour (say 6pm), then you get one 30 min event at 6pm - 6:30pm, and another at 7pm - 7:30pm. So what's happening here is that the first 30 min event eats up the full hour space for the text, which pushes the other 6:30pm - 7pm to the next hour. 

I'm morphing the bug and renoming.

Comment 5

[Jason Smith [:jsmith]]

Attachment: Create First Event

Comment 6

[Jason Smith [:jsmith]]

Attachment: First Event on Day View

Comment 7

[Jason Smith [:jsmith]]

Attachment: Create Second Event

Comment 8

[Jason Smith [:jsmith]]

Attachment: View Both Events

Comment 9

[David Scravaglieri [:scravag]]

With context we can see the event is presented at the wrong time in the interface

Comment 10

[James Lal [:lightsofapollo]]

What is the desired behavior here?

Off the top of my head we can:

- Add a minimum height
- Hide the location when there is no room

Comment 11

[Jason Smith [:jsmith]]

Important note btw - if I delete the event at 6pm - 6:30pm, then the 2nd event that still exists fixes itself on the day view to be at the right timeslot (6:30pm - 7pm). So this definitely looks like a CSS-esque issue with blocking off of space per event.

Comment 12

[James Lal [:lightsofapollo]]

The technical reason is simple, we enforce enough space for the location so even though overlap logic is correct we override the height. I _think_ it makes sense to hide the location but then we will have similar issues for 1-30 minute events too so maybe UX has some clever idea how to resolve this.

Comment 13

[Les Orchard [:lorchard]]

Taking a look at this... Seems like an overlapping event in the same hour is screwy, too (maybe already covered by another bug?) 

Haven't quite grok'd the CSS yet, but: it looks like the "top" style for individual events starts from the end of the previous event in the hour, rather than from the start of the hour. 

So, if I remove the "top: 50%" from the second event starting at 30-min past, it ends up positioned correctly after the 1/2-hour-long (ie. height: 50%) event starting at the top of the hour.

An overlapping event (eg. with a top: 25%) also shows up 25% height after the first event, rather than overlapping 25% down from the top of the hour.

Comment 14

[Les Orchard [:lorchard]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6293

Pointer to Github pull-request

Comment 15

[Alex Keybl [:akeybl]]

Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known P2 bugs found before or during C1".

Comment 16

[Jason Smith [:jsmith]]

Verified.