> moreover it means that we'd want two different behaviors when receiving SIGINT (whether it's a genuine unix signal or one sent by the server if we follow the tests result above) perhaps, the solution would be in the default_ctrl_handler to only terminate the program if attached to a console, or in the program group of a unix console
One way or another, terminating GUI process in response to Unix SIGINT is a Wine thing, it's not something we can express in Windows terms. If kernelbase part is not suitable, maybe we may just terminate process from ntdll when we're not connected to console. We know that in this case the signal originated from the host.
> remark: Wine unix console is the sole case where launching a GUI program from command line doesn't return immediately to prompt (native & builtin cmd implementation only wait on CUI programs completion). But that's conform to unix behavior.
I'm not sure what exactly you mean by conforming to unix behavior, but it's arguably a bug that will cause problems similar to !3145, under different conditions. I'd rather avoid depending on this behavior in the solution for SIGINT if possible.
> note: I'm not even sure tweeking with setsid whould be useful as anyway the unix console is in raw mode, so only conhost regenerates the signals
It's in raw mode only if a console application reads input. In this case, taking more control by conhost seems justified.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3312#note_40761
This get us pass the "Update your browser" blocker in adobe's sign-in page. The page itself doesn't make use of `window.MutationObserver`.
However the sign-in page is still broken.
--
v24: mshtml: add stubs for MutationObserver methods
mshtml: implement window.MutationObserver with MutationObserver stub
https://gitlab.winehq.org/wine/wine/-/merge_requests/3391