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

RESOLVED FIXED in mozilla2.0b7



7 years ago
7 years ago


(Reporter: Spocke, Assigned: Ehsan)



Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 final+, blocking1.9.2 .11+, status1.9.2 .11-fixed, blocking1.9.1 .14+, status1.9.1 .14-fixed)




(1 attachment)



7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: 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: 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:

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.


7 years ago
blocking1.9.2: --- → ?
blocking2.0: --- → ?
OS: Windows Vista → All
Priority: -- → P3
Version: unspecified → 1.9.2 Branch
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.
Ever confirmed: true
Keywords: testcase
Version: 1.9.2 Branch → Trunk

Comment 2

7 years ago
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

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

Comment 4

7 years ago
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:

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.
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?
blocking1.9.1: --- → ?
Created attachment 478351 [details] [diff] [review]
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.
Assignee: nobody → ehsan
Attachment #478351 - Flags: review?(roc)
Attachment #478351 - Flags: approval2.0?
Attachment #478351 - Flags: review?(roc) → review+
blocking2.0: ? → final+
Attachment #478351 - Flags: approval2.0?

Comment 7

7 years ago
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?
blocking1.9.1: ? → .14+
blocking1.9.2: ? → .11+
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
(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.  :-)
Attachment #478351 - Flags: approval1.9.2.11?
Attachment #478351 - Flags: approval1.9.1.14?


7 years ago
Attachment #478351 - Flags: approval1.9.2.11?
Attachment #478351 - Flags: approval1.9.2.11+
Attachment #478351 - Flags: approval1.9.1.14?
Attachment #478351 - Flags: approval1.9.1.14+
status1.9.1: --- → .14-fixed
status1.9.2: --- → .11-fixed
Bustage fix:
Test fix followup on branches: SimpleTest.waitForFocus is not available on branches, so I just replaced it with a setTimeout.
apparently SimpleTest.waitForClipboard is also not available? See oranges.
I've backed this out from 1.9.2 due to persisting test failures:

It looks like 1.9.1 could do with a similar backout/fix...
status1.9.2: .11-fixed → ---
Resolution: FIXED → ---
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.
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
(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.
Landed with test fixes:
status1.9.2: --- → .11-fixed
Test fix ported to 1.9.1:
Yet another follow-up to work around the fact that querySelector is not available on 1.9.1.
Argh, pushed one final 1.9.1 fix which makes the test pass for me locally:
You need to log in before you can comment on or make changes to this bug.