Created attachment 365329 [details] [diff] [review] use nsStringGlue.h See summary; the use of nsAString.h makes it impossible to use from outside of libxul. Simply switching to nsStringGlue.h makes it usable. (Yes, it's not frozen. It's also the only way to add something that doesn't refer to things chrome.manifest can handle - e.g. paths not known ahead of time.)
Attachment #365329 - Flags: review?(benjamin)
does it have to include this at all?
Comment on attachment 365329 [details] [diff] [review] use nsStringGlue.h Just remove the include altogether, it's superfluous. Note that this is not the only way to set a resource:// mapping. You can do so by creating a directory service key for "resource:mappingname"
Created attachment 365443 [details] [diff] [review] remove it Okay, this removes it; I was originally thinking something else might have relied on that #include for the string definitions. It looks like the only things that use this file from C++ are /netwerk/protocol/res/src/nsResProtocolHandler.cpp which has it from nsResProtocolHandler.h -> nsInterfaceHashtable.h -> nsHashKeys.h -> nsStringGlue.h /netwerk/test/TestRes.cpp which isn't listed in its Makefile (and can't possibly work anyway, it wants nsIEventQueueService.h) /chrome/src/nsChromeRegistry.cpp which manually #includes nsString.h Thanks for the fast review, by the way :)
OS: Windows Vista → All
Hardware: x86 → All
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Summary: nsIResProtocolHandler.idl #includes nsAString.h instead of nsStringGlue.h → nsIResProtocolHandler.idl shouldn't #include nsAString.h
Target Milestone: --- → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.