328932 - Evaluating Components.classes in JS Console throws an exception "Error: uncaught exception: Permission denied to get property UnnamedClass.classes"

Status: RESOLVED FIXED

(Core Graveyard :: Error Console, defect)

Description

[Andrew Schultz]

Attempting to evaluate "Components.classes" in the JS Console window results in an exception:

Error: uncaught exception: Permission denied to get property UnnamedClass.classes

Backing out the checkin from bug 327078 and bug 328469 unbreaks it.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So the JS console is setting the "src" of an about:blank iframe (the <iframe> itself is in a chrome document, but has about:blank loaded in it) to a javascript: URI and expects that to run with chrome privileges.  I purposefully disabled that in bug 327078, and I think that the right fix is to fix the JS console to preload a chrome URI in that iframe or to use a sandbox to evaluate the JS or something.

Note that for normal users all of this is a non-issue, imo (so I see no reason to scramble to fix this on branches; if we fix it, we fix it).

Comment 2

[[e-mail]]

Attachment: Proposed patch (SeaMonkey fix, checked in on trunk and 1.8 and 1.8.0 branches)

I had to shamelessly steal blank.html from nsAboutBlank.cpp

Comment 3

[jag (Peter Annema)]

Comment on attachment 213561 [details] [diff] [review]
Proposed patch (SeaMonkey fix, checked in on trunk and 1.8 and 1.8.0 branches)

Index: console/resources/content/blank.html
===================================================================

\ No newline at end of file

Comment 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 213561 [details] [diff] [review]
Proposed patch (SeaMonkey fix, checked in on trunk and 1.8 and 1.8.0 branches)

r=bzbarsky, but doesn't toolkit need a similar fix?  Or is the idea that this patch applies to both xpfe and toolkit?

Comment 5

[[e-mail]]

(In reply to comment #3)
>(From update of attachment 213561 [details] [diff] [review] [edit])
>Index: console/resources/content/blank.html
>===================================================================
>\ No newline at end of file
I actually saved about:blank, which has no newline...
alternatively I could use data:text/html, instead?

(In reply to comment #4)
>doesn't toolkit need a similar fix?
I'm sure gavin is eager to port the fix :-)

Comment 6

[[e-mail]]

xpfe patch checked in, over to gavin for toolkit port.

Comment 7

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

Attachment: toolkit patch (Firefox fix)

Port the patch for bug 158475 while I'm at it :)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Note that this is probably needed on all 4 branches too, since bug 327078 landed on those.  Unless we're ok with breaking this on branches.

Comment 9

[[e-mail]]

Comment on attachment 213561 [details] [diff] [review]
Proposed patch (SeaMonkey fix, checked in on trunk and 1.8 and 1.8.0 branches)

Fix for regression from bug 327078.

Comment 10

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

Comment on attachment 213825 [details] [diff] [review]
toolkit patch (Firefox fix)

It'd be nice to not regress the JS console functionality for 1.5.0.2.

Comment 11

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

mozilla/toolkit/components/console/content/console.xul 	1.7
mozilla/toolkit/components/console/content/console.js 	1.4
mozilla/toolkit/components/console/content/blank.html 	1.1
mozilla/toolkit/components/console/jar.mn 	1.6 

Comment 12

[[e-mail]]

Comment on attachment 213561 [details] [diff] [review]
Proposed patch (SeaMonkey fix, checked in on trunk and 1.8 and 1.8.0 branches)

Checked into the MOZILLA_1_8_BRANCH.

Comment 13

[[e-mail]]

(In reply to comment #7)
>Port the patch for bug 158475 while I'm at it :)
Oddly I seem to be able to back out that patch without regressing the bug...

Comment 14

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

mozilla/toolkit/components/console/content/console.xul 	1.5.10.2
mozilla/toolkit/components/console/content/blank.html 	1.1.2.2
mozilla/toolkit/components/console/jar.mn 	1.5.18.1
mozilla/toolkit/components/console/content/console.js 	1.3.10.1

Comment 15

[Bob Clary [:bc] (inactive)]

fwiw, this makes it impossible to run some security tests on 1.5.0.2

Comment 16

[Tim Riley [:timr]]

After talking to the Release Team (dveditz, mscott, and others) we feel that the "proposed patch" directly affects Firefox and would require a respin.  The fix is important, but not worth a respin.  Should be a no brainer for 1.5.0.3

The "toolkit patch" can land as it is independent of Firefox.  We won't rebuild for this.  We will be building FF 1.5.0.2 based on tags from when QA started the final tests about a week or two ago.  But this allow Seamonkey to build off of this code.  If you request toolkit patch approval1.8.0.2, we will approve it to land now.

Comment 17

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

(In reply to comment #16)
> The "toolkit patch" can land as it is independent of Firefox.  We won't rebuild
> for this.

Just to be clear, the "toolkit patch" is the patch that affects Firefox - the "proposed patch" is Seamonkey-only.

Comment 18

[[e-mail]]

Comment on attachment 213561 [details] [diff] [review]
Proposed patch (SeaMonkey fix, checked in on trunk and 1.8 and 1.8.0 branches)

As per comment 16 rerequesting approval for SeaMonkey change to land in closed 1.8.0 branch.

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 213561 [details] [diff] [review]
Proposed patch (SeaMonkey fix, checked in on trunk and 1.8 and 1.8.0 branches)

approved for 1.8.0 branch, a=dveditz for drivers

Comment 20

[Tim Riley [:timr]]

Comment on attachment 213561 [details] [diff] [review]
Proposed patch (SeaMonkey fix, checked in on trunk and 1.8 and 1.8.0 branches)

It looks like ths landed o 3/17/06.  If so, please mark the bug with keyword: fixed1.8.0.2

Comment 21

[Andrew Schultz]

Tim: Only the SeaMonkey-only change landed on the 1_8_0 branch.  The toolkit version has not landed on the 1_8_0 branch.

Comment 22

[Daniel Veditz [:dveditz]]

adding fixed1.8.0.2 keyword because the seamonkey patch is checked in. This will also get a fixed1.8.0.3 keyword when the toolkit version is in. Sorry for all the confusion, but this is an edge case for the current way we're abusing bugzilla flags for branch tracking.

Comment 23

[Daniel Veditz [:dveditz]]

Comment on attachment 213825 [details] [diff] [review]
toolkit patch (Firefox fix)

approved for 1.8.0 branch, a=dveditz for drivers

Comment 24

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

Toolkit patch checked in on the 1_8_0 branch for Firefox 1.5.0.3.

mozilla/toolkit/components/console/jar.mn 	1.5.26.1
mozilla/toolkit/components/console/content/blank.html 	1.1.8.2
mozilla/toolkit/components/console/content/console.js 	1.3.18.1
mozilla/toolkit/components/console/content/console.xul 	1.5.10.1.4.1