Closed Bug 341518 Opened 14 years ago Closed 12 years ago

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

Categories

(Calendar :: Internal Components, defect, trivial)

x86
Windows XP
defect
Not set
trivial

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: qx1nq3a02, Assigned: berend.cornelius09)

References

Details

Attachments

(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
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
The same thing applies to the arrow buttons above the month view of the main display.
*** Bug 341519 has been marked as a duplicate of this bug. ***
Assignee: nobody → base
Status: UNCONFIRMED → NEW
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.
Attached patch patch for views (obsolete) — Splinter Review
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
Status: NEW → ASSIGNED
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+
patch for views checked in.  Reassigning to default for work on the minimonth.
Assignee: jminta → base
Status: ASSIGNED → NEW
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
Target Milestone: --- → Sunbird 0.3
Not going to make the 0.3 train.
Target Milestone: Sunbird 0.3 → Sunbird 0.4
*** Bug 359635 has been marked as a duplicate of this bug. ***
Not going to make the 0.5 train.
Target Milestone: Sunbird 0.5 → ---
Assignee: nobody → Berend.Cornelius
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)
Would is make sense to start a new dateFormat.dtd file (similar to existing dateFormat.properties) instead of adding more content to global.dtd?
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.
Status: NEW → ASSIGNED
Version: Trunk → unspecified
Attached patch patch v. 2 (obsolete) — Splinter Review
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+
>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
Attached patch final patchSplinter Review
patch checked in on trunk and MOZILLA_1_8_BRANCH
Attachment #286567 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: wanted-calendar0.8?
Resolution: --- → FIXED
Flags: wanted-calendar0.8?
Target Milestone: --- → 0.8
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9pre) Gecko/20071103 Calendar/0.8pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.