User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:188.8.131.52) 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:184.108.40.206) 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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 1.9.2 Branch → Trunk
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.
So you should be able to use a HTML5 data attribute instead of a custom one (bug 598105) to workaround, correct?
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.
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
Status: NEW → ASSIGNED
Attachment #478351 - Flags: review?(roc)
Attachment #478351 - Flags: review?(roc) → review+
blocking2.0: ? → final+
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+
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
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. :-)
status1.9.1: --- → .14-fixed
status1.9.2: --- → .11-fixed
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 ago → 9 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: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/4e4a45a5045d http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8d0accc2738f
status1.9.2: --- → .11-fixed
Test fix ported to 1.9.1: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/944aa1640267
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
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.