Using an hourly build with patch https://bugzilla.mozilla.org/show_bug.cgi?id=356295 breaks drag&drop. Comment 75 in that bug states that windows is not fixed, yet bug is marked fixed. Bug 356295 should be backed out ASAP.
No errors in console, broken in this hourly: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080825051210 Minefield/3.1a2pre Firefox/3.0 ID:20080825051210
Appears to be fixed in build: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080825093504 Minefield/3.1a2pre Firefox/3.0 ID:20080825093504 which contains the backout of bug 356295
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Re-opening as the checkin of bug 356295 once again broke drag&drop of links to the tab-bar, the address bar, and words to the address bar. Using an hourly build just after the checkin: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080827061801 Minefield/3.1a2pre Firefox/3.0 ID:20080827061801 No errors are noted in the Error Console. 1. Click and drag the link in comment 2 to the address bar note nothing happens.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I didn't notice before, but today doing a drag&drop of a link to anywhere, tab-bar, location bar, search bar or even another window shows the drag operation with the international 'no symbol' 'circle/w slash'. This tells me that no drag operations are allowed. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080828044328 Minefield/3.1a2pre Firefox/3.0 ID:20080828044328
Status: REOPENED → NEW
Component: General → Drag and Drop
Product: Firefox → Core
QA Contact: general → drag-drop
Target Milestone: Firefox 3.1a2 → mozilla1.9.1
Seems so, I can drag left image, but the right one gives the 'no can do' symbol
Created attachment 335934 [details] [diff] [review] fix issues with dragging on Windows and Linux Two issues here: - On Windows, in cases where a drag doesn't set the effectAllowed at the start, the action is initialized to 'none' so a drop doesn't seem to ever occur. Instead, we initialize to all three actions. - On Linux, the dragover nsEvent was being reused for drop, so the cancel flag was still set, causing the event to not do the default action of firing the older xul dragdrop event as well.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago → 10 years ago
Resolution: --- → FIXED
Verified with build: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080901154342 Minefield/3.1b1pre Firefox/3.0 ID:20080901154342
Status: RESOLVED → VERIFIED
This did not fix the issue where dragging a url from the location bar to a folder on the bookmarks toolbar no longer opens sub-folders thus preventing drag and drop into the sub-folders. Neil, known issue or different bug?
Flags: blocking1.9.1? → blocking1.9.1+
You need to log in before you can comment on or make changes to this bug.