Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behavior in browser extensions #38

Open
AlexITC opened this issue Dec 15, 2021 · 4 comments
Open

Behavior in browser extensions #38

AlexITC opened this issue Dec 15, 2021 · 4 comments

Comments

@AlexITC
Copy link

AlexITC commented Dec 15, 2021

I maintain a plugin and a template to create browser extensions with Scala.js.

I'm interested to push the macrotask-executor to these repos but I still don't understand the differences.

For example, in a browser extension, there are different contexts (like different applications composing the browser extension), some of them being:

  • A background context, which is usually always live, which has some similarities to a service worker.
  • Several UI contexts, which can be in the web pages where the extensions are injected, or, the UI you see when clicking the launching an extension by clicking its toolbar icon.

The UI contexts behave just like any normal web page, hence, the macrotask-executor should be useful, on the other hand, I wonder if the macrotask executor is useful for the background context.

Thanks.

@AlexITC AlexITC changed the title Check the behavior in browser extension Behavior in browser extensions Dec 15, 2021
@armanbilge
Copy link
Member

Thanks for raising this issue! Firstly, the MacrotaskExecutor should work in any JS runtime. If not, that's a bug :)

So the question at hand is what is the performance of MacrotaskExecutor when used in a browser extension. This depends on what APIs are available: so long as one of setImmediate, postMessage, or MessageChannel (for webworkers) are available, it should have optimal performance. If none of these are available, it falls back to setTimeout which is always available but much less performant.

From your description it sounds like the UI contexts provide APIs available in webpages and the background contexts provide APIs usually available in webworkers. The MacrotaskExecutor is already known to work well in those environments.

Lastly, do you have an easy way of testing browser extensions in CI? It would be a good addition to our test matrix and confirm everything is working as expected. We currently run tests in Node.js, JSDOM, and Chrome/Firefox webpages and webworkers.

@AlexITC
Copy link
Author

AlexITC commented Dec 15, 2021

Thanks for raising this issue! Firstly, the MacrotaskExecutor should work in any JS runtime. If not, that's a bug :)

Yes, it does.

it falls back to setTimeout which is always available but much less performant.

This is what I don't know, the background context might end up using this approach.

From your description it sounds like the UI contexts provide APIs available in webpages and the background contexts provide APIs usually available in webworkers. The MacrotaskExecutor is already known to work well in those environments.

Correct, the background context has differences from webworkers, I'm yet to investigate details about this.

Lastly, do you have an easy way of testing browser extensions in CI? It would be a good addition to our test matrix and confirm everything is working as expected. We currently run tests in Node.js, JSDOM, and Chrome/Firefox webpages and webworkers.

Yes, it is doable with Selenium, I'm involved in a private extension where we use that.

@armanbilge
Copy link
Member

armanbilge commented Dec 15, 2021

Thanks for the response!

Yes, it is doable with Selenium, I'm involved in a private extension where we use that.

Fantastic, do you think you could make a PR setting this up? That would be the best way to test this, and make sure we don't have any regressions for this environment in the future. Our test suite actually includes a test to verify one of the higher-performance polyfills is used.

assert((end - start).toDouble / MinimumClamp < 0.25) // we should beat the clamping by at least 4x even on slow environments

@AlexITC
Copy link
Author

AlexITC commented Dec 15, 2021

I do remember the test, unfortunately I don't have too much free time right now but I can get someone from my team to add it, don't expected it too soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants