Remove HEADLESS option

[RReverser]

Closes #20554.

[sbc100]

Looks like the codesize issues were fixed in #24538

[kripken]

Perhaps we can add a headless flag to emrun, as suggested here?

#20554 (comment)

[RReverser]

Perhaps we can add a headless flag to emrun, as suggested here?

I thought about that, but the problem is that browser automation is actually not trivial - it requires special "drivers" to communicate with their API in headless mode, and integration is different for each browser.

That's why projects like Playwright and Puppeteer exist, but what would we do in this case? Install it for the user as part of emsdk and maintain their versions? It seems easier to point users to said projects for the migration so they can choose the right one for their usecase (eg do they want one-off execution, do they want automated testing, are they limited by Node.js instead of real browser etc).

[RReverser]

It's also not very clear what exactly should emrun do in headless mode. Intercept console that we normally display in the HTML? Produce a screenshot of the final result after some delay?

There's too many options and it would require careful design.

[kripken]

Oh, I was hoping chrome --headless would just work - does it not? I thought that might do what our HEADLESS used to: run the page normally as much as possible, without opening a visual window (so it can run in CI that has no window manager, for example).

[RReverser]

Oh, I was hoping chrome --headless would just work - does it not?

It starts a process in background, but then you need to connect to it over a special remote port and communicate commands via a driver.

From the console you can take a screenshot or dump DOM. https://developer.chrome.com/docs/chromium/headless

However, even that is browser-specific - AFAIK emrun is not tied to just Chrome at the moment?

[kripken]

It starts a process in background, but then you need to connect to it over a special remote port and communicate commands via a driver.

HEADLESS mode was used in cases without a driver. Imagine a web page that just needs to run for a bit, then it exits. This is useful for tests, where the exit code indicates success (and also benchmarks).

emrun does handle exit codes from pages, so basically my hope was that emrun --headless test.html could run a page like emrun does right now, but tells the browser not to open a window, useful for testing on terminal-only CI.

However, even that is browser-specific - AFAIK emrun is not tied to just Chrome at the moment?

Hmm, Firefox has -headless as well, but I haven't tested.

In general all I was thinking about was an emrun flag that passes --headless to chrome (or I guess -headless to firefox), with no other changes.

But, I see there is

emrun --browser-args

So perhaps the readme can just mention for emrun, you can use emrun --browser-args=--headless in chrome, for example - ?

[sbc100]

It starts a process in background, but then you need to connect to it over a special remote port and communicate commands via a driver.

HEADLESS mode was used in cases without a driver. Imagine a web page that just needs to run for a bit, then it exits. This is useful for tests, where the exit code indicates success (and also benchmarks).

emrun does handle exit codes from pages, so basically my hope was that emrun --headless test.html could run a page like emrun does right now, but tells the browser not to open a window, useful for testing on terminal-only CI.

However, even that is browser-specific - AFAIK emrun is not tied to just Chrome at the moment?

Hmm, Firefox has -headless as well, but I haven't tested.

In general all I was thinking about was an emrun flag that passes --headless to chrome (or I guess -headless to firefox), with no other changes.

But, I see there is

emrun --browser-args

So perhaps the readme can just mention for emrun, you can use emrun --browser-args=--headless in chrome, for example - ?

Yes, that is what I was thinking. If you just want to control browser args you already have options for doing that yourself.

[RReverser]

HEADLESS mode was used in cases without a driver. Imagine a web page that just needs to run for a bit, then it exits. This is useful for tests, where the exit code indicates success (and also benchmarks).

In general all I was thinking about was an emrun flag that passes --headless to chrome (or I guess -headless to firefox), with no other changes.

But this alone doesn't wait for the app "exit" nor returns exit code on failures. It only loads page in background and that's it.

[sbc100]

HEADLESS mode was used in cases without a driver. Imagine a web page that just needs to run for a bit, then it exits. This is useful for tests, where the exit code indicates success (and also benchmarks).

In general all I was thinking about was an emrun flag that passes --headless to chrome (or I guess -headless to firefox), with no other changes.

But this alone doesn't wait for the app "exit" nor returns exit code on failures. It only loads page in background and that's it.

emrun itself has its own existing mechanisms for tracking the lifetime of the program and the browser process.

[RReverser]

Ah hmm maybe I didn't look deeply enough into what emrun does.

So perhaps the readme can just mention for emrun, you can use emrun --browser-args=--headless in chrome, for example - ?

So this is sufficient and works as expected?

[kripken]

Yes, if emrun works on a page already, than that flag should make it run in a headless environment I think (though I didn't test in one, but I see no window is shown on my laptop).

Another thought, maybe add --browser=chrome to the example, to clarify the flag is chrome-specific.

[RReverser]

Ok yeah then it's easier than I thought as most work is already done.

So perhaps the readme can just mention for emrun, you can use emrun --browser-args=--headless in chrome, for example - ?

What did you mean by readme though - I assume not literally putting this into emscripten repo README? Just changelog or is there a relevant docs page we should add this to?

[kripken]

Sorry, I meant changelog and not readme. Like this: