Not to beat a dead horse, but looking at these tables, it seems that
the decision to go one way or another can be made simply by looking at
the 3 bottom rows. However, I'm pretty sure you won't find any
existing messages that go over a few KBs. For any large data
transfer, we use shared memory b
This happened to me over the last few days with building Webkit's
tree. It was driving me nuts, until I also saw it with Chrome. I
rebooted and then it magically worked. My guess is that it was cygwin's fault.
On Wed, Nov 26, 2008 at 12:08 PM, Mike Belshe <[EMAIL PROTECTED]> wrote:
>
> Today m
On Fri, Dec 5, 2008 at 8:24 AM, Marc-Antoine Ruel <[EMAIL PROTECTED]> wrote:
>
> As an argument, you could say that isn't it funny activex controls can
> override the specified viewport size and even resize itself whenever
> it wants while a NPAPI has no control on its viewport?
You can actually
(It's been suggested that I send this out to a large audience, so here you go)
Most of the Rietveld problems that I see in the logs or that people
complain about has been with regards to either very large changelists
(i.e. > 100 files) or with many patchsets of large changelists (i.e.
10 patchset
ote:
>>
>> Awesome John. Thanks!
>>
>>
>> On Wed, Dec 10, 2008 at 4:00 PM, John Abd-El-Malek <[EMAIL PROTECTED]> wrote:
>>>
>>> (It's been suggested that I send this out to a large audience, so here you
>>> go)
>>>
>&
On Thu, Dec 11, 2008 at 1:03 AM, John Abd-El-Malek <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 11, 2008 at 12:07 AM, e. roman <[EMAIL PROTECTED]> wrote:
>>
>> Glad to hear this.
>> However I just tried building some webkit-merge changelists and
>> rietveld
Just a heads-up that I've integrated the script into our Rietveld
instance. If you use gcl, it will ping the server at a special url
after a patchset upload so that it can lint the files in the
background. When you visit the issue page, you'll see a "x errors"
link under the Lint column which t
script doesn't catch all style violations, but it
should cover enough to save reviewers tedious nitting.
>
> On Tue, Dec 16, 2008 at 11:20 PM, Adam Barth wrote:
>>
>> Awesome! Thanks John. Trailing whitespace be gone!
>>
>> On Tue, Dec 16, 2008 at 8:16 PM, John
On Mon, Dec 15, 2008 at 4:58 PM, Nicolas Sylvain wrote:
> Hello,
> As you all know, our tests are really flaky and are causing the tree to be
> red too often.
> I took a quick look at the test logs and compiled the stats about all the
> flakyness.
>
> UI TESTS:
> In the last 7 days, 188 ui te
2008 at 1:33 PM, Marc-Antoine Ruel
> wrote:
>>
>> Yep, that's simple and neat
>>
>> On Wed, Dec 17, 2008 at 1:29 PM, Erik Kay wrote:
>> > jam++
>> > Great stuff! I like how this is integrated. It feels very natural.
>> > Erik
&
On Tue, Jan 13, 2009 at 2:25 PM, Elliot Glaysher (Chromium) <
e...@chromium.org> wrote:
>
> Background: For the last couple of months, there have been requests
> from external contributors for a style linting tool. I've just finish
> cleaning Google's cpplint.py up for public release.
>
> cpplint.
Just a heads up about a very small gcl change which allows a description to
be added on an upload. This doesn't work on the first upload (since that
uses the description). You might find this useful when uploading new
versions of a change, to let the reviewer know what changed.
gcl upload change_
It seems that the only reason this code is needed is to get the function
pointers for the internal plugin. Perhaps the PluginVersionInfo &
InternalPluginInfo stuff could be taken out of the platform independent
code. ReadWebPluginInfo can be modified to return both the WebPluginInfo &
the three f
uld be functionally equivalent to adding an entry to the existing
>> g_internal_plugins array, but would be run-time accessible from elsewhere in
>> the code base.
>>
>> On Tue, Jan 20, 2009 at 1:48 PM, John Abd-El-Malek wrote:
>>
>>> It seems that the only reaso
r registering
>>>>>> internal plugins dynamically, instead of having to modify the
>>>>>> g_internal_plugins array in plugin_lib.cc.
>>>>>>
>>>>>> For instance (based on the current code):
>>>>>>
>>>>&g
t maintain these structures in a vector separate from
> PluginList::plugins_ and only use for the dynamically registered internal
> plugins.
>
>
> On Tue, Jan 20, 2009 at 3:27 PM, John Abd-El-Malek wrote:
>
>> Perhaps something like PluginList::AddExtraPluginPath can be added w
On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin 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 which mime-t
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 wrote:
> Wow. It s
I've gone through the code and removed all such occurrences. This
speeds up the build from 15 to 13 minutes (using /MP on quadcore with
SSD). It also means that editing that file only rebuilds 36 files
instead of 200.
There shouldn't be any reason to include that file from a header. The
reason th
Looks good, one comment: previously there's been some high level
comments about how workers can be used to give extensions a long lived
context. If this is still the case, would an extension that used a
worker & UI end up having to use two processes?
On Wed, Feb 4, 2009 at 5:49 PM, Matt Perry w
> table -> process_util -> process, which meant if you touched any of
> our process-management code we'd rebuild all of WebKit's SVG bindings.
> :~(
>
> For an especially painful build, try touching npapi.h. Apparently
> most of our project depends on that file.
>
On Thu, Feb 5, 2009 at 4:57 PM, Jeremy Moskovich wrote:
> Just a quick note, since this may be generally useful:
>
> If you pass the --renderer-startup-dialog when running the browser (or the
> unit tests) then any spawned render process will print a message to stdout
> with it's pid and then cal
On Fri, Feb 6, 2009 at 10:54 AM, Nicolas Sylvain wrote:
>
>
> On Thu, Feb 5, 2009 at 10:56 AM, John Abd-El-Malek wrote:
>
>>
>> One idea I've been thinking about is timing how long a clean build
>> takes, and tracking that just as we do with other performance te
(CCing chrome-dev so that others who don't know can search for this later.
Using Erik's & Huan's chromium emails so reply get sent to the list).
I submitted some refactoring and now I'm seeing the reliability and purify
tests are red, which I think is a false alarm due to callstacks changing.
Fo
rg/buildbot/purify/unit/
>
> Erik
>
>
> On Sat, Feb 21, 2009 at 12:12 PM, John Abd-El-Malek
> wrote:
> > (CCing chrome-dev so that others who don't know can search for this
> later.
> > Using Erik's & Huan's chromium emails so reply get sent to
great, thanks.
On Sun, Feb 22, 2009 at 2:31 PM, Patrick Johnson wrote:
> Hey John,
> I filed a bug for the reliability crash (
> http://code.google.com/p/chromium/issues/detail?id=7951) and added it to
> our known crashes file.
>
> Patrick
>
>
> On Sat, Feb 21, 20
I was looking at the second top crasher in 2.0.166.1, and it turned out that
these users are running with --in-process-plugins. This turns off the
sandbox and runs plugins in the renderer process.
So far we've exposed all the internal command line switches to all users,
but I'm wondering if that h
27;t currently have an archive of debug builds, but we do have that for
> Chromium release builds.
>
> --Mark
>
> On Mon, Mar 2, 2009 at 16:16, John Abd-El-Malek wrote:
>
>> I was looking at the second top crasher in 2.0.166.1, and it turned out
>> that these users a
gt; On Mon, Mar 2, 2009 at 4:25 PM, Elliot Glaysher (Chromium)
> wrote:
> >
> > +1. We absolutely should do this.
> >
> > -- Elliot
> >
> > On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek
> wrote:
> >> I was looking at the second top crasher in
Also, I don't feel that strongly regarding Chrome vs Chromium or Debug vs
Release. The only thing I'm strongly against is having this in Chrome
Release :)
On Mon, Mar 2, 2009 at 4:33 PM, John Abd-El-Malek wrote:
>
>
> On Mon, Mar 2, 2009 at 4:31 PM, Erik Kay wrote:
>
ill allow these flags in release builds when necessary.
>
> On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek
> wrote:
> > I was looking at the second top crasher in 2.0.166.1, and it turned out
> that
> > these users are running with --in-process-plugins. This turns off
is now fixed.
>
> <http://www.chromeplugins.org/tips-tricks/how-to-run-google-chrome-on-windows-7-64-bit/>
>
> - nick
>
> On Mon, Mar 2, 2009 at 4:36 PM, Evan Martin wrote:
>
>>
>> On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek
>> wrote:
>> > I was looki
h reports).
I think this is a small enough use-case, that pointing users towards
Chromium or Debug Chrome builds is almost just as good, while avoiding the
overhead with having official Chrome builds used in untested and buggy
configurations.
>
> -Darin
>
>
> On Mon, Mar 2, 2009 at
out the fact that
>> the option
>> is unsupported and potentially hazardous to the stability of Chrome.
>>
>> -Darin
>>
>>
>> On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek wrote:
>>
>>> I was looking at the second top crasher in 2.0.166
The point I was trying to make was that this isn't just about crash dumps.
For example, engineering effort will have to be done to filter them out of
UMA statistics. Also, there are reentrancy issues with plugins as Darin
mentioned. We know of them, but haven't bothered spending time chasing the
Just a heads up for others who find it annoying when svn st always shows the
vcproj.GOOGLE.username.user files. You can put *.user in the global-ignores
setting in svn's config file to avoid this.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev
On Thu, Mar 5, 2009 at 8:59 PM, eager_learner
wrote:
>
> Hello Plugin Gurus
>
> The following link is very well written and I hope it still holds good
>
> http://sites.google.com/a/chromium.org/dev/developers/design-documents/plugin-architecture
>
> I have some followup questions on plugin develop
I'm guessing I'm not the only one who's irritated by it. Can we make it so
that only members can post to chromium-reviews? We can automatically
subscribe everyone who's sent a review in the last month or something.
What do people think?
--~--~-~--~~~---~--~~
Chrom
ciently (we're
> already doing this for dev, many -bugs messages get held for moderation
> because they "look like spam", and we seem to have a reasonable turnaround
> time.)
> -Ian
>
> On Fri, Mar 6, 2009 at 10:38 AM, Peter Kasting wrote:
>
>> On Fri, Mar 6, 2009 a
Hi Vijay,
It sounds like reading up on NPAPI and how Windows applications paint is in
order :)
Here are some documents:
Here's the high level link about NPAPI on the Mozilla docs, links to samples
etc: https://developer.mozilla.org/en/Plugins
This is the reference for NPAPI:
https://developer.moz
The only place that calls it in the browser process is
BrowserAccessbilityManager, which I'm guessing isn't critical for the ports
(it's actually disabled by default on our shipping builds).
success = members->render_widget_host_->process()->channel()->
SendWithTimeout(msg, kAccessibilityM
One comment regarding synchronous IPC (I presume this is from the extension
process to the renderer\browser process): I agree that synchronous IPC is
slower, and better to be async when possible. However, if it's used for
APIs that aren't called frequently (100 calls/s, as opposed to thousands or
I think it'd be very helpful to just copy & paste it here:
http://dev.chromium.org/developers/design-documents/plugin-architecture
On Thu, Mar 12, 2009 at 3:38 PM, Evan Martin wrote:
>
> John graciously explained all this to me so I thought I'd write what I
> know before I forget. Amanda/John,
The reason I did it was because in the worker process, there's no frame.
Why/where do you need it?
On Mon, Mar 16, 2009 at 1:46 PM, Marshall Greenblatt wrote:
> Hi John,
>
> Rev 11763 removes the WebFrame pointer that was previously passed to
> ResourceLoaderBridge::Create() in simple_resource_
at 2:04 PM, Michael Nordman wrote:
> We're going to need some kind of reference to the 'context' for the app
> cache impl too, i had been depending on the WebFrame ptr for this thusfar,
> but that won't help us in workers.
>
> On Mon, Mar 16, 2009 at 2:01 PM
On Fri, Mar 20, 2009 at 10:23 AM, Jeremy Orlow wrote:
> Are there any plans (long term or short) to render stuff like iframes with
> a different origin inside a different process? Does the story get more
> complicated with plugs and extensions?
>
> *More background:*
> I'm looking at implementin
On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow wrote:
> *If you don't care where various bits of the localStorage implementation
> live and you aren't scared about letting stuff out of the sandbox, you can
> stop reading now.*
>
> *
> *
> Background:
>
> For those who don't know the spec by heart:
On Sun, Mar 22, 2009 at 5:17 PM, cpu wrote:
>
>
>
> On Mar 22, 8:47 am, empriser wrote:
> > There are more than 50,000 patches onhttp://codereview.chromium.org/;
>
> I don't think so. 50k/365 = 140. That means 140 patches per day
> including weekends. We are very active but not that active.
ri
2009/3/24 Thomas Van Lenten
> A bunch of process handle code is something we're gonna need to look very
> carefully at. The filtering via names may be valid on Windows, but on
> Linux, a user could have Chromium running twice (with different
> profiles/user data dirs) pointing at different displ
On Tue, Mar 24, 2009 at 10:00 AM, Amanda Walker wrote:
> 2009/3/24 John Abd-El-Malek :
> > Right, this is used so that if the user starts Chrome a second time, it
> > tells the currently running exe to open a new tab. This is the standard
> way
> > of doing it on Windo
On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade wrote:
>
> glib and x aren't thread-safe. To work around this our intention is to
> only call into them from the UI thread. Unfortunately we currently
> don't follow through on this.
>
> To query the clipboard the renderer sends a sync IPC call to the
On Fri, Apr 10, 2009 at 1:03 PM, Brett Wilson wrote:
>
> On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade wrote:
> > a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
> > the calls thread safe, but it does so by locking a process-wide mutex,
> > which will block our UI thread's
Does this also
include third_party\WebKit\WebKit\chromium\public\WebKitClient.h? I'm
guessing not, since none of those files are in the WebKit repository yet,
but just want to double check.
On Fri, May 1, 2009 at 8:35 AM, Dimitri Glazkov wrote:
>
> We are very, very close to total unforking. In
This is definitely awesome!
Too bad, I was just about to sign up to do the next n merges ;)
On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote:
>
> Hello all,
>
> This is kind of a momentous occasion. For the first time -- ever, our
> WebKit Canary bot (the one that pulls directly from WebKit
You can file a bug at http://code.google.com/p/rietveld/issues/list, and cc
me.
On Mon, May 11, 2009 at 9:36 AM, Darin Fisher wrote:
> In some cases, I suspect I may need to file the issue against upstream
> Reitveld... any guidance?
>
> Thanks,
> -Darin
>
> >
>
--~--~-~--~~---
One reason I don't find the IRC bot is as useful as subscribing to
chromium-checkins is that I'll miss checkins when I'm not looking at mirc or
when I get disconnected. I find it useful to add gmail filters for
filepaths (i.e. src/chrome/plugin or render_messages_internal).
On Tue, May 12, 2009 at
Are you sure this is broken? Flash uses this so if it was broken, we would
have seen lots of sites fail.
On a debug build, I can see this working fine using about:ipc.
NPN_GetProperty is called on "location"
and the returned object is NPN_Invoke'd to call "toString"
On Mon, Jun 8, 2009 at 1:38 A
criptStream, no stream is being created at
> all. As I mentioned before this used to work with Chrome 1.x. I'm not
> sure why the javascript document.location does not correctly result in
> a string. I probably need to dig in more. Does this exact sequence
> work correctly for y
BTW this is how Flash does it.
On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth wrote:
>
> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote:
> > We used to use NPN_GetURL with "javascript:document.location" as the
> > URL. In the current implementation, after this script is executed in
> > WebPluginImpl::E
9, 2009 at 3:36 PM, Adam Barth wrote:
> Flash does something similar, but not *precisely* the same. I stand
> by my statement that the below is insecure.
>
> Adam
>
>
> On Mon, Jun 8, 2009 at 8:08 PM, John Abd-El-Malek wrote:
> > BTW this is how Flash does it.
Flash does something similar, but not *precisely* what Vijay proposed.
> This approach is extremely fragile. If you require this value to
> make a security decision, I recommend a different approach (as I have
> now stated multiple times).
>
> Adam
>
>
> On Tue, Jun 9, 2009 at
matches what I observed and wrote below..
>
>
> Adam
>
>
> On Tue, Jun 9, 2009 at 1:30 AM, John Abd-El-Malek wrote:
> > My question to you is what you see Flash doing. I pasted below what I
> > observed by looking at their NPN calls.
> >
> > On
On Wed, Jun 10, 2009 at 11:48 AM, Meryl Silverburgh <
silverburgh.me...@gmail.com> wrote:
>
> From this document, it talks about Messaging between
>
> http://dev.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome
>
> Can you please help me understand what is the Message Flow
You can use the IPC logger, which is enabled in debug builds only by
default. about:ipc
On Windows this will popup a graphical display which also allows you to
filter for specific messages. On Linux, you need to set
the CHROME_IPC_LOGGING environment variable.
On Wed, Jun 10, 2009 at 7:24 PM, Me
about:ipc is only implemented on Windows.
For Mac/Linux, you need to set the CHROME_IPC_LOGGING environment variable.
All the messages will be dumped to stderr.
On Wed, Jun 10, 2009 at 8:34 PM, Meryl Silverburgh <
silverburgh.me...@gmail.com> wrote:
>
> Thank you. I try and successfully build ch
On Wed, Jun 10, 2009 at 10:19 PM, Meryl Silverburgh <
silverburgh.me...@gmail.com> wrote:
> On Wed, Jun 10, 2009 at 12:18 PM, John Abd-El-Malek
> wrote:
> >
> >
> > On Wed, Jun 10, 2009 at 11:48 AM, Meryl Silverburgh
> > wrote:
> >>
> >>
Just wanted to give a friendly warning, the same I gave to Nirnimesh, that
we don't want to do any extra processing in Rietveld. Otherwise it'll lead
to the 500s that people (don't) miss.
On Fri, Jun 12, 2009 at 12:40 PM, Marc-Antoine Ruel wrote:
>
> -> chromium-dev
>
> On Fri, Jun 12, 2009 at 1
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx wrote:
>
> I notice that when I load chrome.sln and do a build, not all the
> dependencies are built anymore. For instance, theme_dll isn't built
> (not listed in the proj deps), is this expected?
>
> On Jun 18,
Another missing dependency, in the runtime sense, is unit_tests
on test_chrome_plugin. Right now if you just compile that project from a
clean build, it'll crash.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek wrote:
> +1 this is affecting a lot of people.
>
>
> On Thu, J
Guess I should have
> brought it up, but I figured it was just something funny on my system.
>
> On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek wrote:
>
>> +1 this is affecting a lot of people.
>>
>>
>> On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx wrote:
>
On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek wrote:
> Yeah it happened to me before as well, I just figured I'd complain now..
> Note another missing dependency is on crash_service.exe
> , npapi_layout_test_plugin, and npapi_test_plugin
btw just to be clear, the
no updates. That's
> been taking a back seat to just getting the conversion completed, but I've
> accelerated my work on it as we wind down to the last few targets.
>
> --SK
>
>
> On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek wrote:
>
>>
>&
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
> Hi,
>
> yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
> design docs
>
> WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
> Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
2009/6/24 Drew Wilson
> BTW, I checked in with IanH - it sounds like WebSockets are also on the
> Worker roadmap, so that's something to keep in mind while you iterate on
> your design.
> +1 to avoiding WebCore/loader, but also +1 to refactoring to enable as much
> common code as possible cross-p
gt; share more code across implementations.
>
It'd be great of course if unconfirmed_message_count_
and asked_to_terminate_ weren't needed, but it's used to avoid a large
number of cross process calls (the equivalent variables in WebKit would be
in a different process). Almost all
2009/6/25 Fumitoshi Ukai (鵜飼文敏)
> Thanks for review.
>
> 2009/6/25 Michael Nordman
>
>> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>> to me.
>> * A version of the diagram you have in the chrome doc would be nice in the
>> webkit doc too.
>>
>
> Sure. I've added a
On Thu, Jun 25, 2009 at 1:54 AM, Non-Stick wrote:
>
> OK. Thanks for that Matt. At least now I know I was using the wrong
> mechanism.
>
> So what is the recommended way to download and install an NPAPI Plugin
> over the internet under Chrome ?
There's no way to make Chrome download your plug
It looks like it had trouble writing to /tmp. I don't think there are
missing binaries, looks like a space/permission issue. Is there enough
space available?
2009/6/29 David Jones
> I reviewed my layout-tests' output, and found some errors like:
> 090629 14:28:30 __init__.py:1032 ERROR
> Layou
Chrome and Safari don't support the pluginspage attribute. The best way to
get this small feature request on our radar is to file a bug.
On Tue, Jun 30, 2009 at 3:04 PM, Non-Stick wrote:
>
> > Can you create a test page that works differently in Firefox and
> > Chrome? If so, that's a strong a
This functionality doesn't exist right now. However Rietveld is open
source, so if anyone is interested in hacking something together, I'd be
more than happy to give feedback and code reviews.
On Mon, Jul 6, 2009 at 6:24 PM, Marshall Greenblatt
wrote:
> On Mon, Jul 6, 2009 at 8:40 PM, Mohamed Ma
There isn't a way to index data at the moment through the public API,
although I have seen hacks on the google group for app engine.
On Mon, Jul 6, 2009 at 7:54 PM, Marshall Greenblatt
wrote:
> On Mon, Jul 6, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>
>> This functionality do
Just a heads up that you can now reply to code review emails and your reply
will show up on Rietveld.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.googl
Note: this finds the Rietveld issue number by looking for the last
http://codereview.chromium.org/ url in the email. So make sure to leave
that url in the email, and if you add another url to a different issue,
don't put it at the end.
On Mon, Jul 6, 2009 at 9:11 PM, John Abd-El-Malek
tool) does it...
> Maybe the chromium-revi...@googlegroups.com could be changed to
> chromium-reviews+@googlegroups.com and that could be
> used instead?
>
> On Wed, Jul 8, 2009 at 5:44 PM, John Abd-El-Malek wrote:
>
>> Note: this finds the Rietveld issue n
On Fri, Jul 17, 2009 at 10:45 AM, Daniel Wagner-Hall wrote:
>
> Hi,
>
> Can anyone help me with this? How can I get the window handle of an
> element from its JS DOM node?
DOM elements, with the exception of plugins and select controls, don't have
window handles because they're not implemented a
On Fri, Jul 17, 2009 at 12:06 PM, Daniel Wagner-Hall wrote:
>
> I can happily get the plugin's window handle using standard NPAPI
> calls, I'm trying to get the window handle of arbitrary tabs (and
> indeed frames) which my extension has loaded
>
> Specifically, I am opening pages, at the moment u
I have a leak after a check-in. I tried following the instructions on my
Linux box, but couldn't (I hardly develop on Linux).
jabdelma...@jabdelmalek:/usr/local/google/chrome/src$ sh
tools/valgrind/chrome_tests.sh --generate_suppressions -t ui
Usage: chrome_tests.py -b -t [-t ...]
chrome_tes
On Mon, Jul 20, 2009 at 7:31 PM, Thomas Van Lenten wrote:
>
>
> On Mon, Jul 20, 2009 at 10:04 PM, John Abd-El-Malek wrote:
>
>> I have a leak after a check-in. I tried following the instructions on my
>> Linux box, but couldn't (I hardly develop on Linux).
>&
The plug-in sandbox is too weak to be robust, see the other thread about it.
As long as it has access to HWNDs, it's very easy to break out of it.
On Wed, Jul 29, 2009 at 10:43 AM, Adam Barth wrote:
>
> I wonder if we could use something like the plug-in sandbox for the
> main browser process i
On Tue, Jul 28, 2009 at 8:40 PM, Jeremy Orlow wrote:
> I'm starting to think ahead to how quotas will work with LocalStorage (and
> I assume database and maybe even AppCache). To begin with, I'll probably
> just set a fixed quota (5mb is pretty standard), but some apps will surely
> desire more
whoa, please revert this change. if I have a big changelist, now every time
I run gcl I have to expend effort to make sure no new files crept in. this
will lead to more build failures as people check in other files accidently.
On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge wrote:
> Howdy,
> Q
This is very cool, but I ran into a few problems when I tried to run it:
a:\chrome2\src\chrome>tools\test\smoketests.py --tests=ui
>> You must have your local path of trunk/src/tools/python added to your
PYTHONPATH.<<
Traceback (most recent call last):
File "A:\chrome2\src\chrome\tools\test\smo
Intentional but I have a TODO in the Chromium branch of Rietveld to update
this. I just synced ~60 changes from trunk to our branch, and now we get a
close button to the left of each issue. Since everyone with a @chromium
account could edit an issue, I thought it was too easy to accidentally clos
On Sun, Aug 16, 2009 at 3:14 PM, Mark Mentovai wrote:
> John Abd-El-Malek wrote:
> > Intentional but I have a TODO in the Chromium branch of Rietveld to
> update
> > this. I just synced ~60 changes from trunk to our branch, and now we get
> a
> > close button to the
On Mon, Aug 17, 2009 at 11:43 AM, bsmedberg wrote:
>
> At Mozilla we're currently working on implementing multi-process
> plugin hosts similar to the model used by Chromium. However, we're
> having trouble working through the many potential race conditions
> introduced by having multiple processe
On Tue, Aug 18, 2009 at 5:37 AM, Evan Martin wrote:
> On Sat, Aug 15, 2009 at 11:44 PM, Nico Weber wrote:
> > `git cl patch` reuses existing issues, so when landing stuff for other
> > people, I used to edit the issue on codereview to add "Patch by
> > someone+usuallytru...@example.org "
> before
Have you tried using the ipc logger (about:ipc in debug builds)? You can
look at all the messages and their content.
On Tue, Aug 18, 2009 at 11:16 AM, hap 497 wrote:
> Thanks. I did debug on Renderer process.
> As a matter for fact,
> This breakpoint 'WebFrameLoaderClient::dispatchWillSendReque
The information on how to do this is currently on the internal wiki,
although it seems there's no reason it shouldn't be moved to the public wiki
(not it :) ).
http://wiki.corp.google.com/twiki/bin/view/Main/ChromeDebuggingChromeBotCrashes
On Tue, Aug 18, 2009 at 3:42 PM, James Hawkins wrote:
>
>
Including files like render_messages.h and automation_messages.h from other
header files is unnecessary and slows down the build (adds about ~100K lines
of headers to each cc file). Last time I removed all these occurrences, it
improved the build time by 15%. Looks like a few more crept in now, s
ng to write a presubmit check for that.
>
> On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek wrote:
>
>> Including files like render_messages.h and automation_messages.h from
>> other header files is unnecessary and slows down the build (adds about ~100K
>> lines of headers to
1 - 100 of 201 matches
Mail list logo
