Well, we don't have a sandbox on Linux. The normal fd-passing
recvmesg() should work fine. Who knows if it will work if we ever get
a sandbox.
On Tue, Jan 27, 2009 at 5:55 AM, Andrew Scherkus scher...@chromium.org wrote:
Great! I'm really interested in using shared FDs.
Just to clarify,
I've hung off this page another page for Mac issues that will need followup
(
http://sites.google.com/a/chromium.org/dev/developers/browser-bootstrapping/mac-followup).
As you hit other issues, please note them there so they are all in one
place.
TVL
On Tue, Jan 20, 2009 at 10:18 AM, Mike
Noticed in passing while looking for something else this morning
(though they may have been there a while).
These sound potentially nasty; is anybody looking at them already?
$ valgrind --track-origins=yes Hammer/test_shell_tests
...
[ RUN ] WebFrameTest.GetContentAsPlainText
UNIMPLEMENTED:
The last one looks similar to https://bugs.webkit.org/show_bug.cgi?id=23473
or https://bugs.webkit.org/show_bug.cgi?id=22834, which Brett Wilson and
Dean McNamee appear to be working on.
- James
On Tue, Jan 27, 2009 at 11:45 AM, Dan Kegel daniel.r.ke...@gmail.comwrote:
Noticed in passing
It seemed complicated to allow other processes direct access to the
DOM, so we were not going to do that. For something like the
inspector, what we were thinking is a client/server model, with the
client being JS that interacts with the DOM and the server being in
another process and showing the
On Tue, Jan 27, 2009 at 8:08 PM, Aaron Boodman a...@chromium.org wrote:
It seemed complicated to allow other processes direct access to the
DOM, so we were not going to do that.
But many extensions will need to access the DOM one way or another.
Are you going to restrict this access or
With regard to moving the DOM inspector out of process Sergey Ryazanov have
filed https://bugs.webkit.org/show_bug.cgi?id=23502 with a rather large
patch where the inspector access to the DOM is being factored to an
interface layer which will allow us to move the DOM inspector
out-of-process.
On Tue, Jan 27, 2009 at 12:04 PM, Søren Gjesse sgje...@chromium.org wrote:
With regard to moving the DOM inspector out of process Sergey Ryazanov have
filed https://bugs.webkit.org/show_bug.cgi?id=23502 with a rather large
patch where the inspector access to the DOM is being factored to an
(apologies for resend)
Yes. This is the same issue. This was also reported in:
http://code.google.com/p/chromium/issues/detail?id=5464
where we decided to filter the errors in Purify because the code was
argued to be correct and an important optimization (and they didn't
want to change it).
I'd been sending this sort of stuff to Dean and John but maybe other
people will find it interesting.
Plugin loading works in two phases:
- at startup, we scan the plugin directories for metadata, like plugin
names and which mime-types they apply to;
- at runtime, when we're asked for a specific
On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin e...@chromium.org wrote:
I'd been sending this sort of stuff to Dean and John but maybe other
people will find it interesting.
Plugin loading works in two phases:
- at startup, we scan the plugin directories for metadata, like plugin
names and
There are a lot of patches lately with a lot of reviewers on them,
especially related to porting since a lot of people might need to be
in the loop for some changes.
The problem is that there's no clear responsibility given in these
reviews. If I'm the sole reviewer on a change, I know I have to
I think specifying the reviewer's responsibility in the description/message
is a good start. It might also help when requesting specific feedback about
design details as opposed to checking code style.
Andrew
On Tue, Jan 27, 2009 at 10:13 PM, Amanda Walker ama...@chromium.org wrote:
On Wed,
Wow. It sucks that we'll need to load plugins in the main browser process.
That gives plugins a nice opportunity to hose the browser. Oh well :-( If
we really wanted to, I suppose we could have a plugin scanner process, but
that seems unfortunately heavyweight.
-Darin
On Tue, Jan 27, 2009
On Tue, Jan 27, 2009 at 10:04 PM, Brett Wilson bre...@chromium.org wrote:
There are a lot of patches lately with a lot of reviewers on them,
especially related to porting since a lot of people might need to be
in the loop for some changes.
The problem is that there's no clear responsibility
One of my goals with the out of process worker code is it to make it easier
to have many different types of child processes. Perhaps it makes sense to
have the linux port do this stuff in a child process once that code is
ready.
On Tue, Jan 27, 2009 at 10:49 PM, Darin Fisher da...@chromium.org
16 matches
Mail list logo
