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

RESOLVED FIXED in mozilla2.0b7

Status

()

P3
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: spocke, Assigned: Ehsan)

Tracking

({testcase})

Trunk
mozilla2.0b7
testcase
Points:
---
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)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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.
(Reporter)

Updated

9 years ago
blocking1.9.2: --- → ?
blocking2.0: --- → ?
OS: Windows Vista → All
Priority: -- → P3
Version: unspecified → 1.9.2 Branch
(Assignee)

Comment 1

9 years ago
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.
(Assignee)

Updated

9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Version: 1.9.2 Branch → Trunk
(Reporter)

Comment 2

9 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

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

Comment 4

9 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: 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.
(Assignee)

Comment 5

9 years ago
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: --- → ?
(Assignee)

Comment 6

9 years ago
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
Status: NEW → ASSIGNED
Attachment #478351 - Flags: review?(roc)
(Assignee)

Updated

9 years ago
Attachment #478351 - Flags: approval2.0?
blocking2.0: ? → final+
(Assignee)

Updated

9 years ago
Attachment #478351 - Flags: approval2.0?

Comment 7

9 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+
(Assignee)

Comment 8

9 years ago
http://hg.mozilla.org/mozilla-central/rev/b1a8e09a13f4
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
(Assignee)

Comment 9

9 years ago
(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.  :-)
(Assignee)

Updated

9 years ago
Attachment #478351 - Flags: approval1.9.2.11?
Attachment #478351 - Flags: approval1.9.1.14?

Updated

9 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+
(Assignee)

Comment 12

9 years ago
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
apparently SimpleTest.waitForClipboard is also not available? See oranges.
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...
Status: RESOLVED → REOPENED
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.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
(Assignee)

Comment 16

9 years ago
(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.
(Assignee)

Comment 19

9 years ago
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
(Assignee)

Comment 20

9 years ago
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
You need to log in before you can comment on or make changes to this bug.