Closed Bug 580710 Opened 9 years ago Closed 9 years ago

Drag&Drop onto sidebar loads page into sidebar

Categories

(Firefox :: General, defect, major)

x86
Windows XP
defect
Not set
major

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.
Attached image sample screenshot
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
Blocks: 545714
Keywords: regression
Attached file testcase
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
blocking2.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+
Attached patch fixSplinter Review
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)
Whiteboard: [has patch][needs review neil]
Component: Drag and Drop → General
Product: Core → Firefox
QA Contact: drag-drop → general
Target Milestone: mozilla2.0 → ---
Blocks: 619355
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+
Keywords: checkin-needed
Whiteboard: [has patch][needs review neil] → [has patch]
http://hg.mozilla.org/mozilla-central/rev/0362605d2623
Status: NEW → RESOLVED
Closed: 9 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.