mini month "previous" and "next" arrow buttons move when clicked



Internal Components
12 years ago
10 years ago


(Reporter: ianxm, Assigned: Berend Cornelius)


Windows XP



(1 attachment, 3 obsolete attachments)



12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20060508 Firefox/
Build Identifier: Lightning version 0.1 (build 2006031011)

The arrow buttons at the top right and left of the mini month display shift to the sides when clicked.  It looks like their position depends on the month string between them.  i.e. going from "February" to "March" brings the buttons closer together.  The problem is that if you are repeatedly clicking to get a few months ahead the button may not stay under the pointer.

Reproducible: Always

Comment 1

12 years ago
The same thing applies to the arrow buttons above the month view of the main display.

Comment 2

12 years ago
*** Bug 341519 has been marked as a duplicate of this bug. ***
Assignee: nobody → base
Component: Lightning → Base
Ever confirmed: true
OS: Windows 2000 → Windows XP
QA Contact: lightning → base
Version: unspecified → Trunk
FWIW: I do _not_ see this on Mac in Sunbird's minimonth.

Comment 4

12 years ago
Created attachment 225618 [details] [diff] [review]
patch for views

This is the patch to fix the position of the arrows in the views, in response to comment #1.  I need to look more at the minimonth, since it's laid out a bit differently.
Assignee: base → jminta
Attachment #225618 - Flags: first-review?(dmose)
Comment on attachment 225618 [details] [diff] [review]
patch for views

When in doubt, more cowbell -- or spacer. r=shaver
Attachment #225618 - Flags: first-review?(dmose) → first-review+

Comment 6

12 years ago
patch for views checked in.  Reassigning to default for work on the minimonth.
Assignee: jminta → base
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody


12 years ago
Target Milestone: --- → Sunbird 0.3
Not going to make the 0.3 train.
Target Milestone: Sunbird 0.3 → Sunbird 0.4

Comment 9

11 years ago
*** Bug 359635 has been marked as a duplicate of this bug. ***
Not going to make the 0.5 train.
Target Milestone: Sunbird 0.5 → ---


10 years ago
Assignee: nobody → Berend.Cornelius

Comment 11

10 years ago
Created attachment 284614 [details] [diff] [review]
patch with modified minimonth-header

I resolved the issue by changing two things:
1) I use a deck element to store the monthdescriptions forcing the control to adjust to the largest month description. In this respect I also moved the according resources to global.dtd. Please see bug #388414 and its comments #16,18,32. I checked that these resources are only used where global.dtd is included. As this patch is rather small I found it Ok to do this in one "washing up".
2) I also used a deck-element to ensure that the year-cell will keep a constant width. At first I applied a min-width in the style sheet rule (min-width: 52px;) finding out that the control still changes its width when switching the date from December 1999 to January 2000 (I also tried applying a maxwidth of 52px but it did not help either); I did not like the implementation of the constructor where the elements headbox, monthcell.. are referenced by their index. I had to change this for the yearCell but did not dare to adapt the same for the other controls as it's not really part of this issue.
Attachment #225618 - Attachment is obsolete: true
Attachment #284614 - Flags: review?(philipp)

Comment 12

10 years ago
Would is make sense to start a new dateFormat.dtd file (similar to existing instead of adding more content to global.dtd?

Comment 13

10 years ago
In fact currently "global.dtd" (almost) only contains strings related to date-time information. So your suggestion would result in a mere renaming of "global.dtd" for which I do not see a necessity.
In this context only two strings (<!ENTITY more.label and <!ENTITY more.label>) break ranks - and these do not seem to be used anywhere in the project.
I filed bug 399595 to remove the unused entities.
Version: Trunk → unspecified

Comment 15

10 years ago
Created attachment 286567 [details] [diff] [review]
patch v. 2

I overworked the implementation to determine the minimal width of the year-text field. I noticed that we currently administrate three different .css files for the minimonth, one for lightning and two for Sunbird (+one to define the bindings). This overhead should be consolidated. Yet as there were slight differences between Sunbird's minimonths and lightning's I left it as it is.
Attachment #284614 - Attachment is obsolete: true
Attachment #286567 - Flags: review?(philipp)
Attachment #284614 - Flags: review?(philipp)
Comment on attachment 286567 [details] [diff] [review]
patch v. 2

>+<!DOCTYPE dialog [
>+  <!ENTITY % dtd1 SYSTEM "chrome://calendar/locale/global.dtd" > %dtd1;
One line doctypes can be written as
<!DOCTYPE dialog SYSTEM "chrome://calendar/locale/global.dtd">

>diff -a -U 8 -pN -r -x '*.png' mozilla_ref/calendar/resources/skin/classic/datetimepickers/minimonth.css mozilla/calendar/resources/skin/classic/datetimepickers/minimonth.css
>diff -a -U 8 -pN -r -x '*.png' mozilla_ref/calendar/sunbird/themes/pinstripe/sunbird/datetimepickers/minimonth.css mozilla/calendar/sunbird/themes/pinstripe/sunbird/datetimepickers/minimonth.css
>diff -a -U 8 -pN -r -x '*.png' mozilla_ref/calendar/sunbird/themes/winstripe/sunbird/datetimepickers/minimonth.css mozilla/calendar/sunbird/themes/winstripe/sunbird/datetimepickers/minimonth.css

We should consolidate the resources/skin version of the css into base/themes. Could you file a followup bug if it doesn't already exist?

Otherwise r=philipp
Attachment #286567 - Flags: review?(philipp) → review+

Comment 17

10 years ago
>Could you file a followup bug if it doesn't already exist?

My idea was to fix this within bug 377753 ("Look and Feel of minimonths should be adapted" that is already assigned to me. Thanks for the review

Comment 18

10 years ago
Created attachment 286695 [details] [diff] [review]
final patch

patch checked in on trunk and MOZILLA_1_8_BRANCH
Attachment #286567 - Attachment is obsolete: true


10 years ago
Last Resolved: 10 years ago
Flags: wanted-calendar0.8?
Resolution: --- → FIXED
Flags: wanted-calendar0.8?
Target Milestone: --- → 0.8

Comment 19

10 years ago
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071103 Calendar/0.8pre
You need to log in before you can comment on or make changes to this bug.