[chromium-dev] Re: Worker processes are now sandboxed on OS X
It's quite confusing but worker processes [used for Web workers]
utility processes represent 2 different process types.
So:
* Worker processes are enabled and Sandboxed on OS X.
* Utiliity processes are disabled on OS X Linux but the plumbing is now in
place to Sandbox them when they're re-enabled.
Best regards,
Jeremy
On Sat, Nov 7, 2009 at 1:51 AM, Antony Sargent asarg...@chromium.orgwrote:
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/utility_process_host.cc?r1=31090r2=31091pathrev=31091
I notice the following code is still in there:
bool UtilityProcessHost::StartProcess(const FilePath exposed_dir) {
#if defined(OS_POSIX)
// TODO(port): We should not reach here on Linux (crbug.com/22703).
// (crbug.com/23837) covers enabling this on Linux/OS X.
NOTREACHED();
return false;
#endif
If MacOS still defines OS_POSIX, doesn't this mean your changes further
down are not actually running?
Also, by worker process did you mean utility process? (Do we have
something called a worker process for html5 worker threads?)
On Fri, Nov 6, 2009 at 1:21 PM, Jeremy Moskovich jer...@chromium.orgwrote:
r31091 http://src.chromium.org/viewvc/chrome?view=revrevision=31091adds
sandboxing for worker processes on Mac and infrastructure to do the
same for the utility process which is currently disabled on Mac/Linux (
http://crbug.com/23837).
All unit tests currently pass according to the buildbots but if you
experience any issues with worker processes on Mac please try running Chrome
with --no-sandbox . If that solves the issue please file a bug and assign it
to me.
Best regards,
Jeremy
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Recommendations for string data type
Thanks for all the responses. Just ot give some context (as some of you asked) I came across this recently when working on string cleanup in bookmark sync code. The sync protocol uses UTF8 and it interacts with bookmarks which is all wstrings. syncapi.h is the interface on top of sync engine that provides and interface to the code on top (we call it glue) to go back and forth from bookmark model and sync model. So in this case the choice was easy - to use wstrings in syncapi interface since that's what's consumed/produced by callers of the API. My main observation (which surprised me) was that bookmark model uses wstrings, but Scoot cleared to me that it has to be moed to string16 one day. I signed up for doing that next quarter :). Thanks again for nice pointers and providing good insight into this. -Munjal On Fri, Nov 6, 2009 at 4:16 PM, Peter Kasting pkast...@google.com wrote: On Fri, Nov 6, 2009 at 4:08 PM, Jens Alfke s...@google.com wrote: I have been looking at WebCore::StringImpl a lot lately, and I would really like to make it a bit more abstract [i.e. virtual methods] so it could support multiple backing store implementations tuned for different strings. WebKit code has allergies to virtual functions. If you want to do this, you'll need to come armed with perf data that shows that there is absolutely no speed hit. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Preventing keypress after accellerator?
On Fri, Nov 6, 2009 at 6:51 PM, James Su su...@chromium.org wrote: One example: the default behavior of Ctrl+M keypress event is insertNewLine, and it'll always be performed in editor_client_impl.cc if the keypress event is not handled or prevented by the web app. Then the result is we can never use Ctrl+M as an browser accelerator. Is above explanation clear enough? If we're in an editable area, wouldn't we _want_ ctrl-m to insert a new line, and ctrl-b to toggle bold, etc.? The description above sounds desirable rather than problematic. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Preventing keypress after accellerator?
2009/11/8 Peter Kasting pkast...@google.com On Fri, Nov 6, 2009 at 6:51 PM, James Su su...@chromium.org wrote: One example: the default behavior of Ctrl+M keypress event is insertNewLine, and it'll always be performed in editor_client_impl.cc if the keypress event is not handled or prevented by the web app. Then the result is we can never use Ctrl+M as an browser accelerator. Is above explanation clear enough? If we're in an editable area, wouldn't we _want_ ctrl-m to insert a new line, and ctrl-b to toggle bold, etc.? The description above sounds desirable rather than problematic. ctrl-b behaves exactly like what you said, because the toggle bold action is bound to its key down event. If we want ctrl-m to behave like it as well, we can add an entry in keyDownEntries in editor_client_impl.cc to achieve it. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Multiple constrained windows
Hi, some pages try to show multiple http auth dialogs at the same time ( one example is in http://crbug.com/26900 ). On linux, that happens to work fine, but on OS X it doesn't. I could change the OS X code to queue constrained windows and show only one window at a time per tab, or I could do the same thing for all platforms by putting the code in tab_contents. Any opinions out there? Nico --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Multiple constrained windows
How is it implemented now? -Ben On Sat, Nov 7, 2009 at 10:18 PM, Nico Weber tha...@chromium.org wrote: Hi, some pages try to show multiple http auth dialogs at the same time ( one example is in http://crbug.com/26900 ). On linux, that happens to work fine, but on OS X it doesn't. I could change the OS X code to queue constrained windows and show only one window at a time per tab, or I could do the same thing for all platforms by putting the code in tab_contents. Any opinions out there? Nico --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Multiple constrained windows
On Sun, Nov 8, 2009 at 16:48, Nico Weber tha...@chromium.org wrote: some pages try to show multiple http auth dialogs at the same time ( one example is in http://crbug.com/26900 ). On linux, that happens to work fine, but on OS X it doesn't. I could change the OS X code to queue constrained windows and show only one window at a time per tab, or I could do the same thing for all platforms by putting the code in tab_contents. Any opinions out there? As a user of HTTP auth dialogs for proxy authentication on Linux, I would appreciate changing the behaviour to only showing the window once. In fact, it would be better if there was only one auth window shown for the entire browser, but this is unique to the http proxy case - you don't want it when it's only one site requesting authentication. Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
