Closed
Bug 580710
Opened 14 years ago
Closed 13 years ago
Drag&Drop onto sidebar loads page into sidebar
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
FIXED
Firefox 4.0b9
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: u130342, Assigned: enndeakin)
References
Details
(Keywords: regression, Whiteboard: [has patch])
Attachments
(3 files)
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.
Comment 2•14 years ago
|
||
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
Updated•14 years ago
|
Blocks: 545714
Keywords: regression
Comment 3•14 years ago
|
||
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.
Updated•14 years ago
|
Component: General → Drag and Drop
Product: Firefox → Core
QA Contact: general → drag-drop
Target Milestone: --- → mozilla2.0
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 4•14 years ago
|
||
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:"
Updated•14 years ago
|
Assignee: nobody → enndeakin
blocking2.0: ? → final+
Assignee | ||
Comment 5•14 years ago
|
||
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)
Updated•14 years ago
|
Whiteboard: [has patch][needs review neil]
Updated•14 years ago
|
Component: Drag and Drop → General
Product: Core → Firefox
QA Contact: drag-drop → general
Target Milestone: mozilla2.0 → ---
Comment 6•14 years ago
|
||
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+
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Whiteboard: [has patch][needs review neil] → [has patch]
Comment 7•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/0362605d2623
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b9
You need to log in
before you can comment on or make changes to this bug.
Description
•