775110 - Cannot Drag Captcha Text into Textarea

Status: REOPENED

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

Description

[therube]

URL: http://forums.mozillazine.org/posting.php?mode=post&f=40

Disable JavaScript
Refresh the page

You should see:

> We need to make sure you are a human. Please solve the challenge below, and
> click the I'm a Human button to get a confirmation code. To make this
> process easier in the future, we recommend you enable Javascript.
 
Followed by a two word phrase
Type the two words into the box
Click, "I'm a human"
(if successful)
Text code is generated
Highlight said text (Ctrl+A)

Attempt to drag the text into any of the textareas on the screen

Mouse pointer changes when hovering the textarea giving an indication that you should be able to drop

Drop

Nothing happens
 
 
This worked in SeaMonkey 2.10 & FF13, but not in SeaMonkey 2.11 nor FF14.
 
 
If you open a new window of URL, you are able to drag the text from the original window into the new window textarea.
 
 
Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a2
Build identifier: 20120718013005

(for Mc.)

Comment 1

[Alice0775 White]

Attachment: testcase

(No need to disable JavaScript)

Comment 2

[Alice0775 White]

Regression window(cached m-c):
Good:
http://hg.mozilla.org/mozilla-central/rev/3de967c4624c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120321 Firefox/14.0a1 ID:20120321025041
Bad:
http://hg.mozilla.org/mozilla-central/rev/f10862ac3217
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120321 Firefox/14.0a1 ID:20120321033140
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3de967c4624c&tochange=f10862ac3217


Regression window(cached m-i):
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/4ce96dfc2c16
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120319 Firefox/14.0a1 ID:20120320075941
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/f163b1d6621e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120320 Firefox/14.0a1 ID:20120320100241
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4ce96dfc2c16&tochange=f163b1d6621e

Suspected: Bug 605991

Comment 3

[Alex Keybl [:akeybl]]

(In reply to Alice0775 White from comment #2)
> Suspected: Bug 605991

As always, thanks Alice :)

This bug wouldn't block release, but would be great to fix for FF15 given the fact that this is a recent regression.

Comment 4

[Neil Deakin]

Bug 605991 caused data being dragged from different domains to not be allowed to be dropped on a parent frame.

In the testcase here, the child frame has a data url. I originally had a check for that which allowed data urls but Olli didn't think it was needed. Maybe it is?

There's a related bug here. The editor code isn't allowing drops from the same domain and should be. I can attach a patch for that.

Comment 5

[Neil Deakin]

Attachment: Allow same domains in editors

Comment 6

[Neil Deakin]

Comment on attachment 648794 [details] [diff] [review]
Allow same domains in editors

This patch doesn't fix the bug, but is needed as part of the fix.

Comment 7

[(no longer active)]

Comment on attachment 648794 [details] [diff] [review]
Allow same domains in editors

Review of attachment 648794 [details] [diff] [review]:
-----------------------------------------------------------------

Shouldn't you use the principals of the documents to check this, the same way that nsHTMLEditor::IsSafeToInsertData works?  In fact you can probably move that method to nsEditor and just use it directly.

Comment 8

[Neil Deakin]

The original bug (with mozillazine) probably isn't fixable without reverting bug 605991 as it relies on dragging text from a child frame from a different domain.

Comment 9

[(no longer active)]

(In reply to comment #8)
> The original bug (with mozillazine) probably isn't fixable without reverting
> bug 605991 as it relies on dragging text from a child frame from a different
> domain.

What do other browser engines do there?

Comment 10

[Neil Deakin]

Attachment: Allow same domains in editors, version 2

Comment 11

[Neil Deakin]

We(In reply to Ehsan Akhgari [:ehsan] from comment #9)
> (In reply to comment #8)
> > The original bug (with mozillazine) probably isn't fixable without reverting
> > bug 605991 as it relies on dragging text from a child frame from a different
> > domain.
> 
> What do other browser engines do there?

Chrome has the same problem.

Comment 12

[(no longer active)]

(In reply to comment #11)
> We(In reply to Ehsan Akhgari [:ehsan] from comment #9)
> > (In reply to comment #8)
> > > The original bug (with mozillazine) probably isn't fixable without reverting
> > > bug 605991 as it relies on dragging text from a child frame from a different
> > > domain.
> > 
> > What do other browser engines do there?
> 
> Chrome has the same problem.

So, WONTFIX?

Comment 13

[Neil Deakin]

Comment on attachment 651073 [details] [diff] [review]
Allow same domains in editors, version 2

Still want to have this patch in though.

Comment 14

[(no longer active)]

Comment on attachment 651073 [details] [diff] [review]
Allow same domains in editors, version 2

Review of attachment 651073 [details] [diff] [review]:
-----------------------------------------------------------------

Sure, looks good!

Comment 15

[Neil Deakin]

Checked into inbound.

Try run: https://tbpl.mozilla.org/?tree=Try&rev=ffbd68c6d1ae

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/70545fbaccd7

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

Updating status flags, we're too late to take something for FF15 here but please nominate for uplift to 16 when ready.

Comment 18

[Alex Keybl [:akeybl]]

Can we get this fix nominated for FF16 Neil?

Comment 19

[(no longer active)]

(In reply to Alex Keybl [:akeybl] from comment #18)
> Can we get this fix nominated for FF16 Neil?

This patch doesn't fix the bug.  See comment 11.

Comment 20

[Alex Keybl [:akeybl]]

Thanks Ehsan. Given comment 11, users will just have to copy/paste instead of drag. We have not gotten significant user complaints since FF14.

Comment 21

[Neil Deakin]

Not working on this. Chrome doesn't allow this either, so we probably won't fix this.

Comment 22

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.