418429 - "Node was not found" error in this case, should work just fine

Status: NEW

(Core :: Security: CAPS, defect)

Description

[Martijn Wargers (dead)]

Attachment: zipped up testcase

See zipped up testcase.

To reproduce the issue:
- Exract the zipped up testcase
- Open the file named 'parent.htm'

Actual results:
After clicking on "Allow" for the "enhanced abilities", I still see the iframe and I see this error in the error console:
Error: uncaught exception: [Exception... "Node was not found"  code: "8" nsresult: "0x80530008 (NS_ERROR_DOM_NOT_FOUND_ERR)"  location: "file:///C:/Documents%20and%20Settings/mw/Bureaublad/a/iframe.htm Line: 10"]

This regressed when the fix for bug 230606 went in.

Comment 1

[Martijn Wargers (dead)]

Fwiw, because of this, I had to set security.fileuri.origin_policy to 3, otherwise I couldn't get things to work in my testing.

Comment 2

[Daniel Veditz [:dveditz]]

If you rework this testcase so that the frame is cross-origin http you get exactly the same error, when you would expect granting all those privileges ought to get you somewhere. Bug 230606 changed file:// to work as-if it were separate origins, exposing this bug. Prior to bug 230606 file was all one origin so you shouldn't have needed to enablePrivilege to delete the iframe.

Without having looked yet my money's on XOW not doing caps checks. We might even be skipping the checks on purpose for perf reasons -- and given the limited use of this kind of thing I wouldn't blame them.

Personally I'm all in favor of killing UniversalXPConnect. The idea of caps was that there were limited permissions (browserRead, browserWrite, etc) you could safely grant short of giving away the store. Given the types of exploits we've had with even "limited" permissions it's not at all "safe" and the permission dialogs confuse the hell out of users. There is no way they can answer those sanely and safely.

And as for UniversalXPConnect in particular, install an addon. If you can't convince a user to install something to run your intranet app or whatever turns out to need these privileges then they shouldn't be granting UXPC privileges either.

I bet we'd save a bunch of perf overhead if we eliminated these caps checks.

Comment 3

[Daniel Veditz [:dveditz]]

Attachment: inner frame for test

Comment 4

[Daniel Veditz [:dveditz]]

Attachment: testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

Note bug 396851.

Comment 6

[Daniel Veditz [:dveditz]]

To run the testcase you must first set the pref signed.applets.codebase_principal_support to true.

If you load the testcase attachment from standard BMO it is same-origin with its frame and it will be deleted whether or not you grant the permission request (expected). If you don't set the pref you won't see the grant dialog.

If you load the testcase from test1.bugzilla.mozilla.org as in the URL field above then the inner frame is from a different origin. If you deny the privilege request you'll get the usual
  Error: Permission denied to get property HTMLIFrameElement.parentNode

If you grant the privilege you get the "Node was not found" exception described in this bug.

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

Can we close this now that bug 396851 is fixed?

Comment 8

[Martijn Wargers (dead)]

Now with the testcase on this bug, the iframe doesn't disappear on reload (no js errors in the console).
On shutdown, the firefox.exe seems to lock up, using all cpu.

Comment 9

[Michelle Funches - QA]

This bug has been tagged for regression and or closure.
Review of files and comments, it appears this can be closed.
Test info from C#3 C#4 are stable.
Is there is a reason for this to remain open