-
Notifications
You must be signed in to change notification settings - Fork 476
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chrome: Support custom locales and resources paths #3749
Comments
Are you using a fully qualified path for |
Yes, i use a fully qualified absolute path. |
Using spotify releases I'm pinpointing this as:
69ce47a..44f7b57 are just 4 commits, and it is probably when --disable-chrome-runtime was added (hence making chrome runtime default), because 125.0.14 does not crash if --disable-chrome-runtime is passed. Maybe adding similarily into ChromeMainDelegateCef::PreSandboxStartup a call to InitializeResourceBundle with a similar implementation will fix this. I suppose the DIR_RESOURCES is similarily affected. Passing --enable-chrome-runtime to 125.0.11 crashes as well. So either this should be patched in Chrome (not recommended), or pair the paths override also in ChromeMainDelegateCef. |
We are setting the override here for Chrome. |
Looks like our ordering is wrong here. The DIR_LOCALES values is queried via the call to
|
The chrome::DIR_RESOURCES and ui::DIR_LOCALES overrides need to be configured before calling ChromeMainDelegate::PreSandboxStartup.
The chrome::DIR_RESOURCES and ui::DIR_LOCALES overrides need to be configured before calling ChromeMainDelegate::PreSandboxStartup.
The patch doesn't fix problems on linux, another crash with callstack like this:
|
It looks like Chrome is using The location of |
One complication with overriding We likely want to keep the current binary loading behavior unchanged on Linux. |
@JCYang Please explain your use case for customizing the resources-dir-path. Given the complexity described above I'm inclined to just remove this configuration option and require resources to be placed next to the libcef module on Linux and Windows, and in the appropriate app bundle framework location on MacOS. |
We have a fairly straightforward use-case: We ship both 32-bit and 64-bit CEF binaries in the same application (on Windows), and since the chromium resources are the same for both, we use Also just for completion sake, while |
We ship both 32-bit and 64-bit CEF binaries in the same application (on Windows), and since the chromium resources are the same for both
Interesting. The *.bin files (icu, v8, etc) are not the same for both architectures. Where do you put those?
Note that *.pak files being the same would be considered a happy coincidence and probably not by design.
|
Everything but *.pak files are next to libcef as normal; we're just moving resources and locales. We know that it's maybe not deliberate they're shared between arches, but we haven't had an issue with it yet, and we've been doing it since like CEF 86, so. |
Just to express interest in this issue: we have an application with 1000s of dlls and other files including 3rd party libraries. Every little bit helps to keep the application folder tidy, and avoid possible clashes and confusion. |
before M128, if you set chrome_runtime = true, then _cef_settings_t.resources_dir_path doesn't work at all. |
Describe the bug
The cefclient sample application crashes unexpectedly when launched using a custom locales path.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The cefclient sample application is started.
Versions (please complete the following information):
The text was updated successfully, but these errors were encountered: