599322 - Base href ignored for drag/drop or copy/paste in designMode

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Spocke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729; .NET4.0E)

The <base href=".."> gets ignored when you perform a drag/drop or copy/paste inside a designMode area. This affects existing products like TinyMCE and this didn't happen before the 3.6.9 minor release. I would guess that the mfsa2010-62 has something to do with this.

Reproducible: Always

Steps to Reproduce:
1. Open the attached URL.
2. Drag/drop or copy/paste the images inside the iframe.
3. Notice that the image becomes broken.
Actual Results:  
The images are broken after a drag/drop since the URLs are relative to the current page not the base path.

Expected Results:  
The images should have the URL intact or be relative to the right location.

I guess this one messed things up:
http://www.mozilla.org/security/announce/2010/mfsa2010-62.html

It might be better to not filter the contents in drag/drop or copy/paste on the same domain if possible. Since elements can contain other things you want to retain such as custom attributes.

Comment 1

[(no longer active)]

This doesn't have anything to do with the fix to MSFA2010-62.  The same problem is reproducible in 3.6.8 using the test case in this bug as well.

Comment 2

[Spocke]

Ahh we had a fix in TinyMCE for this issue where we use a custom attribute called _mce_src that holds the original url. We restore the correct url by using that attribute on drop. The MSFA2010-62 strips all attributes except valid ones so that custom attribute gets removed and then our fix doesn't work any more. I guess should file a new bug report regarding that but this issue is the original bug that prompted us to do the workaround.

Comment 3

[LegNeato]

So you should be able to use a HTML5 data attribute instead of a custom one (bug 598105) to workaround, correct?

Comment 4

[Spocke]

Yes, but existing applications that uses TinyMCE would break such as Wordpress and there is a lot of users out there that would get upset. We use the _mce_ prefix similar to the _moz_ prefix in TinyMCE and it would be ideal if they where retained. But the attribute filtering issue is being discussed at a separate bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=596300

So please remove the reference to MSFA2010-62 from this bug if possible since it doesn't have any relevance to this one. This one is only about the base href being ignored when dropping or pasting contents.

Comment 5

[(no longer active)]

Spocke, I have a very safe patch (it's a one-liner code wise) which solves this issue, and I think we can take that patch on the branch.  But until the next dot-release, you can use Christian's suggestion.

Christian, may I recommend that this bug blocks the next dot release for both branches?

Comment 6

[(no longer active)]

Attachment: Patch (v1)

GetDocBaseURI returns the base URI if one is available, or the document URI if it's not.  With this, the base URI if present ends up overriding the document URI, which is what we want.

Comment 7

[LegNeato]

Marking as blocking. Ehsan, do you think this will come in by tomorrow night, or do you think it should be deferred until the next one?

Comment 8

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/b1a8e09a13f4

Comment 9

[(no longer active)]

(In reply to comment #7)
> Marking as blocking. Ehsan, do you think this will come in by tomorrow night,
> or do you think it should be deferred until the next one?

It will hopefully come in by tonight.  :-)

Comment 10

[(no longer active)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0a7c2a5e6783
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/50468ded710c

Comment 11

[(no longer active)]

Bustage fix:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8d42a507bb40
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/372481ff0103

Comment 12

[(no longer active)]

Test fix followup on branches: SimpleTest.waitForFocus is not available on branches, so I just replaced it with a setTimeout.

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ee78fb6afe02
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/09e1a8d09661

Comment 13

[Wolfgang Rosenauer [:wolfiR]]

apparently SimpleTest.waitForClipboard is also not available? See oranges.

Comment 14

[Mark Banner (:standard8)]

I've backed this out from 1.9.2 due to persisting test failures:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/d59afde40273

It looks like 1.9.1 could do with a similar backout/fix...

Comment 15

[Mark Banner (:standard8)]

Sorry, this bug is still fixed on trunk, so shouldn't have reopened it - the status1.9.2 flag should be enough to track this.

Comment 16

[(no longer active)]

(In reply to comment #13)
> apparently SimpleTest.waitForClipboard is also not available? See oranges.

Sigh.  Without SimpleTest.waitForClipboard, this is not possible to test reliably.  I guess I'll have to steal waitForClipboard's code from trunk and add it to the test.

Comment 17

[(no longer active)]

Landed with test fixes:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/4e4a45a5045d
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8d0accc2738f

Comment 18

[(no longer active)]

Test fix ported to 1.9.1:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/944aa1640267

Comment 19

[(no longer active)]

Yet another follow-up to work around the fact that querySelector is not available on 1.9.1.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a95320254fbb

Comment 20

[(no longer active)]

Argh, pushed one final 1.9.1 fix which makes the test pass for me locally:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5d57c5cc2033