Closed
Bug 412948
Opened 16 years ago
Closed 16 years ago
Tasks cannot be deleted
Categories
(Calendar :: Tasks, defect)
Calendar
Tasks
Tracking
(Not tracked)
RESOLVED
FIXED
0.8
People
(Reporter: klint, Assigned: berend.cornelius09)
References
Details
(Keywords: regression)
Attachments
(3 files, 1 obsolete file)
1.17 KB,
patch
|
michael.buettner
:
review+
|
Details | Diff | Splinter Review |
19.91 KB,
patch
|
michael.buettner
:
review+
|
Details | Diff | Splinter Review |
1.34 KB,
patch
|
dbo
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.9 ID:2007103104 Lightning 20080118 Tasks cannot be deleted anymore in today pane or tasks unifinder since last build (at least for remote ICS calendar) Reproducible: Always Steps to Reproduce: 1.Select a task in Today pane or in Unifinder (tested on ICS remote calendar) 2.Right click to delete 3.Exit and enter TB again (to refresh task view... Another bug ;) ) Actual Results: The task still appears. Expected Results: The task should have been deleted. Was working ok on previous build (20080117)
Comment 1•16 years ago
|
||
Does the Error Console provide more information?
Comment 3•16 years ago
|
||
Confirmed with Lt 2008011716/ Tb 2.0.0.9
Status: UNCONFIRMED → NEW
Ever confirmed: true
No, it is empty. One other remark though : I don't know why, but the "new task" entry is greyed in the contextual menu of the today pane (although I'm able to add a new task using the new bottom line
Comment 5•16 years ago
|
||
I can't see any error in console. Regression range: Works with 2008011704 fails with 2008011716
Keywords: regression
Updated•16 years ago
|
Flags: blocking-calendar0.8?
Updated•16 years ago
|
OS: Windows XP → All
Hardware: PC → All
By the way, should I file a new bug for the fact that the "new task" entry is greyed out in the contextual menu of the today pane and in the unifinder as well ? Or is it related to this one ? Thansk
Comment 7•16 years ago
|
||
I guess all the task related regressions are caused by the same change. Checkins during regression range: http://tinyurl.com/2zeo6j
Comment 8•16 years ago
|
||
It's caused by the patch from bug 412613. The command controller forwards to Thunderbird's default command controller in case we're in calendar mode. It doesn't take the task mode into account. isCalendarInForeground() needs to be adapted accordingly.
Updated•16 years ago
|
Flags: blocking-calendar0.8? → blocking-calendar0.8+
Comment 9•16 years ago
|
||
Thanks for the tip mickey, saved me from having to look for the bug myself :)
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #297790 -
Flags: review?(michael.buettner)
Comment 10•16 years ago
|
||
Comment on attachment 297790 [details] [diff] [review] Fix commands for task mode >+ return isSunbird() || (gCurrentMode && gCurrentMode != "mail"); It's correct to check for *not in mail mode*, so that's just fine. Although, I'd suggest to rename isCalendarInForeground(). r=mickey.
Attachment #297790 -
Flags: review?(michael.buettner) → review+
Comment 11•16 years ago
|
||
Checked in on HEAD and MOZILLA_1_8_BRANCH -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.8
Comment 12•16 years ago
|
||
It's still impossible to delete tasks in Mail Mode. It's fixed for Task Mode (Lt 2008011907)
Assignee | ||
Updated•16 years ago
|
Assignee: philipp → Berend.Cornelius
Status: REOPENED → NEW
Assignee | ||
Comment 15•16 years ago
|
||
This fix should solve the problem. On the way I also fixed the buggy "Mark Completed" menuitem and took care that all calendar and event/todo related menuitems are correctly enabled in all three thunderbird modes.
Attachment #298435 -
Flags: review?(michael.buettner)
Comment 16•16 years ago
|
||
Comment on attachment 298435 [details] [diff] [review] patch v. 2 >+ default: >+ if (aCommand in this.commands) { >+ // All other commands we support should be enabled by default >+ return true; >+ } It's indeed correct to handle the calendar commands even if we're in mail mode, hope we're approaching the final version of this particular function... :-) r=mickey.
Attachment #298435 -
Flags: review?(michael.buettner) → review+
Assignee | ||
Comment 17•16 years ago
|
||
patch checked in on trunk and MOZILLA_1_8_BRANCH =>FIXED
Status: NEW → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Comment 18•16 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/2008012309 Calendar/0.8pre This checkin caused the following strict warnings: Warning: function cC_doCommand does not always return a value Source File: chrome://calendar/content/calendar-common-sets.js Line: 265, Column: 26 Source Code: return; Warning: function cC_doCommand does not always return a value Source File: chrome://calendar/content/calendar-common-sets.js Line: 268, Column: 14 Source Code: return;
Comment 19•16 years ago
|
||
This patch fixes task warning.
Attachment #299499 -
Flags: review?(daniel.boelzle)
Comment 20•16 years ago
|
||
Comment on attachment 299499 [details] [diff] [review] [checked in] Fix warning r=dbo
Attachment #299499 -
Flags: review?(daniel.boelzle) → review+
Comment 21•16 years ago
|
||
Comment on attachment 299499 [details] [diff] [review] [checked in] Fix warning Checked in extra patch on both branches.
Attachment #299499 -
Attachment description: Fix warning → [checked in] Fix warning
Comment 22•16 years ago
|
||
Comment on attachment 299499 [details] [diff] [review] [checked in] Fix warning >- return this.defaultController.doCommand(aCommand); >+ this.defaultController.doCommand(aCommand); Is the change in behavior intended? Previously the default controller would handle the command and return. Now the default controller and the calendar controller handle the command. Should there be an additional "return;" line added?
Comment 23•16 years ago
|
||
No, that was quite stupid of me. It should of course be this.defaultController.doCommand(aCommand); return; I think it was 3AM when I cheked that in. Thanks for catching it! Checked in a fix for the fix -> FIXED (again)
Comment 24•16 years ago
|
||
Berend: Can you please comment on this? I assume my patch does what you wanted, but I'm not quite sure. I think it's not worth to file another bug for that: "Print button is always enabled in mail mode"
Attachment #299993 -
Flags: review?(Berend.Cornelius)
Comment 25•16 years ago
|
||
Adding patches for different issues to fixed bugs is inappropriate in my opinion. In generally one bug should handle one topic. Or is the current behavior a regression caused by this bug?
Comment 26•16 years ago
|
||
Well, you are right. It's not really a regression, because it did never occur before this patch was checked in. But it's a kind of inversion for bug 394358, which I think should be fixed together with this... I'm fine to file a spin-off for that, but I thought it would not be worth the trouble.
Assignee | ||
Comment 27•16 years ago
|
||
Your patch works good. I have noticed the same thing as I am working on the task-toolbar and was about to solve it just the same way. Anyway I suggest to set up a spin off bug that I will immediately approve and check in.
Updated•16 years ago
|
Attachment #299993 -
Attachment is obsolete: true
Attachment #299993 -
Flags: review?(Berend.Cornelius)
You need to log in
before you can comment on or make changes to this bug.
Description
•