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.

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

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.

Can you figure out why it's not going through here? http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsMenuFrame.cpp#738

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

Removing Target Milestone 0.7 because this bug is trunk only.

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.