It appears that nsIMIMEHeaderParam is used from JS in m-c only in unit tests. Also, most of the interface is unused in m-c, since m-c only uses the HTTP part. nsMIMEHeaderParamImpl.cpp should be deCOMtaminated and the non-HTTP parts removed from m-c. (A quick look suggests that no processing differs depending on HTTP_FIELD_ENCODING or MIME_FIELD_ENCODING.)

ni Jason to find an owner and set the priority.

Hello Henri, I see the clients in JS of nsIMIMEHeaderParam are devtool[1]/toolkit[2] instead of unit tests. Hence, it's hard to deCOMtaminated with these clients stand. You're correct, lots of API in nsIMIMEHeaderParam.idl should not exposed. However, if we couldn't deCOMtaminated it, it's not very attractive to shrink the list of API. What do you think? [1] https://searchfox.org/mozilla-central/rev/807a37c670c093b6e5201841a7c5315ba67ba8d5/devtools/startup/devtools-startup.js#990 [2] https://searchfox.org/mozilla-central/rev/924e3d96d81a40d2f0eec1db5f74fc6594337128/toolkit/content/contentAreaUtils.js#593

(In reply to Junior Hsu from comment #2) > Hello Henri, > I see the clients in JS of nsIMIMEHeaderParam are devtool[1]/toolkit[2] > instead of unit tests. > Hence, it's hard to deCOMtaminated with these clients stand. > > You're correct, lots of API in nsIMIMEHeaderParam.idl should not exposed. > However, if we couldn't deCOMtaminated it, it's not very attractive to > shrink the list of API. > > What do you think? Good point. I missed the devtools callers. Yeah, deCOMtamination doesn't work then. Still, it would make sense to check how much browser-irrelevant email-related dead-in-Firefox code there is.

I did some archeology. We split the parser for MIME(TB and dev tool) and http header in bug 601933. However, it breaks lots of sites in the field though it satisfies the spec. We disable the effect in bug 858337, which meets the Comment 0. Hence, splitting two functions with same functionality help it easy to revert. A stale result [1] shows still considerable breakage. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=66694#c27 We might figure we can fix bug 601933 one day. Let's rather leave the code unchanged.