197305 - setting designMode on data: URLs throws security exception

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Jesse Ruderman]

Trying to set designMode on a data: URL gives the following error:

Error: uncaught exception: [Exception... "Access to restricted URI denied" 
code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)"  location: "..."]

In terms of security, data: URLs are generally considered to have the same
source as the page that linked to or loaded them.

Comment 1

[Jesse Ruderman]

Attachment: testcase

Comment 2

[Martijn Wargers (dead)]

Attachment: patch

This makes it work for me.

Comment 3

[Daniel Veditz [:dveditz]]

Comment on attachment 216989 [details] [diff] [review]
patch

I'm not a peer in content, but sr=dveditz fwiw

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Should the result of GetSecurityManager be checked for OOM cases? Some code in the tree does check, others don't.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 216989 [details] [diff] [review]
patch

GetSecurityManager() is only null during shutdown, so as long as you can guarantee that this code is not running after layout module shutdown you're ok.  And you can guarantee that once bsmedberg's document thing lands.

This looks great.  r=bzbarsky

Comment 6

[Martijn Wargers (dead)]

Checking in content/html/document/src/nsHTMLDocument.cpp;
/cvsroot/mozilla/content/html/document/src/nsHTMLDocument.cpp,v  <--  nsHTMLDocu
ment.cpp
new revision: 3.665; previous revision: 3.664
done

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

This patch was clearly only tested with a MIDAS demo and the test case above
and not with a single document with chrome JS setting designMode...
Sorry, but this is _severely_ broken, designMode does not work at all any more in
that case, and works ONLY in the case of a page embedding an iframe itself
containing the edited document.
If you launch FF and move from about:blank to a page HAVING ITSELF designMode="on", editing is not turned on because CheckSameOriginPrincipal() refuses it.

I am therefore reopening the bug.

This bug is a complete blocker for the contenteditable feature.

Comment 8

[Martijn Wargers (dead)]

Maybe the patch in bug 333922 would fix that issue (I didn't know I broke this, sorry)?

Comment 9

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

This bug is likely to break all xul-based apps using designMode as a
cheap editing solution... If this bug is to remain unsolved for 
FF2.0, and because I have this feeling the original reported bug
above is an hyper-minor edge case, I *STRONGLY* recommend to back
out the patch and revert to the original code.

Comment 10

[Martijn Wargers (dead)]

Afaik, the patch wasn't checked in the 1.8.1 branch. The patch in bug 333922 should fix the issue mentioned in comment 7.

Comment 11

[Boris Zbarsky [:bzbarsky]]

This bug is fixed.  IF there are regressions, please file bugs on them blocking this one.

And yes, this bug was checked in trunk-only.  I'd need to see great incentive to touch the fragile midas/editor mess on branches.

Comment 12

[Brendan Eich [:brendan]]

Comment on attachment 216989 [details] [diff] [review]
patch

Nominating, incentive may be forthcoming from my old pal scotti.

/be

Comment 13

[Martijn Wargers (dead)]

Comment on attachment 216989 [details] [diff] [review]
patch

Brendan forgot to put an email in the approval text input. More or less asking a random person here.
If this is approved, then the patch for bug 197305 also has to be approved.

Comment 14

[Martijn Wargers (dead)]

Er, I meant the patch for bug 333922.

Comment 15

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Requesting 1.8.1 blocking -- starting to hurt major web apps (like Windows Live stuff), and will only become more problematic.

Comment 16

[Martijn Wargers (dead)]

Fixed on 1.8.1 branch by check-in of combined 1.8.1 patch in bug 333922.