481311 - nsIResProtocolHandler.idl shouldn't #include nsAString.h

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Mook (songbird dead account)]

Attachment: 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.)

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

does it have to include this at all?

Comment 2

[Benjamin Smedberg]

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"

Comment 3

[Mook (songbird dead account)]

Attachment: 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 :)

Comment 4

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/7db7d5ab702a