Closed Bug 574596 Opened 14 years ago Closed 14 years ago

Links inside Google Reader can't be dragged

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b2
Tracking Status
blocking2.0 --- final+

People

(Reporter: sylvain.pasche, Assigned: MatsPalmgren_bugz)

References

()

Details

(Keywords: regression, testcase)

Attachments

(3 files)

Steps to reproduce:
1) Open Google Reader (http://www.google.com/reader).
2) Navigate to a blog entry containing http links.
3) Try to drag one link to open it in a new tab.

Result:
You can't drag the link.

Expected:
It should be draggable.

I had an old nightly in my Linux vm where this still works:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.3a5pre) Gecko/20100501 Minefield/3.7a5pre

But it doesn't work with:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.3a6pre) Gecko/20100624 Minefield/3.7a6pre
or
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100624 Minefield/3.7a6pre
Attached file Reduced testcase
Based on a Google Reader page.
Regression range:

Works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100524 Minefield/3.7a5pre
http://hg.mozilla.org/mozilla-central/rev/da9e50cb4091

Broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100525 Minefield/3.7a5pre
http://hg.mozilla.org/mozilla-central/rev/ffbc3baf03ae

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=da9e50cb4091&tochange=ffbc3baf03ae
Component: General → Drag and Drop
Product: Firefox → Core
QA Contact: general → drag-drop
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file ../../../../mozilla/content/base/src/nsContentAreaDragDrop.cpp, line 710

That would be the GetTransferData call returning NS_ERROR_FAILURE.
The first bad revision is:
changeset:   42637:0c440c656ada
user:        Mats Palmgren <matspal@gmail.com>
date:        Tue May 25 01:24:15 2010 +0200
summary:     Bug 39098 - Elements with visibility:hidden, visibility:collapse, or display:none get copied to the clipboard. r=dbaron

That seems like an unintended consequence, for sure.  Esp. given the difference between the <a> inside <h2> and not.
Assignee: nobody → matspal
Blocks: 39098
blocking2.0: --- → ?
Attached patch wipSplinter Review
When dragging a node we create a "fake" Selection and process it using
the same code as when dragging a selection, ie with the
SkipInvisibleContent flag set.  Let's make a separate API method
for this case and hide the details in nsCopySupport.
I've pushed this to TryServer to see what breaks....
Attached patch mochitest.diffSplinter Review
Comment on attachment 454565 [details] [diff] [review]
wip

Passed unit tests on TryServer.
Attachment #454565 - Flags: review?(dbaron)
http://hg.mozilla.org/mozilla-central/rev/7ca493708001
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3b2
blocking2.0: ? → final+
You need to log in before you can comment on or make changes to this bug.