GNOME Bugzilla – Bug 683997
Calendar meeting moved and new invite sent without prompting
Last modified: 2012-10-25 21:05:08 UTC
When viewing the Evolution calendar, and attempting to open a meeting, it's easy to accidentally drag-and-drop it instead. Even though the meeting is owned by someone else, drag-and-drop still triggers the sending of an invite, to the annoyance of other meeting attendees. Dragging and dropping a meeting should not automatically send a new invite without prompting.
Thanks for a bug report. I tried to reproduce this with On This Computer/Personal calendar, and it works as expected there. It means the meeting which I do not organize is not moved at all, and that I do organize is moved and I'm asked to confirm message sending. Is it possible the dialog with "send or not" was accidentally confirmed when you dropped the meeting on its new position?
If it helps, I'm using the evolution-ews backend, and this occurred with a meeting on the Exchange calendar, not the personal calendar.
Thanks for the update. I believe it's because of that, and I wouldn't be surprised if that will be done by server itself, though I didn't check the code, thus it's possible it's done elsewhere. Either way, I'm moving this to evolution-ews.
Following up on this, I inadvertently reproduced this *again*, and it looks like it didn't occur due to drag-and-drop after all. It happened when I right-clicked on an appointment; the right-click menu opened, with the cursor already over one of the menu items, and when I released the mouse button it looked like it immediately selected that menu item. I don't know which menu item it selected, but it seems to have caused the meeting to move to a later time and sent out a meeting update to every attendee with myself as the owner.
Dropping drag and drop from the subject since this issue seems to occur for a different reason. Moving back to evolution for re-triage, since my original report described the cause incorrectly and thus didn't help reproduce it.
Thanks for the update. In that case this is an issue in gtk+, because the dialog is a standard widget, same as the buttons. There is one similar bug filled already, thus I'm marking this as a duplicate of it. *** This bug has been marked as a duplicate of bug 591258 ***
While I agree that bug 591258 needs fixing, that doesn't seem like the only bug here. It shouldn't be possible for a single context menu item, or a single drag-and-drop, or any similar action to both move the meeting and mail out a new invite *without confirmation*.
The thing is that what you see here is caused by that bug. The reason, from my point of view, without any reading of actual gtk+ code, is that the button or menu items are reacting on mouse-button-up event, also for cases when these widgets did not receive mouse-button-down events. That is what is causing the trouble. You can test it, when you press-down right mouse button on a place with defined context menu. Hold the button down, move above one item, and release the button. The item will be activated. And that's the bug. I'm pretty sure the same happened to you here, only you didn't move the mouse, because the button in the dialog appeared "on the right place", where you had your mouse pointer.
I understand that that bug might have caused the problem, and I can indeed observe the behavior you mentioned, that right-clicking and releasing can activate a context menu item. I'd argue that it seems like an *additional* bug, in Evolution, that a single context menu item (however it gets activated) can cause a meeting to move and spam all attendees with a new invite and incorrect time, with no confirmation whatsoever.