the res protocol handler was IMO poorly designed. it attempts to provide for the possibility of multiple resource resolutions (or substitutions) and as a result creates a very inefficient system. i believe that this design is completely overkill for a web browser. the res protocol handler should have only one substitution per key. if that fails, it should be the callers responsibility to try a different key. i should add that no one is currently using this "feature." asserting that a resolution succeeds is very costly. for example, the res protocol handler has to verify access to the resolved file before accepting the resolution. this has a very negative effect on startup performance. my patch for bug 97528 eliminates this check (b/c we only register one substitution per key anyways). and so, i believe that we should eliminate this "feature." the result will be a much simpler and faster res protocol handler.

this patch does a bunch of things: 1- cleans up nsIResProtocolHandler, removing extraneous unused API 2- cleans up nsResProtocolHandler 3- removed unused nsIResChannel (still need to remove references to nsIResChannel in the rest of mozilla) 4- cleans up res protocol handler entry in nsNetModule.cpp 5- other miscellaneous cleanup

in addition the mac project file will be modified to remove nsIResChannel.idl

Comment on attachment 49834 [details] [diff] [review] v1.1 removed reference to nsIResChannel in nsChromeProtocolHandler Looks good. The nsIURI's that are in mSubstitutions does not be need to QI'ed since you are the only one putting anything in to that array. Just static_cast.

good point... i'll attach a new patch.

Comment on attachment 49874 [details] [diff] [review] v1.1 revised per comments from dougt has r=dougt from previous comments

Comment on attachment 49874 [details] [diff] [review] v1.1 revised per comments from dougt sr=mscott

fixed-on-trunk