-
Notifications
You must be signed in to change notification settings - Fork 16k
Remove or fix the "Running without renderer sandbox" error message #22
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
Comments
It's showed because the renderer sandbox is disabled, otherwise many node functions won't work. It is in fact not a error message, but a kind warning. Removing it only needs a one line patch for chromium. But I want to keep this message so I can know whether and when the renderer has started, it's helpful for debugging. How about replacing it with a warmer message? like:
|
If it is helpful to you let's just keep it! |
The ninja generator of gyp behaves strangely on the 'libraries' field of link settings, for example, specifying path to an external library works well on both xcodebuild and msvc generators, but the ninja generator would link to the wrong path (it can neither translate relative path correctly, nor convert the command line parameter to the '-lxxx' form). The only way to make all generators work on all platforms is to use abusolute paths for external libraries.
* vendor/libchromiumcontent ee4cea0...33472d4 (5): > Export ICU headers > When `gclient sync` fails, revert all local changes and try again > Merge pull request #23 from brightray/chromiumviews_pdb > Merge pull request #22 from brightray/cygwin2 > Update to Chrome 28.0.1500.71
The ninja generator of gyp behaves strangely on the 'libraries' field of link settings, for example, specifying path to an external library works well on both xcodebuild and msvc generators, but the ninja generator would link to the wrong path (it can neither translate relative path correctly, nor convert the command line parameter to the '-lxxx' form). The only way to make all generators work on all platforms is to use abusolute paths for external libraries.
* vendor/libchromiumcontent ee4cea0...33472d4 (5): > Export ICU headers > When `gclient sync` fails, revert all local changes and try again > Merge pull request #23 from brightray/chromiumviews_pdb > Merge pull request #22 from brightray/cygwin2 > Update to Chrome 28.0.1500.71
…pec/main/multi-bd7f08ee8b build(deps-dev): bump mocha and @types/mocha in /spec
Do you know why this error always is logged?
This has been logged since we started using CEF1 a long time ago. It is not a huge problem, and I don't think we should spend a huge amount of time on it, but it has always annoyed me.
The text was updated successfully, but these errors were encountered: