ore
might start receiving them. Everyone on chromium-dev also is marked for
moderation without a reason. Trying to fix both of these issues.
On Wed, Jan 20, 2010 at 1:14 PM, John Abd-El-Malek wrote:
> Just to explain to everyone the steps that I will follow. For each mailing
> list, I
Hello,
The chromium-dev mailing list has now been switched to
chromium-...@chromium.org. Please update your filters and address book
accordingly.
Existing members have been subscribed, with the exception of users who don't
permit managers to add them to a group. You can visit the new group at
h
managers can post)
3) send an email to the old list telling everyone that it's now disabled and
that they must now post to the new list
On Wed, Jan 20, 2010 at 11:08 AM, John Abd-El-Malek wrote:
> This is a heads up that as part of moving all of our resources to
> chromium.org
This is a heads up that as part of moving all of our resources to
chromium.org (and vanity!), I'll be switching our mailing lists to be under
chromium.org today. I will send an email when it's done, but for now you
may want to update your rules to be either googlegroups.com or
chromium.orgso that
On Mon, Dec 14, 2009 at 10:42 AM, Drew Wilson wrote:
> They'll sometimes get disabled due to webkit updates, other times they'll
> get disabled due to other things (for example, we changed the valgrind bots
> to fail noisily if individual tests fail, regardless of whether they
> actually generate
(this topic has been on my mind a lot, so here's my vent :) )
I think we shouldn't allow any test to be disabled without a bug to track it
that includes an initially assigned owner. This shouldn't
I've seen it happen too often that a test gets disabled to quickly turn the
tree green, and it stays
ous to the user that they shouldn't be
running without sandbox but we need to give them a better way to figure out
what's wrong so that they can continue to use it.
--
Alice Lin | Google, Inc. | Senior Strategist, Consumer Operations |
650.253.6827 | a...@google.com
On Fri, Dec 11, 2009 a
(adding Alice)
Alice: do you have a rough estimate for how often we ask users to turn off
the sandbox when debugging problems?
Thanks
On Fri, Dec 11, 2009 at 11:33 AM, John Abd-El-Malek wrote:
>
>
> On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher wrote:
>
>> I don't th
IMO.
>
> -Darin
>
>
> On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow wrote:
>>
>>> On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting wrote:
>>>
>>>> On Thu,
On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow wrote:
> On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting wrote:
>
>> On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek wrote:
>>
>>> We disable --single-process and --in-process-plugins on release Google
>>>
We disable --single-process and --in-process-plugins on release Google
Chrome builds to avoid the support headache that it causes. I think we
should do the same for --no-sandbox.
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher wrote:
> After reading the WebGL blog post today, and following the li
The goal is to expose all this through Pepper.
On Thu, Dec 10, 2009 at 5:50 PM, Jeremy Orlow wrote:
> Much of what can't be done on the web platform also can't be done inside
> the NaCl sandbox.
>
>
> On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek > wrote:
&g
NaCl is the answer to all these problems...
On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow wrote:
> Or reject extensions that could be written without a NPAPI component.
> *ducks*
>
> On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting wrote:
>
>> On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman wrote:
On Thu, Dec 10, 2009 at 1:22 PM, Evan Stade wrote:
> On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting wrote:
>
>> On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon wrote:
>>
>>> In essence:
>>>
>>> return DoWork(&foo)
>>> #if defined(OS_POSIX)
>>> && DoWork(&posix_specific)
>>> #endif
>>> ;
On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon wrote:
>
>
> 2009/12/10 Brett Wilson
>
> On Wed, Dec 9, 2009 at 4:24 PM, John Abd-El-Malek
>> wrote:
>> > btw I searched the code, almost all the instances are in code from
>> different
>> > reposit
btw I searched the code, almost all the instances are in code from different
repositories, like v8, gtest, gmock. I counted only 17 instances in
Chrome's code.
On Wed, Dec 9, 2009 at 4:08 PM, Evan Stade wrote:
> I didn't even know that I could disable the linter like that. Good to
> know---doze
Lately I've been seeing more and more // NOLINT added to the code. It's
great that people are running lint to make sure that they're following the
guidelines, but I personally find adding comments or gibberish to our code
for tools that are supposed to make the code quality better happy/more
consi
This is much needed, thanks for working on it :)
Some notes:
-Putting it in a url, but not having a menu item, removes much of the
benefit since only a tiny percentage would be able to use it.
-Checking that each plugin is up to date should be automatic and enabled for
all users, just like our plu
Note: this should be working again now. We decided to put the issue numbers
in the subject line like Mondrian (but at the end, as to not conflict with
bug numbers which are put at the front of Python bug mail).
On Thu, Nov 19, 2009 at 11:40 AM, John Abd-El-Malek wrote:
> There is a bug in
On Thu, Nov 19, 2009 at 2:17 PM, Matt Perry wrote:
> On Thu, Nov 19, 2009 at 2:14 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Thu, Nov 19, 2009 at 1:57 PM, Tony Chang wrote:
>>
>>> For reasons unknown to me, this line jumped back up. It seems it&#
ings look fine on Windows (the perf graph is what I'd expect, and
>> running the test locally results in toolstrip50 results greater than
>> toolstrip1). These tests don't run on Mac. We should run the tests on
>> Linux to verify things look sane locally, too. No expla
There is a bug in App Engine with some new APIs that we're using. I'm
working on a workaround with another outside contributor which will
hopefully land in a day or two. Until then, if you care about your reply
showing up on Rietveld, don't reply by email.
--
Chromium Developers mailing list: c
run slower
> than the extension_toolstrip1 test. Maybe the graph is pulling the wrong
> numbers?
>
>
> http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150&graph=warm
>
> On Wed, Nov 18, 2009 at 9:53 AM, John Abd-El-Malek wrote:
>
>>
Yep, that was my plan. I'm planning on doing the same thing for the rest of
the child processes, and if I see any significant changes on the perf test
(which I don't expect), I'll update the reference builds again.
On Wed, Nov 18, 2009 at 6:46 AM, Brett Wilson wrote:
> On Tue, Nov 17, 2009 at 1
Heads up to explain the sudden jump on Linux Startup perf test.
I just submitted r32264 which makes opening and closing processes happen off
the UI thread. Surprisingly enough, according to UMA stats these would take
an average of 1s on Linux for the first renderer, and 100ms on Windows.
Subsequ
t should be as zippy as 2005 now
>
> On Thu, Oct 29, 2009 at 7:23 PM, Mike Belshe wrote:
> > On Thu, Oct 29, 2009 at 3:34 PM, John Abd-El-Malek
> wrote:
> >>
> >>
> >> On Thu, Oct 29, 2009 at 3:23 PM, Finnur Thorarinsson <
> fin...@chromium.org>
On Thu, Nov 12, 2009 at 11:45 AM, Paweł Hajdan Jr.
wrote:
> On Thu, Nov 12, 2009 at 20:26, John Abd-El-Malek wrote:
>
>> My question still stands: if this list is needed in order to process the
>> first network request, why add extra complexity to RDH to make more things
>
On Wed, Nov 11, 2009 at 10:40 PM, Paweł Hajdan Jr.
wrote:
> On Thu, Nov 12, 2009 at 01:00, John Abd-El-Malek wrote:
>
>> On Wed, Nov 11, 2009 at 1:22 PM, Paweł Hajdan Jr. <
>> phajdan...@chromium.org> wrote:
>>
>>> To do that, I'd need to listen for B
On Wed, Nov 11, 2009 at 1:22 PM, Paweł Hajdan Jr.
wrote:
> Initially I got an advice to use PauseRequest and ResourceHandler to wait
> with servicing requests until all privacy blacklists are loaded. However,
> there are problems with that.
>
> When you look at ResourceDispatcher code, we need a B
Enabling contribution to Chrome on Windows without having to purchase any
software is very welcome, good job :)
I looked at the steps, and as I'm sure you're thinking, if these can be
incorporated into the gyp sln generation that would be ideal.
On Mon, Nov 9, 2009 at 6:21 PM, Dominic Jodoin wrot
On Sun, Nov 8, 2009 at 12:04 PM, Drew Wilson wrote:
> In base webkit (i.e. the default, single-process implementation of
> SharedWorkers), I route all of these errors back to the individual parent
> documents on the main thread, and log them via
> ScriptExecutionContext::reportException() and
> S
On Thu, Nov 5, 2009 at 1:42 PM, Jeremy Orlow wrote:
> On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow wrote:
>>
>>> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>>>
On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow wrote:
> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>
>> Over the last week, I've been making some changes to how threads are used
>> in the browser process, with the goal of simplifying cross-thread access and
I've gone through the code and made all destructors of objects that derive
from base::RefCounted or base::RefCountedThreadSafe private. This helps to
catch corruption bugs at compile time. For classes that are derived from
refcounted, make the destuctor protected and ensure that all derived class
On Tue, Nov 3, 2009 at 11:49 PM, Paweł Hajdan Jr.
wrote:
> I encountered another problem related to Singletons in unit tests.
> PluginService is a Singleton, and it listens to extensions notifications. In
> one of my tests when I was using the extensions notifications the
> PluginService crashed b
process? We try to keep the media
> processing code off the render thread but we've been bitten using cached
> MessageLoops which have been destructed (usually on tab close when the
> render thread goes away).
>
> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>
>> Over
system. No idea why.
>
That sounds like a bug, because external contributors are able to use it.
Marc-Antoine?
> -Ben
>
>
> On Tue, Nov 3, 2009 at 7:05 PM, John Abd-El-Malek wrote:
>
>> But this means that the person didn't use the trybot.
>>
>> I think
On Tue, Nov 3, 2009 at 12:03 AM, Paweł Hajdan Jr.
wrote:
> On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek wrote:
>
>> *The solution*
>> 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask,
>> DeleteSoon, ReleaseSoon) which are safe and efficient: no loc
But this means that the person didn't use the trybot.
I think we need to be harsher on people who commit with changes that didn't
complete or failed on the trybot. They need to have a really good reason as
to why they want to try their change on the buildbot and possibly delay many
other engineer
Ren wrote:
> Cool! I could compare the builds before and after these changes to see
> what difference it makes. Of course it also prevents future issues.
>
> Huan
>
> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek
> wrote:
> > Over the last week, I've been making
Over the last week, I've been making some changes to how threads are used in
the browser process, with the goal of simplifying cross-thread access and
improving stability.
*The problem*
We were using a number of patterns that were problematic:
1) using ChromeThread::GetMessageLoop
-this isn't s
ere are no
> UI tests in interactive_ui_tests).
>
> I also suggest bumping the priority of http://crbug.com/25997 to P1 and
> possibly marking it with FlakyTest label.
>
> On Mon, Nov 2, 2009 at 09:37, John Abd-El-Malek wrote:
>
>> This is related to bug 25997. The tests
This is related to bug 25997. The tests are inherently flakey because
singeltons aren't released between runs, so cached MessageLoop pointers are
bogus. Sometimes they're ok when the order of construction/destruction of
MessageLoop pointers is the same. But if that changes, or other memory
alloc
On Thu, Oct 29, 2009 at 5:31 PM, Evan Martin wrote:
> On Thu, Oct 29, 2009 at 5:28 PM, Evan Martin wrote:
> > If you add the junk to your ~/.subversion/config that's specified on this
> page
> > http://dev.chromium.org/developers/coding-style
> > then git will do the right thing as well. (I ju
Per the Chromium style guide (
http://dev.chromium.org/developers/coding-style), we require all new files
to have the svn:eol-style property set. We even have a presubmit check for
it in case you don't configure Subversion to automatically add them per the
above previous link.
git users seem to no
comparison, only a few breakpoints in both, fresh
build, both on SSD etc.
>
>
>
> On Thu, Oct 29, 2009 at 14:51, John Abd-El-Malek wrote:
>
>>
>>
>> On Thu, Oct 29, 2009 at 2:38 PM, Mike Belshe wrote:
>>
>>> I've been using VS2008 on Win7 for th
On Thu, Oct 29, 2009 at 2:38 PM, Mike Belshe wrote:
> I've been using VS2008 on Win7 for the last month or so.
>
> I hate it.
>
> Problems:
>
> 1) Stepping in the debugger is SOOO slow. I am thinking about going
> back to VS2005.
>
I was just about to reply and say the same thing (on Win 7)
On Tue, Oct 27, 2009 at 10:40 PM, Darin Fisher wrote:
> On Tue, Oct 27, 2009 at 10:35 PM, Adam Barth wrote:
>
>> On Tue, Oct 27, 2009 at 10:27 PM, Darin Fisher
>> wrote:
>> > What version of Windows are you using? I find the double-buffering on
>> Vista
>> > and Win7 to have a big negative imp
Check out BufferedResourceHandler, it pauses requests until plugins are
loaded (needed to know which mime types are available).
On Fri, Oct 23, 2009 at 1:23 PM, Paweł Hajdan Jr.
wrote:
> I'm going to use PauseRequest for privacy blacklists. It seems that I
> should create a new ResourceHandler, a
On Tue, Oct 13, 2009 at 3:46 PM, Dimitri Glazkov wrote:
>
> Based on the feedback, it sounds like we need to take the approach
> with LTTF team adding more resources on cleaning up the bottom of the
> test_expectations file (i.e. stuff recently added by the gardeners).
>
> It is still the gardener
>> > Anthony Laforge
>> > Technical Program Manager
>> > Mountain View, CA
>> >
>> >
>> > On Tue, Oct 6, 2009 at 7:26 PM, Patrick Johnson
>> > wrote:
>> >>
>> >> [+laforge]
>> >>
>> >&g
I got 21 emails in the last day for
http://code.google.com/p/chromium/issues/detail?id=20915
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/gro
This isn't about decreasing memory usage. It's about getting rid of nasty
problems like the browser process crashing every startup because of a
corrupt database and decreasing browser process crashes in general.
I think it's fair that not everyone shares the same opinion, but I do hope
that an exp
On Tue, Oct 6, 2009 at 5:56 PM, Peter Kasting wrote:
> On Tue, Oct 6, 2009 at 5:53 PM, John Abd-El-Malek wrote:
>
>> If corruption in the in-memory URL database doesn't survive a crash (i.e.
>> because it's recreated each time),
>>
>
> It doesn't
&
On Tue, Oct 6, 2009 at 5:30 PM, Peter Kasting wrote:
> On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek wrote:
>
>> Given that sqlite corruption means (repeated) crashing of the browser
>> process, it seems this data heavily suggests we should separate sqlite code
>>
On Tue, Oct 6, 2009 at 5:16 PM, Scott Hess wrote:
> On Tue, Oct 6, 2009 at 5:09 PM, Jeremy Orlow wrote:
> > On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek
> wrote:
> >> On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano wrote:
> >>> On Tue, Oct 6, 2009 at 4:
ake from
> there.
>
I do think these are two separate problems. Personally, I don't care as
much if my history or any other database is corrupted and I start from
scratch. But random crashes that I can't isolate is something else.
> -scott
>
>
> On Tue, Oct 6, 2009
On Tue, Oct 6, 2009 at 5:09 PM, Jeremy Orlow wrote:
> On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano wrote:
>>
>>> On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek
>>> wrote:
On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano wrote:
> On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek
> wrote:
> > I'm not sure how Carlos is doing it? Will we know if something is
> corrupt
> > just on load/save?
>
> Many sqlite calls can return sqlite_co
at 3:58 PM, Huan Ren wrote:
> It will be helpful to get our own measurement on database failures.
> Carlos just added something like that.
>
> Huan
>
> On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek
> wrote:
> > Saw this on
> > slashdot: http://www.cs.toronto.
Saw this on slashdot:
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
The conclusion is "an average of 25,000–75,000 FIT (failures in time per
billion hours of operation) per Mbit".
On my machine the browser process is usually > 100MB, so that averages out
to 176 to 493 error per year, w
On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade wrote:
>
> > We try to fire the timer rapidly, but if we get bogged down, it just
> won't fire until later; when it actually does fire, we update our state
> > based on how much time has really passed instead of how many times the
> timer has triggered.
Cygwin (1.5.25-15), copying sh.exe
> and bash.exe over to src\third_party\cygwin\bin.
>
> So it may be a good idea to check in this Cygwin version.
>
> On Oct 1, 2009 4:43pm, John Abd-El-Malek wrote:
> > I built using the instructions on Windows 7 64 bit without installing
> anot
I built using the instructions on Windows 7 64 bit without installing
another cygwin.
On Thu, Oct 1, 2009 at 4:03 PM, vha14 wrote:
>
> So it looks like I need to install Cygwin separately before I can
> build Chrome? If so this should be added to the Windows build
> instruction page.
>
> On Oct
t;
> We need to add to v8's svn:ignore.
>
> John Abd-El-Malek wrote:
> > Every time v8 team updates which branch is the one that's used in Chrome,
> > gclient sync fails on Windows. The error is below.
> > running 'svn update a:\chrome2\src\tools
Every time v8 team updates which branch is the one that's used in Chrome,
gclient sync fails on Windows. The error is below.
running 'svn update a:\chrome2\src\tools\tryserver' in 'a:\chrome2'
At revision 3275.
Error: Can't switch the checkout to http://v8.googlecode.com/svn/tr...@2966;
e filenames are generates when in the
WebKit directory. Marc-Antoine knows this best, so I'm handing it off.
On Wed, Sep 23, 2009 at 10:13 AM, Dimitri Glazkov wrote:
> BTW, I trying to be snarky in my request. More like begging :)
>
> :DG<
>
> On Wed, Sep 23, 2009 at 10:08 AM
reat idea! Do we have a Python/gcl/rietveld expert
> who can tackle this?
>
> :DG<
>
> On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek
> wrote:
> > I didn't know this was possible. It seems it will get a lot more usage
> if
> > it "just works&
(also to
upload) can use this transparently. What do you think?
On Wed, Sep 23, 2009 at 7:42 AM, Marc-Antoine Ruel wrote:
> On Tue, Sep 22, 2009 at 9:35 PM, Adam Barth wrote:
> > On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek
> wrote:
> >> Is this even possible? i
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov wrote:
>
> Today wasn't a happy day for p...@. He did a seemingly innocuous roll
> that broke the world: selenium, ui tests, layout tests. I am sure it
> was stressful and probably added unnecessary gray to his hair.
>
> Stuff like this happens to W
Agreed, we should have a --browser-startup-dialog that's added to
BrowserMain. ui_tests can then pass it and --renderer-startup-dialog,
plugin-startup-dialog, in-process-plugins, --single-process along if they're
specified.
On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet wrote:
>
> If you uncomme
It only takes a few moments to figure out this information, and ensures that
the bug lands on the right person's desk.
http://src.chromium.org/viewvc/chrome/trunk/src/ can show who wrote the
initial test
For commits before we moved to the open source repository, look at
http://chrome-corpsvn.mtv/vi
On Mon, Sep 21, 2009 at 3:59 PM, Jeremy Orlow wrote:
> On Mon, Sep 21, 2009 at 3:51 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow wrote:
>>
>>> On Mon, Sep 21, 2009 at 3:29 PM, John Abd-El-Malek wrote:
>>>
On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow wrote:
> On Mon, Sep 21, 2009 at 3:29 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow wrote:
>>
>>> I think we need to re-consider our practice of shipping beta/stable
On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow wrote:
> I think we need to re-consider our practice of shipping beta/stable
> browsers with experimental features hidden behind flags--at least when they
> have any side-effects in JavaScript. An example of where this has bitten us
> is http://code.
agreed
>
>
>
>
> On Fri, Sep 11, 2009 at 4:30 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Fri, Sep 11, 2009 at 4:03 PM, Mike Morearty wrote:
>>
>>>
>>>
>>> On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin wrote:
>>>
&g
On Fri, Sep 11, 2009 at 4:32 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 7:31 PM, John Abd-El-Malek wrote:
>
>> If this sounds good to you, the next step would be getting a broader
>> discussion with other browser vendors on the plugin-futures mailing list (
>>
On Fri, Sep 11, 2009 at 4:34 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 7:28 PM, John Abd-El-Malek wrote:
>
>> Through whatever plugin installer they have (i.e. Flash's installer) or
>> the toolkit (i.e. Flash Builder).
>>
>
> So are you suggesting
On Fri, Sep 11, 2009 at 4:01 PM, Mike Morearty wrote:
>
>
> On Fri, Sep 11, 2009 at 3:54 PM, John Tamplin wrote:
>
>> On Fri, Sep 11, 2009 at 6:37 PM, John Abd-El-Malek wrote:
>>
>>> For reference, something similar is done for popups:
>>> void NPN_P
On Fri, Sep 11, 2009 at 4:03 PM, Mike Morearty wrote:
>
>
> On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin wrote:
>
>> On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek wrote:
>>
>>> I presume you're referring to Chrome extensions? I don't see the
On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek wrote:
>
>> I presume you're referring to Chrome extensions? I don't see the
>> advantage of making this depend on the plugin being distributed via
>> ex
On Fri, Sep 11, 2009 at 2:46 PM, John Tamplin wrote:
> On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher wrote:
>
>> I think that is a reasonable feature request. It would be nice however if
>> there were some way to know when to restore the old behavior.
>> Unfortunately, Chrome won't know when y
For reference, something similar is done for popups:
void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled);
void NPN_PopPopupsEnabledState(NPP instance);
Perhaps we can do the same thing here:
void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled);
void NPN_Pop PluginHangDetec
I think this adds a lot of complexity.
On Fri, Sep 11, 2009 at 2:44 PM, Scott Hess wrote:
>
> Could it be like incognito mode, where the window is special and the
> tabs cannot be pooled with other modes? Then we'd know you were done
> when all your plugin-dev tabs were gone.
>
> -scott
>
>
> O
hen it is viewed in Rietveld?What about when it
> is actually committed, can the change log be tweaked that way,
> automatically, too?
> That would be nice when reading change logs.
>
> Thank you!
>
> ☆PhistucK
>
>
>
> On Thu, Sep 10, 2009 at 05:01, John Abd-El-Malek
Thanks, glad you enjoy it :)
This was a side distraction to fix the annoying issue of having to manually
copying and pasting the bug ids. It severely tested my regex-fu and since
the multiple bugs case should be rare, I'll hide behind the excuse that if
they're duplicates they should be marked as
I'm personally fine with these numbers, thanks for generating them. I guess
one additional benefit is that there'll be less release-specific build
breaks.
On Fri, Sep 4, 2009 at 11:50 AM, Marc-Antoine Ruel wrote:
> - quad core
> - without IB
> - VS2005 (without /MP, with incremental linking)
> -
> Thanks.
>
> On Thu, Sep 3, 2009 at 10:53 AM, John Abd-El-Malek wrote:
>
>> These leaks have always existed in the unit tests. They don't happen in
>> Chrome builds since the posted tasks always get a chance to run on different
>> thread where they clean
These leaks have always existed in the unit tests. They don't happen in
Chrome builds since the posted tasks always get a chance to run on different
thread where they clean up. But in unit tests that doesn't (always) happen.
It's been low priority for me to look at because it's not a real leak,
it'll make showModalDialog work.
> jrg
>
> On Mon, Aug 31, 2009 at 9:57 AM, John Abd-El-Malek wrote:
>
>>
>>
>> On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess wrote:
>>
>>>
>>> On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote:
>>&g
On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess wrote:
>
> On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote:
> > Well, that annoying throbber is still chewing up time, causing some
> > amount of UI loop contention while the images, thumbnails, and icons
> > are fetched. Windows and Linux don't h
Can't we blacklist nspluginwrapper, and use the same logic that it uses to
find the real plugins?
On Fri, Aug 28, 2009 at 11:01 AM, Evan Martin wrote:
>
> Right now our plugin loading code matches Firefox in the search path order.
> 1 $MOZ_PLUGIN_PATH
> 2 ~/.mozilla/plugins
> 3 path_to_chrome
On Thu, Aug 27, 2009 at 11:57 AM, hap 497 wrote:
>
>
> On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson wrote:
>>
>>>
>>> On Mon, Aug 24, 2009 at 12:49 PM, hap 497 wrote:
>
On Wed, Aug 26, 2009 at 1:20 PM, Dan Kegel wrote:
>
> On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlow wrote:
> >> I really like the idea of being able to move people between
> >> operating systems and just bringing the profile along
> >> without having to export and import...
> >>
> >> (seems to m
On Wed, Aug 26, 2009 at 12:41 PM, Darin Fisher wrote:
> On Wed, Aug 26, 2009 at 12:16 PM, Brett Wilson wrote:
>
>>
>> On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
>> > I've heard people proclaim the principle of being able to copy a profile
>> > across systems as being a deciding factor
I think this is one of those things that aren't worth the effort. Brett's
change was also to fix other bugs, so it wasn't just for this. I'd be
surprised if people spend time to fix bugs solely for this.
On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
> I've heard people proclaim the pri
This is very cool work, it'll especially be useful for outside developers
who don't have our beefy machines :)
Would it be possible to get a sense of what percentage of chrome.dll is due
to our code (i.e. base, net, chrome) vs third party (i.e. everything in
\third_party including webkit)? Perhaps
On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson wrote:
>
> On Mon, Aug 24, 2009 at 12:49 PM, hap 497 wrote:
> > Thanks. But the picture in the document shows there is only 1
> > ResourceDispatcherHost and there are 2 Renderer Processes:
> >
> >
> http://dev.chromium.org/developers/design-documents/
There's one ResourceDispatcherHost for all renderers (but there is one
ResourceMessageFilter per renderer process).
That graph shows a connection between the filter (ResourceMessageFilter) and
the ResourceDispatcherHost, but it's the former that has a pointer to the
latter. RDH doesn't have a list
and such.
>
This gives me an idea: I'll add the time it takes to run presubmit checks to
the output, so we can see how long it's taking.
>
>
> On Thu, Aug 20, 2009 at 11:20 AM, John Abd-El-Malek wrote:
>
>> Great! Please try to add this to an existing check, or do
1 - 100 of 201 matches
Mail list logo
