8fb8f7f827
gjs now has an internal mainloop that it can spin to resolve module imports. That loop uses the thread default context, so its possible that other sources, namely from mutter, get dispatched when iterating the context. If that happens before mutter is properly initialized, this will lead to a crash. GjsContext needs to iterate its internal mainloop when initializing to resolve internal modules, to avoid iterating Meta's mainloop and triggering events before Meta is ready we will initialize the Shell global and thus the GjsContext (js_context) before Meta. Once GjsContext is initialized, we can call meta_context_setup(). Once Meta is setup and started, we'll run init.js which uses GJS' internal promises API to set a "mainloop hook". The mainloop hook is run immediately after the module returns so GJS will not attempt to iterate the main loop again before exiting. Also adjust the 'headlessStart' test to not wait for the MetaContext::started signal, as that signal has now already been emitted when the code is executed. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6691 Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2781> |
||
|---|---|---|
| .. | ||
| dbusServices | ||
| gdm | ||
| misc | ||
| perf | ||
| portalHelper | ||
| ui | ||
| js-resources.gresource.xml | ||
| meson.build | ||
| portal-resources.gresource.xml | ||