455462 - Hovering over event in week view causes visual bug on right edge of event

Status: RESOLVED WORKSFORME

(Calendar :: Calendar Frontend, defect)

Description

[Nicholas Brooks]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 (.NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: Lightning build 15-Sep-2008 21:24 PST

By hovering over an event in the Week View causes a visual bug where the right edge of the event becomes jagged.  This corresponds to when the draggable indicators display (three dots) at the top and bottom of the event.

However, this depends on the width of the week view.  If the view is a particular width, some of the events in a day don't take up the whole width of the day, which is probably what is causing this bug in the first place.

Probably best to show the bug.

Reproducible: Sometimes

Steps to Reproduce:
1. Go to week view.
2. However mouse over an existing event.
Actual Results:  
After hovering, event has jagged right edges.

Expected Results:  
After hovering, event looks the same as before it was hovered over.

Comment 1

[Nicholas Brooks]

Attachment: Screenshot of before and after hover

Screenshot of bug described in initial bug report.

Comment 2

[Martin Schröder [:mschroeder]]

Confirmed with latest nightly build on WinXP.

Comment 3

[Philipp Kewisch [:Fallen][☁️📆]]

This looks really strange. Could we get a regression rang for this? Is this something we can live with for the release? Berend, any ideas? If so it would be great to fix today so we can get it into rc2.

Comment 4

[Berend Cornelius]

Attachment: [checked in] patch v. #1

I could not reliably reproduce the bug bug with this patch the issue seems to be fixed from my point of view. I just moved a margin from a stack's child element, that was lying underneath the grippies to the parental stack. 
By the way I also modified the bottom margin of the alarm icon as proposed by Decathlon in bug 453067 comment #8.

Comment 5

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 338841 [details] [diff] [review]
[checked in] patch v. #1

r=philipp if this improves the situation, this bug isn't fixed for me, but it also doesn't break it. I now don't think this should block the release.

Comment 6

[Berend Cornelius]

patch v. #1 checked in on trunk, MOZILLA_1_8_BRANCH and SUNBIRD_0_9_BRANCH. Issue remains open as Philipp could still reproduce the scenarion.

Comment 7

[Decathlon]

Regression range:
Lightning 0.9 2008090118 fails;
Lightning 0.9 2008083119 works.

If you delete code reported here
http://shorl.com/salovastifoju
in calendar-views.css, the bug disappear.

Comment 8

[Berend Cornelius]

in reply to commment #7:
Well observed! I introduced this css -rule with  Bug 452231. Please see Bug 452231 comment #1. As I said in that comment I was not so happy myself with that bugfix and considered it a hack. Anyone is welcome to find a better solution that does not cause any side-effects.
Unfortunately this would come a bit late for the  0.9 train, so we should probably observe the behaviour on trunk.

Comment 9

[Decathlon]

I can't reproduce this bug any more with Lightning 1.0pre .
I observed that bug appears on LG 0.9 when there are either 2 pixels or no pixel between the event boxes and the grid line (e.g. in the screenshot of attachment 338815 [details] there are 2 pixels). Sometimes you can see the bug when event's tooltip disappears from the view because it adds or removes one pixels to the border.

I tried with LG 1.0pre shrinking the week-view (resizing the window or moving the left-side splitter) but there is always 1 pixels between the box and the grid, so the bug doesn't appear even if you search a particular position shrinking the view very slowly.
Could someone please confirm?
Perhaps this bug depends on bug 434019 (1px borders on flex) that is less damaging with Gecko 1.9 (just an idea).

Lightning 1.0pre Nightly Build 2008-11-27
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081125 Lightning/1.0pre Shredder/3.0b1pre

Comment 10

[Martin Schröder [:mschroeder]]

We need to re-confirm with a latest nightly of Lightning 1.0pre that this issue is no longer reproducible. -> qawanted

Comment 11

[[:Aureliano Buendía]]

WFM here on 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090625 Lightning/1.0pre Shredder/3.0b3pre ID:20090625031837

Comment 12

[Martin Schröder [:mschroeder]]

Resolving WFM per comment#9 and comment#11.