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

RESOLVED FIXED in mozilla1.8final

Status

defect
--
major
RESOLVED FIXED
14 years ago
9 years ago

People

(Reporter: ajschult784, Assigned: Gavin)

Tracking

(6 keywords)

Dependency tree / graph
Bug Flags:
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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.
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).
Blocks: 327078
I had to shamelessly steal blank.html from nsAboutBlank.cpp
Assignee: js-console → neil
Status: NEW → ASSIGNED
Attachment #213561 - Flags: superreview?(jag)
Attachment #213561 - Flags: review?(bzbarsky)
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
Attachment #213561 - Flags: superreview?(jag) → superreview+
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?
Attachment #213561 - Flags: review?(bzbarsky) → review+
(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 :-)
xpfe patch checked in, over to gavin for toolkit port.
Assignee: neil → gavin.sharp
Status: ASSIGNED → NEW
Port the patch for bug 158475 while I'm at it :)
Attachment #213825 - Flags: review?(neil)
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.
Attachment #213825 - Flags: review?(neil)
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.
Attachment #213561 - Flags: approval1.8.0.3?
Attachment #213561 - Flags: approval1.8.0.2?
Attachment #213561 - Flags: approval1.7.13?
Attachment #213561 - Flags: approval-branch-1.8.1?(jag)
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.
Attachment #213825 - Flags: approval1.8.0.3?
Attachment #213825 - Flags: approval1.8.0.2?
Attachment #213825 - Flags: approval-branch-1.8.1?(mconnor)
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 
Status: NEW → RESOLVED
Closed: 14 years ago
OS: Linux → All
Hardware: PC → All
Resolution: --- → FIXED
Version: Trunk → 1.8 Branch
Attachment #213561 - Flags: approval-branch-1.8.1?(jag) → approval-branch-1.8.1+
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.
(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...
Attachment #213561 - Flags: approval1.8.0.2?
Attachment #213561 - Flags: approval1.8.0.2-
Attachment #213561 - Flags: approval1.7.14?
Attachment #213561 - Flags: approval1.7.13?
Attachment #213561 - Flags: approval1.7.13-
Attachment #213825 - Flags: approval1.8.0.2? → approval1.8.0.2-
Attachment #213825 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+
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
fwiw, this makes it impossible to run some security tests on 1.5.0.2
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.
(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.
Attachment #213561 - Attachment description: Proposed patch → Proposed patch (SeaMonkey fix)
Attachment #213825 - Attachment description: toolkit patch → toolkit patch (Firefox fix)
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.
Attachment #213561 - Flags: approval1.8.0.2- → approval1.8.0.2?
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
Attachment #213561 - Flags: approval1.8.0.3?
Attachment #213561 - Flags: approval1.8.0.2?
Attachment #213561 - Flags: approval1.8.0.2+
Attachment #213561 - Attachment description: Proposed patch (SeaMonkey fix) → Proposed patch (SeaMonkey fix, checked in on trunk and 1.8 and 1.8.0 branches)
Flags: blocking1.8.0.3?
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
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.
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.
Keywords: fixed1.8.0.2
Flags: blocking1.8.0.3? → blocking1.8.0.3+
Comment on attachment 213825 [details] [diff] [review]
toolkit patch (Firefox fix)

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #213825 - Flags: approval1.8.0.3? → approval1.8.0.3+
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
Keywords: fixed1.8.0.3
Target Milestone: --- → mozilla1.8final
Product: Core → SeaMonkey
Attachment #213561 - Flags: approval1.7.14?
Product: SeaMonkey → Core Graveyard
You need to log in before you can comment on or make changes to this bug.