Closed Bug 362498 Opened 18 years ago Closed 17 years ago

[Trunk] Date picker still reacts on clicks after being closed (date picker is invisible)

Categories

(Calendar :: General, defect)

Product:
Calendar
Component:
General
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: vipers1012000, Unassigned)

References

Details

(Keywords: regression) 

Steps to reproduce
1. Click New Event
2. Click the arrow on From to open mini-calendar control
3. Click any date
4. Click the arrow to close mini-calendar control

Expected result:
Click on anywhere at the space previously occupied by mini-calendar control and the date will change. If you hover the mouse over the space, the pointer changes to hand cursor.

Reproducible: Always
I have also tried the STR and can confirm the same problem (even after multiple reboots) and re-installation of the Calendar Application (0.4a1)
I can confirm this bug while using:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061201 Calendar/0.4a1


(In reply to comment #0)
> Steps to reproduce
> 1. Click New Event
> 2. Click the arrow on From to open mini-calendar control
> 3. Click any date
> 4. Click the arrow to close mini-calendar control
> 
> Expected result:
> Click on anywhere at the space previously occupied by mini-calendar control and
> the date will change. If you hover the mouse over the space, the pointer
> changes to hand cursor.
> 
> Reproducible: Always
> 

(In reply to comment #0)
> Steps to reproduce
> 1. Click New Event
> 2. Click the arrow on From to open mini-calendar control
> 3. Click any date
> 4. Click the arrow to close mini-calendar control
> 
> Expected result:
> Click on anywhere at the space previously occupied by mini-calendar control and
> the date will change. If you hover the mouse over the space, the pointer
> changes to hand cursor.
> 
> Reproducible: Always
> 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061201 Calendar/0.4a1
*** Bug 362510 has been marked as a duplicate of this bug. ***
I'm copying the steps to reproduce from Bug 365861, because some of it's different.
Note that the mini-calendar goes away properly if you don't pick a date on it.  Not a useful workaround, but it shows that whatever's making it not close has to do with clicking on the mini-calendar part.

Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre)
Gecko/20070103 Calendar/0.4a1

Steps to Reproduce:
1. Add a new Event or Task, or edit an existing one.
2. Open the date-picker's calendar by clicking the down arrow by either the
From or To date.
3. Pick a date.  It doesn't work if you close it by clicking the arrow again.
4. Now that the calendar's gone, move the mouse over the space where the
calendar was.
5. Try clicking in that space - for example, near the top-left corner of the
Description box.
Actual Results:  
The cursor is a hand where the dates on the calendar were.  Clicking when the
cursor's a hand sets the date as if the calendar were open.  Clicking above
results in the Month or Year menu, depending on where you clicked.  Upon
choosing a date, the calendar appears for a flash.
Simply, the mouse behaves as if the calendar were still there.
Raising severity and nominating as an 0.5 blocker.  Similar problems are reproducable on Mac as well and take the app below dogfood status, in my opinion.
Severity: normal → critical
Flags: blocking-calendar0.5?
OS: Windows XP → All
Hardware: PC → All
Summary: Mini-calendar control in New Event window is not closed properly → Date picker still reacts on clicks after being closed (date picker is invisible)
Same regression range as in bug 364034:

Works in Sunbird/0.4a1 (2006-11-29-04)
Fails in Sunbird/0.4a1 (2006-11-30-04)

Checkins to directory mozilla/calendar: http://tinyurl.com/ykg2fu
Checkins to directory mozilla/: http://tinyurl.com/yfkuuk
Most likely candidate is bug 324963
Keywords: regression
Yes, probably we aren't removing the date picker from the active popup list. How is the date picker designed? How is it dismissed?
The datepicker basically is:
<menulist><menupopup><minimonth/></menupopup></menulist>.
The minimonth has its own <popupset/> with <popup/>s in it.
The problem is that the datepicker want the main popup to stay open after an item in the subpopups (those inside the minimonth) are selected. Doing this naively leads to a minimonth that does not react to clicks anymore. The workaround we had was to close and open the main popup. That worked until now.
After closing the main popup (after the close-and-open), it is not longer visible, but still reacts to clicks.
And due to some eventlisteners etc, we do the close-and-open right after first opening it, removing the need to open the sub-popups.

If you don't understand anything of the hacks I tried to describe, feel free to ask me on IRC. I admit that it's all ugly and hackish. 
I can't. SImply because it does get called.
I added a printf, and i see it getting caled twice when i close the minimonth popup without opening the child popup. When i open the child and close it, I see the printf once. Then, I see it twice when i close it. Just as before. So I can't find any difference.
Works in Sunbird/0.4a1 (2007-02-25-05, win32, mozilla1.8)
Fails in Sunbird/0.6a1 (2007-02-25-05, win32, trunk)
 -> Issue is trunk only, doesn't need to block 0.5 release
(In reply to comment #14)
> Works in Sunbird/0.4a1 (2007-02-25-05, win32, mozilla1.8)
> Fails in Sunbird/0.6a1 (2007-02-25-05, win32, trunk)
>  -> Issue is trunk only, doesn't need to block 0.5 release
> 

There is still a bug in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3pre) Gecko/20070228 Calendar/0.5pre

If you click on the drop down arrow of the From field and then double click on current month or year in the mini-calendar (by double click I mean click on the current month or year and then click it again without selecting another month or year), the mini-calendar freezes.
(In reply to comment #16)

This is Bug 356505
Since it's trunk-only, this doesn't block 0.5.
Moving milestone to 0.7
Flags: blocking-calendar0.5? → blocking-calendar0.5-
Target Milestone: --- → Sunbird 0.7
Component: Tasks → General
QA Contact: tasks → general
Removing Target Milestone 0.7 because this bug is trunk only.
Target Milestone: 0.7 → ---
Summary: Date picker still reacts on clicks after being closed (date picker is invisible) → [Trunk] Date picker still reacts on clicks after being closed (date picker is invisible)
I can't reproduce any problems anymore one mac-trunk builds. Maybe fixed by bug 279703?
(I have to mention that i can't even try step 4 from comment 0: the dropdown automatically disappears after clicking on a date)
Issue is reproducible in the latest available nightly build (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/20070702 Calendar/0.6a1).

I will retest once a newer trunk nightly build is available that contains the changes from Bug 279703.
Issue is now WORKSFORME using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007082906 Calendar/0.6a1. Most probably fixed by Bug 279703.

Can someone confirm on Linux / Mac OS X?
Issue is also WORKSFORME using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007100204 Calendar/0.6a1.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Flags: blocking-calendar0.5-
You need to log in before you can comment on or make changes to this bug.