Skip to content

Loading…

Move ` µBlock.transposeType()` to Chromium's platform-specific code #536

Closed
gorhill opened this Issue · 6 comments

2 participants

@gorhill

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, stylesheet or other should not be applied to other platform not suffering the bug.

@gorhill gorhill changed the title from Move ` µBlock.transposeType` to Chromium's platform-specific code to Move ` µBlock.transposeType()` to Chromium's platform-specific code
@Deathamns

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.

@gorhill

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.

@gorhill gorhill added the fixing label
@gorhill

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.

@Deathamns

How is this related to this issue?

@gorhill

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.

@Deathamns

Aha. In that case, it actually has an asciiHost attribute too.

@gorhill gorhill added a commit that closed this issue
@gorhill gorhill this fixes #536 255c68b
@gorhill gorhill closed this in 255c68b
@gorhill gorhill removed the fixing label
@seanrand seanrand pushed a commit that referenced this issue
@gorhill gorhill this fixes #536 b190f0b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.