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

extension: Don't build vanilla WASM module for web extensions #19316

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

danielhjacobs
Copy link
Contributor

@danielhjacobs danielhjacobs commented Jan 24, 2025

This won't support Safari 16.3- with the Safari extension, but the Safari extension doesn't work anyway, and by the time someone fixes that we can probably just drop Safari extension support for older Safari versions.

The selfhosted and npm packages are now being built as part of the "Build web demo" job. The "Build web demo" job still uses dual-wasm. It is now renamed the "Build web demo and selfhosted" job, and the "Build web" job is now the "Build web extensions" job (though it does also do things like cloning the JS docs still).

@danielhjacobs danielhjacobs added A-web Area: Web & Extensions extension Related to the Ruffle WebExtension T-refactor Type: Refactor / Cleanup labels Jan 24, 2025
@danielhjacobs
Copy link
Contributor Author

danielhjacobs commented Jan 24, 2025

Note: I can't really test this properly, as I cannot "Release Nightly". I did test that npm run build:repro now creates the expected version of Ruffle that fails on Pale Moon, while npm run build:dual-wasm-repro works on Pale Moon.

@danielhjacobs
Copy link
Contributor Author

danielhjacobs commented Jan 24, 2025

Note: May increase minimum Chrome and Edge versions for the extension to version 96, released over 3 years ago: https://v8.dev/blog/v8-release-96

@torokati44
Copy link
Member

This won't support Safari 16.3- with the Safari extension, but the Safari extension doesn't work anyway,

Does #19348 affect this then? 🤔

@danielhjacobs
Copy link
Contributor Author

danielhjacobs commented Jan 28, 2025

Does #19348 affect this then? 🤔

Someone will need to test the Safari extension with that PR. I don't have desktop Safari to test it. But that PR says it fixes the extension on Safari 16+. I don't know if the extension works on Safari 15- right now. With this PR, it will not.

@torokati44
Copy link
Member

Okay but can we assume that 16.0, 16.1, and 16.2 are not in use anywhere anymore, because 16.3 is out? 🤔

@danielhjacobs
Copy link
Contributor Author

16.4*

At my last check, almost 5% of ios users are still using 16.0-16.3 for some reason, but unlike major versions, we can tell people to upgrade if they use those versions. Any device that supports 16.0 supports 16.4 too. People just don't upgrade unless they have to do so it seems.

@danielhjacobs
Copy link
Contributor Author

#18528 (comment)

"Percent iOS 16.0-3"

@danielhjacobs
Copy link
Contributor Author

As of December, the market share is down to exactly 4%.

@thy486
Copy link
Contributor

thy486 commented Jan 29, 2025

//v8.dev/blog/v8-release-96

This might be relevant here.

run: zip -r "${{ needs.create-nightly-release.outputs.package_prefix }}-web-selfhosted.zip" .
working-directory: web/packages/selfhosted/dist

- name: Upload selfhosted
if: ${{ !matrix.demo }}
if: matrix.demo
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the negation removed here? 🤔

Copy link
Contributor Author

@danielhjacobs danielhjacobs Mar 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So selhosted continues working on Safari 16.3-. It's also why the workflow's long name is changed to "Build web demo and selfhosted"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the second paragraph of #19316 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then, since it now means "demo and selfhosted", maybe this flag should be replaced with a different flag with inverse values, for "extensions"? 🤔

Copy link
Member

@torokati44 torokati44 Mar 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh but it should be clear that this flag will govern "whether we're building the browser extensions, or everything else", and not "whether WASM extensions are enabled".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, looking at it again, more closely: Since (almost) all steps of the build-web job in the Release Nightly workflow are gated by the value of matrix.demo, maybe it would make more sense to just split it, getting rid of all the conditionals? 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, a couple of setup steps at the beginning will have to be duplicated this way, but maybe the increased clarity is worth it...?
BTW still waiting for actions/runner#1182 or something similar...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like this: 3299304 (#19767)

@danielhjacobs
Copy link
Contributor Author

For posterity, copying my message from Discord:

Assuming macOS Safari numbers are similar to iOS version numbers listed on https://gs.statcounter.com/os-version-market-share/ios/mobile-tablet/worldwide, this last month (February 2025), 9.5% of Safari users used versions 14.1-16.3. Assuming the Ruffle extension currently works on Safari 14.1-15.8, after #19664 is merged and works, that is how may Safari users that would otherwise be able to use the extension would be unable to use it after [this PR].

Also note that I think I prefer the #19767 version of this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-web Area: Web & Extensions extension Related to the Ruffle WebExtension T-refactor Type: Refactor / Cleanup
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants