333922 - Setting designMode doesn't work with enhanced privileges on a frame with a different domain

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Martijn Wargers (dead)]

See upcoming testcase.

I've used 
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite");
for it, so I was hoping I could set designMode for documents at a different domain.
However, that doesn't work currently.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Martijn Wargers (dead)]

Attachment: patch

This fixes it for me.
Not sure if this is enough.
I got a js error message some time before with this patch, but now I'm not seeing that js error message anymore.
Currently undo is not working anymore, so I have something screwed up.

Comment 3

[Martijn Wargers (dead)]

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

Ok, tested this again.
It doesn't cause any problems mentioned in comment 2.
It doesn't solve this bug, though.
But it is necessary to solve the regression as mentioned in bug 197305, comment 7.
I've tested that this makes it at least possible for chrome code to set designMode.

Comment 4

[Martijn Wargers (dead)]

I probably should morph this bug into the more general problem that with UniversalBrowserWrite privileges, you still aren't allowed to access window/document properties from other domains.

Comment 5

[Martijn Wargers (dead)]

Ah, sorry, I just need to do netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead UniversalBrowserWrite"); for it to work, so there is no 'general problem' as mentioned in comment 4.

Comment 6

[Martijn Wargers (dead)]

Attachment: Correct testcase

This is a correct testcase, using netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead UniversalBrowserWrite");

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Makes sense.  Thanks for fixing this!

r+sr=bzbarsky

Comment 8

[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.682; previous revision: 3.681
done

Comment 9

[Martijn Wargers (dead)]

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

Brendan asked approval for the patch in bug 197305, in that case, this bug needs also be approved.

Comment 10

[Boris Zbarsky [:bzbarsky]]

This is going to need some merging to land on branch...

Comment 11

[Martijn Wargers (dead)]

Attachment: 1.8.1 branch patch

Ok, this is a combined patch for this bug and for bug 197305.
It is a bit different from the original patch on trunk, because NodePrincipal() does't exist on 1.8.1 branch.
Boris already took a look on it, but just to be sure, I'm asking review on him. I've checked that this fixes the two bugs.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 226413 [details] [diff] [review]
1.8.1 branch patch

Yeah, looks great

Comment 13

[Martijn Wargers (dead)]

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

Fixed on 1.8.1 branch.