Copy, cut, paste from context menu in calendar views do not work

RESOLVED FIXED in 1.0b1

Status

defect
--
major
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: martinschroeder, Assigned: Fallen)

Tracking

Trunk
1.0b1
Bug Flags:
blocking-calendar1.0 +
tb-integration +

Details

(Whiteboard: [needed beta][no l10n impact])

Attachments

(1 attachment, 1 obsolete attachment)

Copy, cut, paste from context menu in calendar views do not work, but the corresponding key shortcuts (Ctrl+[C,X,V]) work flawlessly.
Flags: tb-integration?
Flags: blocking-calendar1.0?
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Flags: tb-integration? → tb-integration+
Assignee: nobody → Berend.Cornelius
Whiteboard: [needed beta][no l10n impact]
Confirmed using Lightning 1.0pre (BuildID: 20090308052121) with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090308 Shredder/3.0b3pre.
Posted patch Fix - v1 (obsolete) โ€” โ€” Splinter Review
Assignee: berend.cornelius09 → philipp
Status: NEW → ASSIGNED
Attachment #366400 - Flags: review?(ssitter)
Comment on attachment 366400 [details] [diff] [review]
Fix - v1

Paste still doesn't work with the patch applied. In addition I'd like to know why Lightning seems to require the additional command attribute. Why does it work in Sunbird without it? Why do the other entries in the context menu work without it?
Attachment #366400 - Flags: review?(ssitter) → review-
Posted patch Fix - v2 โ€” โ€” Splinter Review
(In reply to comment #3)
> (From update of attachment 366400 [details] [diff] [review])
> Paste still doesn't work with the patch applied. 

Fixed paste, this worked from the item context menu but not from the view context menu.

> In addition I'd like to know
> why Lightning seems to require the additional command attribute. Why does it
> work in Sunbird without it? Why do the other entries in the context menu work
> without it?

This has been puzzling me for quite some time. We have had this problem while working with menuitems many times before, but here's my partial theory:

command= makes sure that the "oncommand" attribute is taken over from the actual command.
observes= usually takes over quite some attributes, but this doesn't always seem to be the case for oncommand.

I have no idea why there is a difference between Sunbird and Lightning.
Attachment #366400 - Attachment is obsolete: true
Attachment #367469 - Flags: review?(ssitter)
Whiteboard: [needed beta][no l10n impact] → [needed beta][no l10n impact][needs review]
Attachment #367469 - Flags: review?(ssitter) → review+
Comment on attachment 367469 [details] [diff] [review]
Fix - v2

r=ssitter
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/6db3c7566f86>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [needed beta][no l10n impact][needs review] → [needed beta][no l10n impact]
Target Milestone: --- → 1.0
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.