nsFilePicker directly calls IC to do file mappings. Instead, it should be using our IC service.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
One problem with the IC Service is that it's in appshell which should not be needed in an embedding context. Since nsLocalFileMac already uses IC Service, we're deeply dependent on it so this change isn't going to make matters worse. It would be nice to find a better home for IC Service and we could rid embedding of another component which goes mostly unused.
Sounds like the IC service needs to move to embedcomponents, or somesuch.
needing r/sr. cc'ing dagley since he's familiar w/ the code.
+ mFlatFilters.AppendCString ( nsCString((char*)&typeTemp) ); That's constructing another whole nsCString which allocates storage. You could do better with nsDependentCString Other than that, looks good. r=ccarlen This is beside the point of this patch, but I raised the point before: Isn't there a better place for the IC service to live than in appshell? I really want to avoid needing that component for embedding. EmbedComponents is getting a little crowded. If we had an OSServices component, we could put IC in it. Anything else fit in that category? If so, let's make a new bug and do it.
conrad & i talked about this, mFlatFilters is an array, not a string, so creating a new string here is appropriate. bug 102920 filed on conrad's components question: http://bugzilla.mozilla.org/show_bug.cgi?id=102920
I'd like to see some evidence of testing. IC can return empty mime types, and probably empty type/creators sometimes.
For unmapped extensions (.shtml is an example), the ICService returns a null mime info, which we check for. We have the extension in our list (which we use if there is no matching file type), but we're not putting garbage into our macos type list. Finally, i stepped through it to make sure the string foo is correct (don't walk off the end of things, etc). anything else i should test?
I'm convinced. sr=sfraser
Target Milestone: mozilla0.9.5 → mozilla0.9.6
landed on trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.