On Windows 7 the navigation buttons inside mini-day and the keep-duration button need an adjustment

RESOLVED FIXED in 1.0b7

Status

Calendar
Calendar Views
--
trivial
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Decathlon, Assigned: Decathlon)

Tracking

Trunk
1.0b7
x86
Windows 7

Details

Attachments

(3 attachments)

(Assignee)

Description

7 years ago
Created attachment 543944 [details]
Screenshot

As you can see in the screenshot, on Windows 7 there are the following trivial issues: 
- the navigation buttons (previous day e next day) in the mini-day are smaller than the central button (today);
- the keep-duration button on the Edit Event dialog is misplaced to the left and the same occurs for the first timezone link;
- a minor issue is the image in the minimonth's buttons which is not centered (see the today button where the image is a circle).
(Assignee)

Comment 1

7 years ago
Created attachment 543948 [details] [diff] [review]
patch - v1

The patch changes the min-width to 19 pixels for the buttons in the mini-day and the minimonth, and 21 pixels for the keep-duration button.

In order to get a centered image the buttons should have a odd value width (19 or 21 pixels) at the moment in the minimonth the width is 20 pixels because that is the minimum width I can get on Windows XP (it seems there is no way to get a minor width on that OS) so I've decided to set the min-width to 19 pixels in order to get a smaller, but still usable, button with a centered image on Windows 7 (see screenshot) even if this will not change the width on Windows XP (still 20px).

The alternative is to set every min-with to 21 pixels and this will be the same on Win7 and WinXP, but in this way the buttons could be a bit large, see the screenshot.
Assignee: nobody → bv1578
Status: NEW → ASSIGNED
Attachment #543948 - Flags: review?(philipp)
Attachment #543948 - Flags: review?(philipp) → review?(richard.marti)
Comment on attachment 543948 [details] [diff] [review]
patch - v1

Review of attachment 543948 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good to me.

What I see under Win7 (not checked under other systems): in calendar-event-dialog the startdate and enddate rows don't have the same height and the keepduration-button is touching the enddate arrow. This behaviour isn't introduced by this patch, this happens also before this patch. I'll attach a image.
Attachment #543948 - Flags: review?(richard.marti) → review+
Created attachment 544283 [details]
Image with the issue

This could be for an other bug
(Assignee)

Comment 4

7 years ago
(In reply to comment #2)

> What I see under Win7 (not checked under other systems): in
> calendar-event-dialog the startdate and enddate rows don't have the same
> height and the keepduration-button is touching the enddate arrow. This
> behaviour isn't introduced by this patch, this happens also before this
> patch. I'll attach a image.

Richard, what theme are you using? On my Win7 the datetime-pickers look completely different.
Which is the datepicker with the wrong height (compared with the others datepickers where there isn't the keepduration button) the startdate or the enddate?

When the button is in hover status, what is the distance between the left border and the datepickers? I ask that because looks like the rule
-moz-margin-start: -3px 
doesn't have any effect.

The positioning of the keepduration button was a bit complicated as you can read in Bug 366139 comment 22 (and others comments as well).
You are right. Something in my test profile is wrong. I'm using Win7 and with TB5 and Lightning 1.0b4 everything is okay, so forget this comment.

With the -moz-margin-start: -3px this was a error on my side. After correcting it it has effect and the button is correctly shifted to the left.
(Assignee)

Comment 6

7 years ago
(In reply to comment #5)
> You are right. Something in my test profile is wrong. I'm using Win7 and
> with TB5 and Lightning 1.0b4 everything is okay...

Hence is it everything fine in the patch? If yes I will active the checkin-needed keyword.
Yes the patch is fine.
Keywords: checkin-needed
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/2959eb33d4e7>
-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Keywords: checkin-needed
This bug was also pushed to comm-beta and comm-aurora, likely during the last merge.
Target Milestone: Trunk → 1.0b6
You need to log in before you can comment on or make changes to this bug.