I will investigate this today.
On Thu, Sep 3, 2009 at 4:29 AM, James Hawkinsjhawk...@chromium.org wrote:
No, and it's only invoked during tab dragging.
On Wed, Sep 2, 2009 at 7:20 PM, Michael Nordmanmicha...@google.com wrote:
There's is nothing platform specific about r25099, since other
After a talk with jcampan I think that the plan is to convert all the
interactive_ui_tests to browser_tests and make the test launcher reusable.
On Wed, Sep 2, 2009 at 12:27, Scott Violet s...@chromium.org wrote:
If we can't mix the two types, then separate targets is going to be
the only way
Ug, I can't reproduce this on my desktop. If I had to take a guess, I
would guess Brett's gfx::Font change.
TOT:
*RESULT warm: t=
[134.82,133.98,135.04,134.37,134.95,135.01,134.78,134.69,134.55,134.21,134.27,137.12,134.31,134.20,134.56,135.37,135.02,134.68,134.22,134.58,]
ms
r25120:
*RESULT
Quick update: Apple has confirms on the Xcode mailing list they are working
on the issue.
TVL
On Mon, Aug 31, 2009 at 2:44 PM, Thomas Van Lenten thoma...@chromium.orgwrote:
Just a quick heads up, if you are building on 10.6 with Xcode 3.2, you
might hit some hiccups with distributed builds.
You need AutomationProxy for that. See the line
server_.reset(CreateAutomationProxy(command_execution_timeout_ms_));
Please keep the discussion on the list. And I'll repeat my question: what is
your goal? I might guess that you are trying to re-use the browser between
test runs. It may be a bad
On Thu, Sep 3, 2009 at 9:33 AM, Brett Wilsonbre...@chromium.org wrote:
On Thu, Sep 3, 2009 at 9:26 AM, Evan Martine...@chromium.org wrote:
Ok, I'll mark that I own this here and unassign it if I can't figure it out:
http://code.google.com/p/chromium/issues/detail?id=20991
On Thu, Sep 3, 2009
Should we be archiving perf tests so we can backtrack these
regressions more easily? For instance, Windows archives some tests
(e.g. http://build.chromium.org/buildbot/continuous/LATEST/chrome-win32.test/),
though startup isn't one of them.
Michael
On Thu, Sep 3, 2009 at 9:47 AM, Michael
Ok, I'll mark that I own this here and unassign it if I can't figure it out:
http://code.google.com/p/chromium/issues/detail?id=20991
On Thu, Sep 3, 2009 at 2:41 AM, Dean McNameede...@chromium.org wrote:
Ug, I can't reproduce this on my desktop. If I had to take a guess, I
would guess Brett's
On Thu, Sep 3, 2009 at 9:26 AM, Evan Martine...@chromium.org wrote:
Ok, I'll mark that I own this here and unassign it if I can't figure it out:
http://code.google.com/p/chromium/issues/detail?id=20991
On Thu, Sep 3, 2009 at 2:41 AM, Dean McNameede...@chromium.org wrote:
Ug, I can't
I feel a couple of people have written scripts to bisect builds pulled
from http://build.chromium.org/buildbot/continuous/ .
Can we check one of those in? I can review.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View
Looks like we have a leak in render_thread_unittest.cc :
http://build.chromium.org/buildbot/waterfall/builders/XP%20Unit%20(purify)/builds/5386/steps/purify%20test:%20unit/logs/stdio
There are several distinct stacks, but most boil down to this allocation:
ipc/ipc_sync_channel.cc:347
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,
There's already this one that I know of:
http://code.google.com/p/chromium/issues/detail?id=20703, there may be
others.
On Thu, Sep 3, 2009 at 11:11 AM, Antony Sargent asarg...@google.com wrote:
In that case I think I'll just put a bug in for these and add a suppression
to get the tree green.
In that case I think I'll just put a bug in for these and add a suppression
to get the tree green.
Thanks.
On Thu, Sep 3, 2009 at 10:53 AM, John Abd-El-Malek j...@chromium.org wrote:
These leaks have always existed in the unit tests. They don't happen in
Chrome builds since the posted tasks
On Thu, Sep 3, 2009 at 9:33 AM, Brett Wilsonbre...@chromium.org wrote:
On Thu, Sep 3, 2009 at 9:26 AM, Evan Martine...@chromium.org wrote:
Ok, I'll mark that I own this here and unassign it if I can't figure it out:
http://code.google.com/p/chromium/issues/detail?id=20991
On Thu, Sep 3, 2009
I've heard a few complains of I cannot bisect because the archive
does not go that far back.
Are we tight on storage? It would be nice if we can keep more of the
continuous builds around.
On Thu, Sep 3, 2009 at 10:30 AM, Evan Martine...@chromium.org wrote:
I feel a couple of people have
On Thu, Sep 3, 2009 at 11:50 AM, Evan Martine...@chromium.org wrote:
It could be my font change. It does measure some extra text on
startup. But I would have thought this was nothing compared to the
text we already measure.
Bad news: here's the graph after I reverted your change.
From IRC, nsylvain says we keep at least one green build a day forever.
So the archive *should* go back far enough, but with less resolution
in ancient history.
PS: I also learned that among buildbot archives, snapshot = every
build, while continuous = every *green* build.
On Thu, Sep 3, 2009
Yeah, I don't know what the purge policy is, but currently we have
complete build snapshots going back about 2 months:
http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/
On Thu, Sep 3, 2009 at 11:55 AM, Evan Martine...@chromium.org wrote:
From IRC, nsylvain says we keep at least
Actively tracing through DumpRenderTree in WebCore. Getting layout info and
pixels that show I'm in the right file, and the png has scrollbars. But I
can't get gdb to break on ScrollbarThemeMac::paint and putting everything
from Debugger() to asm(int3) as the first statement in it isn't catching.
If anyone has concerns, please speak up within the next few minutes.
M-A
On Thu, Sep 3, 2009 at 12:51 PM, mar...@chromium.org wrote:
Reviewers: Nicolas Sylvain,
Message:
Depending on the compile time difference on Chromium XP, I'll choose to
either (selectively or totally) revert the patch
Thank you.
My goal is to remote control (e.g. load an url) a running instance of browser.
That is why I am trying to run this AutomationProxyTest NavigateToURL
to an running instance of browser.
That is why I ask how can I run the 'TEST_F(AutomationProxyTest,
NavigateToURL) '
Test case in
On Thu, Sep 3, 2009 at 1:58 PM, fin...@chromium.org wrote:
Author: fin...@chromium.org
Date: Thu Sep 3 13:58:01 2009
New Revision: 25367
Log:
Fix 9867: Activating the previous/next buttons with the keyboard in the find
bar should not change the focus.
Add param const Event event to
Ah, ok. I'll clean this up in a followup CL. I'll get on it right away.
Thanks for the tip!
On Thu, Sep 3, 2009 at 14:24, James Hawkins jhawk...@chromium.org wrote:
On Thu, Sep 3, 2009 at 1:58 PM, fin...@chromium.org wrote:
Author: fin...@chromium.org
Date: Thu Sep 3 13:58:01 2009
New
Then probably you should just use AutomationProxy (directly, without UI test
framework). Adapting tests would be harder - just build a small driver
program to launch the browser in a similar way UI test does, and uses the
AutomationProxy to send it NavigateToURL message. You may also want to take
WebKit's is:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/bisect-builds
Maybe there is code to share there? Or with a fancier python one from
Chromium we can replace that old perl thing.
-eric
On Thu, Sep 3, 2009 at 6:30 PM, Evan Martin e...@chromium.org wrote:
I feel a couple
Robert Sesek nicely checked his in at build/build-bisect.py.
It's mac-specific for now, but the next time you need to bisect builds
on another platform I suggest improving it.
On Thu, Sep 3, 2009 at 10:30 AM, Evan Martine...@chromium.org wrote:
I feel a couple of people have written scripts to
Problem:
People rubber stamp or TBR rebaselines instead of doing normal reviews,
because they are hard to review, due to lack of detailed knowledge about why
they are being rebaselined. This is causing bad baselines to be checked in,
which leads to layout test failures, which leads to sadness.
On Thu, Sep 3, 2009 at 4:40 PM, Julie Parent jpar...@chromium.org wrote:
Real examples I ran into in the past 2 days:
- Failing tests because the baseline checked in is for an error page,
and we generate real results. Glancing at the diff should have caught
this:
The flakiness with resources has hugely decreased since I landed my infamous
hook, but it's still there.
I'm not sure what really happens, so I'm thinking about a special build step
(before UI tests etc), which would verify that all the expected resources
are present in the bundle and then fail.
Hi Pawel,
I'm in the process of landing a change which will add grit_info.py, which
will let you list all of the inputs and outputs from a .grd file.
Initially I'll be using the inputs to fix some of the dependencies. Does
this cover your concerns?
http://codereview.chromium.org/197007/show
Seems good. Nice job! I hope it will eradicate this kind of flakiness.
On Thu, Sep 3, 2009 at 17:37, Bradley Nelson bradnel...@google.com wrote:
Hi Pawel,
I'm in the process of landing a change which will add grit_info.py, which
will let you list all of the inputs and outputs from a .grd
Right now we have this manifest key for plugins: plugins: [ {path:
path/to/file, public: true}
]
This won't work well for cross platform extensions. Here's a simple addition
to address that:
plugins: [
{
platform_paths: [
{winxp: plug_xp.dll}, {winvista: plug_vista.dll}, {linux:
libplug_linux.so},
On Thu, Sep 3, 2009 at 9:08 PM, Adam Barthaba...@chromium.org wrote:
On Thu, Sep 3, 2009 at 7:51 PM, Matt Perrympcompl...@chromium.org wrote:
public: false,
Does that mean the default is now true? It's probably a good idea to
make the default value false here.
The default is currently
Sorry for being late to the party, but I don't understand why this is the
best solution to the problem. Why not just have a gyp variable to disable
precompiled headers and then set that variable in the ~/.gyp/include.gypi
file on the try bots?
This should be an easy thing to do since we already
35 matches
Mail list logo
