Closed Bug 580710 Opened 9 years ago Closed 9 years ago
Drag&Drop onto sidebar loads page into sidebar
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1 I have a sidebar extension which makes heavy use by dragging and dropping something from webpages onto this sidebar. I took me a while to find out that there's no problem with my code, I figured this out: - When dragging multiple links everything work's as expected. - When dragging a single link on a control which doesn't support drag&drop by default the the dragged page is loaded into the sidebar. - This happens not only to my extension, even to bookmarks and history sidebars. Reproducible: Always Steps to Reproduce: 1. Load http://google.com 2. Show Bookmarks in sidebar 3. Drag a link from the website onto the "Search" label of bookmarks Actual Results: The sidebar Title remains unchanged (It says for example Bookmarks/History although a web site is loaded) Expected Results: Nothing should happen if something is dragged into the sidebar area. If dragging&dropping is desired behavior there should be options for sidebars to protect against To avoid the confusion, the drag&drop website feature imo should be restricted to the side-bar title. The title of the sidebar should change to something like "Displaying Website". Right clicking the sidebar title could offer the sidebar menu for quick exchange.
the lower right corner shows the browser before dragging, background shows effect after dropping.
Confirmed Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3pre) Gecko/20100721 Minefield/4.0b3pre ID:20100721041129
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
This bug may cause a serious problem(hijack browser). [STR] 1. Open testcase 2. Drag & drop "a link" onto label"Search" of the Bookmarks Sidebar. 3. Click "a link" [Actual] Main browser is hijacked [Expected] Browser should fail in step 2.
Component: General → Drag and Drop
Product: Firefox → Core
QA Contact: general → drag-drop
Target Milestone: --- → mozilla2.0
This also happens on SeaMonkey 2.1. And Shredder/3.2a1pre. So, I think this *should block* early beta. [STR for Shredder3.2a1pre] 1. Start Shredder 2. Open a Message in message pane,(Select a folder and select a message(contained some links) in thread pane) 3. File > New > Message (Ctrl N) 4. Open Contact Sidebar (F9) 5. Drag & drop a link onto label "Address Book:"
Assignee: nobody → enndeakin
blocking2.0: ? → final+
The old content drag/drop handling would only pass null for the nsIWebNavigation to ContentAreaDragDrop, so its dragover listener would get run, but the drop listener would just return early, so no drop would ever happen. browser.js had its own drop handler that got called instead. Now, we set up a dropped link handler and it always gets called. This patch makes it so one has to set a 'droppedLinkHandler' to get anything to happen.
Attachment #464816 - Flags: review?(neil)
Component: Drag and Drop → General
Product: Core → Firefox
QA Contact: drag-drop → general
Target Milestone: mozilla2.0 → ---
Comment on attachment 464816 [details] [diff] [review] fix Sorry for the inordinate delay. It would have been quicker if I had noticed that you had already regressed SeaMonkey in bug 545714.
Attachment #464816 - Flags: review?(neil) → review+
Whiteboard: [has patch][needs review neil] → [has patch]
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b9
You need to log in before you can comment on or make changes to this bug.