REPRODUCTION: ============= - in Lightning or Sunbird's Month View do: * create an event * drag and drop the event to the same day next week RESULT: ======= * Mouse pointer is not released * means X is blocked (no key nor mouse events are handeled) and the user's desktop appears frozen EXPECTED RESULT: ================ * event gets dropped at the new date Note: * possibly a side effect of Bug 312736 * considering a 0.3 Release blocker
Nominating for blocking0.3
*** Bug 348006 has been marked as a duplicate of this bug. ***
*** Bug 348013 has been marked as a duplicate of this bug. ***
*** Bug 348017 has been marked as a duplicate of this bug. ***
Works for me using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060807 Calendar/0.3a2+. Works for me using Lightning/0.1+ (2006080907) with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20060615 Thunderbird/126.96.36.199.
(In reply to comment #5) I forgot: Test was done using storage provider.
Ulf, is this provider specific or no? Can anyone else reproduce this?
In reply to comment #7: no, this is not provider specific. Reproducible for with the storage provider (always). If you fail to reproduce try the following: * drag and drop the event multiple times to different days * use an ssh connection to a remote Lin*x host (ssh -X user@host) and launch tb + lightning
(In reply to comment #7) > Ulf, is this provider specific or no? > > Can anyone else reproduce this? Yep, this helps you (I hope) Error: shadow.parentNode has no properties Source File: chrome://calendar/content/calendar-month-view.xml Line: 471 for more: I can not drag & drop event and when I release button event disappears from main view, is visible only in unifinder I looks like drag&drop is not supported for month view, no matter if this is next week or day - can not drop event :( Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060812 Calendar/0.3a2+
(In reply to comment #9) > I looks like drag&drop is not supported for month view Well sometimes it works, however when I report bug I always try to reproduce with clean profile - and then I could reproduce it. For my working profile it works, strange, so maybe it depends of some settings?
I talked with intern-extraordinaire michael wu. He made a couple of interesting points, which essentially boil down to: we can't fix this in Calendar. 1.) X works on an async drag-n-drop model, while mozilla works on a synchronous model. 2.) The X model has several bugs (patches have been submitted and accepted for the next X release) because of (1) and (2) 3.) There are unavoidable race conditions in drag and drop. (This explains why connecting to a remote X session makes this more reproducable.) As such, I don't see any benefit to blocking the 0.3 release on something that is out of our hands. Blocking the release on this bug would simply mean sitting on our hands for awhile until X and Moz make their respective codebases interact better.
If we can't fix it, we should at least mention it in the release notes.
Should this then dupe against whatever X vs. Moz drag n' drop bug(s) already exist rather than sitting in calendar land?
Not going to make the 0.5 train.
this surely needs fixing before 1.0 and still occurs on all kind of Un*x like systems. Imo blocking 1.0.
(In reply to comment #13) > Should this then dupe against whatever X vs. Moz drag n' drop bug(s) already > exist rather than sitting in calendar land? I second this. This is not a calendar problem, but toolkit's... Anybody knows a toolkit bug we could dupe against?
Not going to happen for 0.8.
Created attachment 337441 [details] [diff] [review] patch v. #1 I am actually working on another drag'n drop issue when I ran into this problem. As it appears to me this indeed looks like a timing problem as Joey stated in comment #11. So while I have been working on that other issue I introduced some timeouts and everything worked fine and in several days I have never again have this problem. With my remote machine a 5 ms timeout was sufficient but in this patch I uses a 10 ms timeout to be sure.
Comment on attachment 337441 [details] [diff] [review] patch v. #1 Add calendar-month-view.xml to jar.mn Quick and dirty, but works; will be overworked either way soon. r=dbo (agreed with Philipp)
Checked in the patch on trunk, MOZILLA_1_8 and SUNBIRD_0_9 ->FIXED
This checkin most probably regressed Bug 454478.
Checked in lightning 0.9 and sunbird 0.9 -> verified.