Closed Bug 386656 Opened 13 years ago Closed 13 years ago

Security Error: Content at moz-nullprincipal:{8c0f4edc-0aac-45cc-8471-895f07bb1bb2} may not load or link to resource://gre/res/hiddenWindow.html during install of latest NTT Build

Categories

(Core :: XML, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.9alpha8

People

(Reporter: cbook, Assigned: peterv)

References

Details

(Keywords: regression)

Attachments

(1 file)

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007070209 Minefield/3.0a7pre

Steps to reproduce:

Install latest Trunk Build
Try to Install (v1.3b1) NTT from http://www.oxymoronical.com/web/firefox/nightly
Install of NTT will fail because not compatible to 1.9a7pre / 3.0a7
Check the Error console you will see a  [nsIInterfaceRequestor::getInterface] Error ( Bug 383455 / Bug 374499) and also a Security Error:

Security Error: Content at moz-nullprincipal:{8c0f4edc-0aac-45cc-8471-895f07bb1bb2} may not load or link to resource://gre/res/hiddenWindow.html 

Output also on http://pastebin.mozilla.org/114094

Reproduced on Vista and Linux
Did you also file a bug against software update?

Security Error: Content at moz-nullprincipal:{974a26e1-8dee-4f66-ade4-17837b76584b} may not load or link to chrome://mozapps/content/update/updates.xul.
(In reply to comment #1)
> Did you also file a bug against software update?
> 


Hi Rob,

yep thats now Bug 386656
(In reply to comment #2)
> yep thats now Bug 386656
> 

err sorry for the bugspam meant its now Bug 386719 
Duplicate of this bug: 386719
Component: Extension/Theme Manager → XML
Product: Firefox → Core
QA Contact: extension.manager → xml
Target Milestone: --- → mozilla1.9beta1
Assignee: nobody → peterv
Attached patch v1Splinter Review
Johnny: in this case the XMLHttpRequest is used by an XPCOM component, so nsContentUtils::GetDocumentFromCaller doesn't return a document. I think we should fall back to the caller's principal in that case, does that seem right? (Although it seems a bit odd to use the principal's URI as the referrer in that case :-/).
Attachment #270746 - Flags: superreview?(jst)
Attachment #270746 - Flags: review?(jst)
Ideally, we'd do what DOMParser does and have a way to init an XMLHttpRequest with a given principal...
So do what bug 332840 did for DOMParser, I'm still trying to understand what that patch did:

- added an Init(...) function for C++ callers
- added an init(...) function for JS callers
- modified the JS constructor so it could take arguments

AFAICS, for this particular case, it does what this patch does: use the subject principal if the constructor is called without arguments. If that is the case I'd rather fix this bug with the patch in attachment 270746 [details] [diff] [review] and open a new bug for the more complete fix.
Status: NEW → ASSIGNED
Though DOMParser seems to get its principal at creation while XMLHttpRequest gets it when send() is called.
Oh, yeah.  My comment was for a followup; I think your patch is fine for now.

And we might want to get principals on creation; we should check the XMLHttpRequest spec, which actually specifies this stuff...
Comment on attachment 270746 [details] [diff] [review]
v1

Looks good.
Attachment #270746 - Flags: superreview?(jst)
Attachment #270746 - Flags: superreview+
Attachment #270746 - Flags: review?(jst)
Attachment #270746 - Flags: review+
Follow-up bug is bug 386823.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Verified fixed with latest trunk Nightly. No more a Security Error when i check for updates. 
Status: RESOLVED → VERIFIED
Guys -

I'm seeing a security error now when trying to use an XHR to retrieve 'file:///' based content. I'm seeing this now in FF 3.0 beta 1, but I've tracked it down to appearing between Gran Paradiso A7 and Gran Paradiso A8. I'm not sure if this is the correct bug to file this report with, but it seemed the closest to what might have changed between those two releases to cause this.

Note that this is an .html file launched off of the file system which is using an XHR to load more 'file:///' content. I'd be happy to attach a testcase if necessary, but I wanted to be sure that I'm in the right bug first, or if I need to file a new bug report.

Note that this breakage is *really bad* for my product, so I'd appreciate any help anyone can give. I'm even offering beer to the fixer :-).

Cheers,

- Bill
William: that sounds like the result of bug 230606. There's more information in that bug, and that would be a better place to put your comment.
You need to log in before you can comment on or make changes to this bug.