fix: potential crash caused by dlopen different gtk libraries

[deepak1556]

Description of Change

#19159 refactored file dialog implementation that relies requiring gtk library at runtime, around the same time chromium has been refactoring itself to also require gtk at runtime https://bugs.chromium.org/p/chromium/issues/detail?id=1192861

Since chromium already loads the required gtk library into the process on startup, the file dialog implementation should just get a handle to the loaded library and perform operations on it, the current implementation can lead to situations in classic snaps where two different version gtk libraries can get loaded into the same process triggering a crash, refs microsoft/vscode#146584 (comment)

NB: There is no functionality change in this PR, simplifies library loading following upstream changes and fixes potential crash alongside.

/cc @tristan957

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: fix crash when opening gtk file dialogs due to mismatched versions

[tristan957]

Hi @deepak1556. Thanks for tracking down the source of the issue. With your PR, I am a little confused how any of the gtk_file_chooser_native_* methods work because it is possible that those symbols don't exist.

Where is the definition of electron::IsElectron_gtkInitialized()?

[deepak1556]

electron_gtk_stubs.cc is responsible for loading the symbols and providing utilities to check if the required symbols are loaded, this file is generated during compile time. An example can be seen with upstream's stub file that gets generated for https://source.chromium.org/chromium/chromium/src/+/main:ui/gtk/gtk.sig, if the symbol is not present it will just call the utility function (example) is provided as part of logging_function in the Build.gn file. In our case, we provide a noop logger which allows for symbol load failures.

[tristan957]

Ok cool. Thanks for the background. This PR sounds like a good solution then. I wonder if Flatpak has the same issue.

[deepak1556]

Not familiar with flaptak, but if it does not search for libraries from the host then worst case would be it fails to load the required gtk version with the symbols and end up calling the legacy dialog fallback. I think only classical snaps can run into this crash edge case.

[tristan957]

I am not at all familiar with the confinement of snap vs classical snap vs flatpak. As you said, I guess classical snap is the outlier here and it is really weird to have to program around this packaging format when seemingly it would work for snap and flatpak.

[nornagon]

should this be upstreamed?

[deepak1556]

I can give it an attempt.

[release-clerk]

Release Notes Persisted

fix crash when opening gtk file dialogs due to mismatched versions

[trop]

I was unable to backport this PR to "16-x-y" cleanly;
you will need to perform this backport manually.

[trop]

I was unable to backport this PR to "17-x-y" cleanly;
you will need to perform this backport manually.

[trop]

I have automatically backported this PR to "19-x-y", please check out #33813

[trop]

@miniak has manually backported this PR to "17-x-y", please check out #34774