426131 - Permission denied to get property History.previous in chrome

Status: RESOLVED INVALID

(Core :: XPConnect, defect)

Description

[John J. Barton]

Attachment: [e-mail] in zip file

In Firebug I try to enumerate window.history but I get an exception. The attached test extension demonstrates it.  It prints from in a web page and in an extension:
'
From Web Page history.previous FAILED:Error: Permission denied to get property History.previous
========== Test Starts =========
win is ...
Test threw: Error: Permission denied to get property History.previous

Comment 1

[John J. Barton]

In the Firebug code I have a bit more info on the exception:

[message]=Permission denied to get property History.current;
[fileName]=XPCSafeJSObjectWrapper.cpp;
[lineNo]=445;
[pos]=0;
[flags]=2;
[errnum]=206;
[exc]=[xpconnect wrapped jsdIValue];

Comment 2

[John J. Barton]

I also get this in other places in Firebug, but its really hard to pin down since the message is so worthless.
Permission denied to get property Location.href
XPCSafeJSObjectWrapper.cpp
Line 445

Comment 3

[Brian Crowder]

John:  Can't you use your window observer to do this via message-passing?

Comment 4

[John J. Barton]

Do what? I am just enumerating the properties to populate the DOM panel.  The vast majority of properties work.  History does not. The Location.href is completely different, in another part of the code. But in both cases I am in chrome code and the access should be allowed.  Or the message needs to tell me why not.

Comment 5

[Brian Crowder]

Actually, I only get this history error if I am trying to access window.history.previous from inside your observer, or within a sandbox.  If I use straight eval from the commandLine.js code:

try {
    result = eval(expr)
} catch (e) {
    result = "eval threw: " + e;
}
dump("======= result: " + result + "\n");


Then I get the following error message:
======= result: eval threw: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHistory.previous]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://firebug/content/commandLine.js :: anonymous :: line 31"  data: no]

Not permission denied.  I'm still investigating.

Comment 6

[John J. Barton]

I set this to firebug-p1, because I believe it is the same problem as other examples of the same error message which cause more harm to Firebug but are harder to reproduce.

Comment 7

[Brian Crowder]

I can't get the extension from comment 0 to produce the "Test Starts" output.

Comment 8

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

If we have a SJOW, I would sort of _expect_ that we would be running with content privileges when firing the getter.  I can't get the test extension to produce results either, though, so it's hard to tell. :(

Comment 9

[Brian Crowder]

By default, History.previous needs UniversalBrowserRead privilege to be accessed (same origin isn't enough).  This preference is set in all.js.

Therefore, the bug as it stands is INVA

Comment 10

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

Chrome has UBR, though -- if we're using an XPCWN rather than a SJOW for History, then I would expect that we would access .previous with chrome privs.  Which part of that is not the case?

Comment 11

[Brian Crowder]

If you want to access with chrome privileges, you should use eval() not evalInSandbox() or a message to a listener in content.  My eval() test was bogus, I should've been using targetWindow.history.previous, which does work (if you've got history -- otherwise, it does yield an exn).

Comment 12

[Brian Crowder]

It's worth noting that most (all?) chrome windows do not have history (browser.xul, for example, does not), so to get history, you must properly reference a content window (such as targetWindow, from the firebug commandLine.js evaluateAndShow() function).

Comment 13

[Johnny Stenback (:jst)]

Bug 429759 filed on history.previous throwing when there's no previous page, FWIW.

Comment 14

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

What's using evalInSandbox?  The test code uses:

var win = getBrowser().contentWindow;
var unwrapped = win.window.wrappedJSObject;
dump(unwrapped.history.previous)

I think that means that unwrapped is a SJOW, and will run the getter with content privs.  If Firebug wants chrome privileges for those pieces that content can't access, then it should probably trap the security exception and ask via an XPCNW.

mrbkap: is there a good way to create an XPCNW from a SJOW, without going back up to the root thing that we unwrapped, and descending without unwrapping?

Comment 15

[Brian Crowder]

Well, I can't get that test extension to work.  Firebug has XPCNW by default now, though, so getting them is as easy as using the window objects it already has (as I demonstrated with the commandLine.js using targetWindow).  I think the references to SJOWs in the earlier comments by John J. Barton are obsolete now.  He can correct me.


This log is made using my eval hack in commandLine.js
>>> targetWindow
======= result: [object XPCNativeWrapper [object Window @ 0x1d155400 (native @ 0x1d15458c)]]

>>> targetWindow.history
======= result: [object XPCNativeWrapper [object History @ 0x1dee6d00 (native @ 0x1cb863e0)]]

>>> targetWindow.history.previous
======= result: http://www.mozilla.org/projects/minefield/


>>> targetWindow.wrappedJSObject
======= result: [object Window @ 0x1d155400 (native @ 0x1d15458c)]

>>> targetWindow.wrappedJSObject.history
======= result: [object History @ 0x1d436920 (native @ 0x1cb863e0)]

>>> targetWindow.wrappedJSObject.history.previous
======= result: eval threw: Error: Permission denied to get property History.previous


Yes, you're right, unwrapped is an SJOW and its getter will run with content privs (denied).  Using a try..catch to fallback to chrome privs -might- be okay, but it makes my spidey-sense tingle.

Comment 16

[John J. Barton]

(In reply to comment #15)
> Well, I can't get that test extension to work.  

I downloaded the test cased I attached and ran it in 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041506 Minefield/3.0pre 
and reproduce the bug.

We need to figure out why you can't run the test. Using the eval approach for this introduces too many uncertainties, esp. considering this is (apparently) a permissions problem.  I would hope that the command line would indeed fail for History since it is supposed to run just like the web page runs. The test replicates my problem in the way it occurs in firebug, in chrome code.

I wish this bug could be set back since its not resolved nor invalid (yet).

Comment 17

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

John: if you're getting a .wrappedJSObject, then you have a SJOW which runs getters with content privileges, and that means that .previous isn't accessible, so permission _should_ be denied.  Is the code in Firebug that triggers this not trying to see the DOM as content code would see it?  That's what I understand from the previous discussions, and it's what your test code is explicitly asking for.

I think you should just catch the security exception when traversing the tree, and show it as "<inaccessible>" in the display.  If you want to see things differently from what content sees, then you should use an XPCNW path to History, in which case you should be able to call the .previous getter with chrome privileges (and without content interference).

Does that make sense?

Comment 18

[John J. Barton]

(In reply to comment #17)
> Does that make sense?

Yes, in this case it makes perfect sense, thanks.

Unfortunately I now need to find the other places I get this problem and create a test case for them. 

Comment 19

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

Yeah, that'd be great.  We've had strange "Location.toString" veto messages in the console for years, which I thought a previous patch of mine would have put some more detail into, but not so much.  I'll see if I can find out where we're reporting the message and get a detail-adding patch spun up quickly.  If nothing else, it might help us figure out how to repro.