Closed
Bug 374078
Opened 18 years ago
Closed 18 years ago
Datepicker doesn't change view
Categories
(Calendar :: Lightning Only, defect)
Calendar
Lightning Only
Tracking
(Not tracked)
VERIFIED
FIXED
Lightning 0.5
People
(Reporter: mattwillis, Assigned: mattwillis)
Details
(Whiteboard: [patch in hand] [no l10n impact])
Attachments
(2 files, 1 obsolete file)
2.34 KB,
patch
|
michael.buettner
:
first-review+
|
Details | Diff | Splinter Review |
4.00 KB,
image/png
|
Details |
Spin-off from bug 351380.
The datepicker (_not_ datetextpicker) in Lightning doesn't actually work at the moment. It's a cdt vs jsDate issue. Note that it is also obscured on Mac by bug 346318.
Flags: blocking-calendar0.5+
Assignee | ||
Comment 1•18 years ago
|
||
Note that I left the ltnGoToDate function in for the datetextpicker if/when it gets turned back on.
Assignee: nobody → lilmatt
Status: NEW → ASSIGNED
Attachment #258678 -
Flags: first-review?(michael.buettner)
Assignee | ||
Updated•18 years ago
|
Whiteboard: [patch in hand] [needs review mickey] [no l10n impact]
Comment 2•18 years ago
|
||
Comment on attachment 258678 [details] [diff] [review]
rev0 - Use the same stuff as minimonth
From a technical point of view the patch is correct, r=mickey.
But I'm asking myself what we're actually trying to achieve by adding this stuff. Pressing the dropdown-button of the datetext-picker opens up a new minimonth while we already have a minimonth just above this field. I would like to ask for UI review before landing this, maybe somebody else understands what this is all about ;-)
Attachment #258678 -
Flags: first-review?(michael.buettner) → first-review+
Comment 3•18 years ago
|
||
I would expect a history of previously entered items and not a date picker.
Assignee | ||
Comment 4•18 years ago
|
||
I think the original aim here was to provide a way to enter a date, and not have to navigate to it using the minimonth.
ui-r is a good idea. Let's get mvl's take on this.
Christian: Other ideas for this would be welcome. :)
Comment 5•18 years ago
|
||
Just an idea :-)
Comment 6•18 years ago
|
||
That looks pretty cool, Christian.
Comment 7•18 years ago
|
||
Thanks. The design for the mini month is not final. It should only give an impression how it could look like with an edit field integrated.
Comment 8•18 years ago
|
||
Basically, what I had in mind was more of a list of options instead of a plain text-field. At least, I didn't even know that it's possible to enter text like 'next friday' or something like that into the field until I saw the corresponding code. I suspect that most users don't get into the details of looking into the code how some specific feature actually works ;-) Wouldn't it be much better to have some sort of list with available options the user can choose from? Or is there some hidden clue that I didn't get up to now?
Assignee | ||
Comment 9•18 years ago
|
||
Nope. No clue. You had to know it could handle "tomorrow". That said, I'm not sure how typing in "Friday" is easier or faster than simply clicking on it in the above minimonth.
My opinion is that the only reason for the datepicker would be to make it easy and fast to type in and go to a date. Otherwise you have to use the minimonth to navigate, which could be slow when you have to go backwards or forwards in time quite a bit. (Click on year, scroll to 1974, click on 1974, click on month, scroll to September, click on September, click on the 13th)
I think the datetextpicker is more suited to text entry since it's a textbox and doesn't confusingly popup a version of the very thing above it when you click on it.
So I'm going to check the patch in so the datepicker works, since it doesn't now, and that's just bad. As I said before, I'd like to know mvl's ui opinion on this, and that it should be handled in the spinoff bug 374080.
Assignee | ||
Comment 10•18 years ago
|
||
Patch checked in on MOZILLA_1_8_BRANCH and trunk.
-> FIXED
Please continue the discussion in bug 374080.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: [patch in hand] [needs review mickey] [no l10n impact] → [patch in hand] [no l10n impact]
Comment 11•18 years ago
|
||
Verified with Lightning/0.5pre (2007032003) and Thunderbird/1.5.0.10 (20070221)
Status: RESOLVED → VERIFIED
Comment 12•17 years ago
|
||
Maybe this could be opened as another bug, but I mention it here because of the change to "onchange" event for ltnDateTextPicker.
This event is triggered on every focus-left, even if no change has been done.
Reproduce (on TB 2.0.0.4 + Ltn 0.5 final, WinXP SP2):
- open Inbox
- click into ltnDateTextPicker (maybe copy the displayed date?)
- leave focus, i.e. by clicking into the message pane
- wait a few seconds --> view is changing to Calendar view by ltnMinimonthPick()
I created a quick&dirty hack to check whether the dates in ltnDateTextPicker and ltnMinimonth are different, if the "onchange" comes from ltnDateTextPicker.
Well, I think there could be a much better solution, but I converted the dates to strings, because the initial setting (today) contains the time as well...
Sven.
Comment 13•17 years ago
|
||
Comment on attachment 270147 [details] [diff] [review]
ltnMinimonthPick() to not change view without (real) date change
Sven, please open a new bug and attach your patch there. This bug is already FIXED and VERIFIED.
Attachment #270147 -
Attachment is obsolete: true
Updated•17 years ago
|
Flags: blocking-calendar0.5+
You need to log in
before you can comment on or make changes to this bug.
Description
•