Closed
Bug 386376
Opened 17 years ago
Closed 17 years ago
Impossible to implement a content sniffer in JS due to recursive GetService calls (nsIContentSniffer, JavaScript)
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
RESOLVED
FIXED
People
(Reporter: bent.mozilla, Assigned: Biesinger)
References
Details
(Keywords: verified1.8.1.13)
Attachments
(2 files)
2.93 KB,
patch
|
benjamin
:
review+
dveditz
:
approval1.8.1.13+
|
Details | Diff | Splinter Review |
2.53 KB,
text/plain
|
Details |
The IOService loads all content sniffers registered in the category manager the first time it is loaded. If a content sniffer is implemented in JS then initializing it requires the ScriptSecurityManager to load. That, in turn, requires the IOService. This recursion is not allowed and so the content sniffer fails to load properly. Not sure what to do about this. I had to reimplement my component in C++ :(
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → cbiesinger
Assignee | ||
Updated•17 years ago
|
Summary: Impossible to implement a content sniffer in JS due to recursive GetService calls → Impossible to implement a content sniffer in JS due to recursive GetService calls (nsIContentSniffer, JavaScript)
Assignee | ||
Comment 2•17 years ago
|
||
this should fix it, and it doesn't break the content sniffer unit test, but I haven't tested yet whether it fixes the actual bug here.
Assignee | ||
Comment 3•17 years ago
|
||
copy to components/; starting the second app startup you'll see a security manager init assertion and no "called" dumps
Assignee | ||
Comment 4•17 years ago
|
||
Comment on attachment 272406 [details] [diff] [review] patch ok, I tested the patch and it works
Attachment #272406 -
Flags: review?(benjamin)
Assignee | ||
Updated•17 years ago
|
Status: NEW → ASSIGNED
Updated•17 years ago
|
Attachment #272406 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 5•17 years ago
|
||
Checking in netwerk/base/src/nsIOService.h; /cvsroot/mozilla/netwerk/base/src/nsIOService.h,v <-- nsIOService.h new revision: 1.64; previous revision: 1.63 done Checking in xpcom/glue/nsCategoryCache.h; /cvsroot/mozilla/xpcom/glue/nsCategoryCache.h,v <-- nsCategoryCache.h new revision: 1.2; previous revision: 1.1 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 7•16 years ago
|
||
Comment on attachment 272406 [details] [diff] [review] patch This is a really safe fix, and this bug is causing branch extension developers a good bit of grief. Ben and I both think this should be safe to take on branch, and I'd ask us to think about doing just that...
Attachment #272406 -
Flags: approval1.8.1.13?
Comment 8•16 years ago
|
||
Comment on attachment 272406 [details] [diff] [review] patch approved for 1.8.1.13, a=dveditz for release-drivers
Attachment #272406 -
Flags: approval1.8.1.13? → approval1.8.1.13+
Comment 10•16 years ago
|
||
(In reply to comment #6) > Would be good to find a way to test this... > Did anyone find a way to test this? This is hard to verify otherwise.
Comment 11•16 years ago
|
||
For what it's worth, the extension developer who was having issues due to this has confirmed that his problem is fixed on branch. Is that good enough to verify?
Comment 12•16 years ago
|
||
Yes, that's good enough for us. Marking it...
Keywords: fixed1.8.1.13 → verified1.8.1.13
You need to log in
before you can comment on or make changes to this bug.
Description
•