Skip to content

Conversation

juj
Copy link
Collaborator

@juj juj commented Sep 29, 2025

This PR adds downloadable firefox packages into emsdk.

The downloading of firefox will be done via the mozdownload pip package, which simplifies the installation a lot.

Installing and activating a Firefox package will set up the EMTEST_BROWSER variable, so running browser tests will then automatically use the activated browser.

The oldest supported Firefox version by Emscripten is 65. So add that version, and all ESR versions from 65 upwards, and the moving channels. This allows people to go back and forth testing different versions of interest.

"version": "78.15.0esr",
"bitness": 64,
"url": "downloaded via mozdownload script, but a dummy directive is placed here so emsdk understands this Tool to be downloaded from the web",
"activated_cfg": "EMTEST_BROWSER=%installation_dir%/firefox%.exe%",
Copy link
Collaborator

Choose a reason for hiding this comment

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

EMTEST_BROWSER is not a config file setting so I would hope this would not be needed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Unfortunately that is the only way currently to distinguish whether the tool is set to be active or not.

Without this directive, there is no record of whether user has set, say, emsdk activate firefox-78.15.0esr or emsdk activate firefox-latest-esr-64bit.

I'll rename this cfg directive to EMSDK_ACTIVATED_TEST_BROWSER to help distinguish that is not actually used to set up EMTEST_BROWSER.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Without this directive, there is no record of whether user has set, say, emsdk activate firefox-78.15.0esr or emsdk activate firefox-latest-esr-64bit.

It is important to track that? What purpose does it serve?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Otherwise if you run emsdk_env, it will activate all Firefoxes, so the very last one in emsdk_manifest.json will win.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess mean all the ff versions you have installed?

Its a shame we don't have any other way to track activated status, other than writing to the config file

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I guess mean all the ff versions you have installed?

Err yeah, that's the case.

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

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

This seems to add a lot of extra complexity, but I'm not sure I see the benefit outside of your specific internal CI setup.

Can we at least try to reduce the extra lines of code somehow? For example do we really need all those FF versions?

"activated_env": "EMTEST_BROWSER=%installation_dir%/firefox%.exe%",
"mac_activated_cfg": "EMTEST_BROWSER=%installation_dir%/Contents/MacOS/firefox%.exe%",
"mac_activated_cfg": "EMSDK_ACTIVATED_TEST_BROWSER=%installation_dir%/Contents/MacOS/firefox%.exe%",
"mac_activated_env": "EMTEST_BROWSER=%installation_dir%/Contents/MacOS/firefox%.exe%",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we modify the extraction process to strip the Contents/MacOS prefix, and avoid adding this new mac_activated_cfg and mac_activated_env concepts?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

There are files in the other directories, e.g. Contents/Resources/. I could maybe remove the Contents/ part, but that would be very non-Apple'esque, and any Apple native devs reading the code would likely read it to be a silly hack.

@juj
Copy link
Collaborator Author

juj commented Oct 1, 2025

I'm not sure I see the benefit outside of your specific internal CI setup.

Users can

emsdk install firefox-x-64bit
emsdk activate firefox-x-64bit
test/runner browser.test_x

to test in any Firefox?

do we really need all those FF versions?

Yes, otherwise we blind our eyes from bugs, and saying we would support codegen down to Firefox 65 would be lip service.

@sbc100
Copy link
Collaborator

sbc100 commented Oct 1, 2025

I'm not sure I see the benefit outside of your specific internal CI setup.

Users can

emsdk install firefox-x-64bit
emsdk activate firefox-x-64bit
test/runner browser.test_x

to test in any Firefox?

do we really need all those FF versions?

Yes, otherwise we blind our eyes from bugs, and saying we would support codegen down to Firefox 65 would be lip service.

I'm not saying that testing old versions of FF is not good, I'm just not sure if emsdk is needs to be the way firefox gets installed. Up until now we have not installed browser, or stuff needed for testing only as part of emsdk.

Would it possible perhaps to write a script that downloads FF, without complicating emsdk?

@juj
Copy link
Collaborator Author

juj commented Oct 1, 2025

I'm just not sure if emsdk is needs to be the way firefox gets installed.

This way I can spin up Emscripten testing the same way in Node, vs in Firefox.

Would it possible perhaps to write a script that downloads FF, without complicating emsdk?

Yes, but then I will have to go through hoops to install some other git repository in tandem with installing emsdk, which would be a massive hassle. With this I can install Firefox at the same line where I install rest of Emscripten tools. It can be of big value in user bug reports as well.

@juj
Copy link
Collaborator Author

juj commented Oct 7, 2025

Ping, further thoughts here?

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

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

lgtm since I don't want to keep blocking your progress.

But I do have some concerns:

I'm generally against adding a more untested code to emsdk (I do get it is being testing on your end but that doesn't stop future changes breaking it)

I don't love adding this many new entries to the manifest... maybe there is some way to templatize so we don't need to repeat ourselves so much? I get that its just a bunch of json, but I also find myself paging through it fairly often by hand and lots of mostly-unused (i.e. used only on your CI bots) entries are somewhat annoying here.

I would love to:

  1. Find a way to avoid the new mac_activated_env and mac_activated_cfg which duplicate the non-man versions. Could magically also look in Contents/MacOS without needing the include this in the json?
  2. Find some way to avoid the duplication in the many new json entries?
  3. Find a way another way to signal activation other than presence in the config file? We have a lot of tools now that don't ever want to be the .emscripten config file since emscripten itself doesn't use them. Perhaps a separately activated.json file that gets written separately to the config file?

Perhaps a secondary firefox_manifest.json, perhaps even allowing your to maintain that externally?

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

Successfully merging this pull request may close these issues.

2 participants