
Loading…
Move ` µBlock.transposeType()` to Chromium's platform-specific code #536
Would it be possible to also not limit the types to Chromium's list. Firefox can differentiate many more types, and being able to see the exact type (especially these: OBJECT_SUBREQUEST, FONT, MEDIA, BEACON) instead of other would be better in my opinion.
Of course that would work only in Firefox, Chrome would still show other if the µBlock.transposeType() can't make it better.
Yes, it's possible but this will require careful revision of entry points to be sure that wherever a specific set of types is expected that it redirects the type to other if the type is outside the specific set. For later reference when the issue is fixed, changed needed:
[add more as we identify these places]
Edit: Also, I wished I had normalized to type names which are less specific to Chromium, so maybe an opportunity to do that at the same time, i.e. xmlhttprequest is a mouthful, I prefer xhr, etc.
I notice that with Firefox, the hostname information is readily available: channel.URI.host. So I think it's a good idea to give the responsibility to the platform-specific code to provide the hostname of a request in the details parameter. In the case of Firefox this means reducing a tad the overhead, and for Chromium (and Safari I presume) this means no added/removed overhead.
How is this related to this issue?
I want to take care of this at the same time, working to normalize details.type in platform specific code, I figure I might as well require platform-specific code to add details.hostname while at it.
This code needs to be platform-specific. For examples, some platforms may be able to identify font objects and thus there is no need to try to guess fonts in the platform-independent code. Also, the workaround Chromium bug to transpose
image,stylesheetorothershould not be applied to other platform not suffering the bug.