(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
The popup blocker might interfere with that, but even if it doesn't, it
seems
unsavory to reveal these navigations to an existing page. (The page could
override and intercept the 'open' method.)
I think for parity with other apps, we should provide a command line switch
to force the
We will. It's on my plate and TVL's. We did have some hardware
slated to use for this, but we've slowly chipped away at that, so
it'll come out of the next batch. Bringing up the 10.6 bots had to
take a back seat to the other things that we needed to do in the beta
run-up, but 10.6 bots are a
Why do we need to provide parity with other apps?
Do you understand how bloated we will become if we extend this to every
feature someone likes?
-Ben
On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher da...@chromium.org wrote:
The popup blocker might interfere with that, but even if it doesn't,
Sounds great. Thanks,
-Darin
On Mon, Dec 14, 2009 at 10:38 AM, Mark Mentovai m...@chromium.org wrote:
We will. It's on my plate and TVL's. We did have some hardware
slated to use for this, but we've slowly chipped away at that, so
it'll come out of the next batch. Bringing up the 10.6
Ah, OK in that case it sounds fine.
-Ben
On Mon, Dec 14, 2009 at 10:48 AM, Darin Fisher da...@chromium.org wrote:
This was explained by Mike Mammarella above.
-Darin
On Mon, Dec 14, 2009 at 10:46 AM, Ben Goodger (Google)
b...@chromium.orgwrote:
What does proper desktop integration
Hi Antoine,
I did exactly what you said-- not set armv7=1 in gyp_defines.
export GYP_DEFINES=target_arch=arm
sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
disable_nacl=1 use_system_ffmpeg=1
I rebuilt chromium.
And then I reset my kernel so that it does not use
On Mon, Dec 14, 2009 at 10:42 AM, Drew Wilson atwil...@chromium.org 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
OK, thanks for the clarification. I'll starting whinging at people who
disable tests without a comment pointing at an associated bug.
-atw
On Mon, Dec 14, 2009 at 10:52 AM, Darin Fisher da...@chromium.org wrote:
On Mon, Dec 14, 2009 at 10:42 AM, Drew Wilson atwil...@chromium.orgwrote:
Since I just excluded a lot of tests in valgrind last week, I'd like to give
a background here.
About a week ago, we noticed that we're ignoring failing tests in our
valgrind tests, which means
that the test results are not accurate. Even worse, unit test of
valgrind/test was crashing in the
Automatically closing tree for compile on Chromium Builder
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/20346
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder
--= Automatically closing tree for compile on Chromium Builder =--
On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher da...@chromium.org wrote:
I think for parity with other apps, we should provide a command line switch
to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
we could expose other dispositions.
Given mdm's explanation, I agree. And
On Mon, Dec 14, 2009 at 10:55 AM, Ojan Vafai o...@google.com wrote:
On Mon, Dec 14, 2009 at 10:36 AM, David Levin le...@chromium.org wrote:
On Mon, Dec 14, 2009 at 10:24 AM, Scott Hess sh...@chromium.org wrote:
Also, last time I was looking through some valgrind suppressions, I
found that
On Mon, Dec 14, 2009 at 10:51 AM, Sofia Tahseen sofia.tahs...@gmail.comwrote:
Hi Antoine,
I did exactly what you said-- not set armv7=1 in gyp_defines.
export GYP_DEFINES=target_arch=arm
sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
disable_nacl=1
2009/12/14 Sofia Tahseen sofia.tahs...@gmail.com
Hi Antoine,
I did exactly what you said-- not set armv7=1 in gyp_defines.
export GYP_DEFINES=target_arch=arm
sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
disable_nacl=1 use_system_ffmpeg=1
I rebuilt
On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson atwil...@chromium.org wrote:
Anyhow, what's our best practices for disabling tests? I think ideally we'd
always log a tracking bug and add a comment, akin to what we do in the
test_expectations file for layout tests.
Another point to keep in mind -
On Mon, Dec 14, 2009 at 12:02 PM, Tony Chang wrote:
I have considered the possibility of moving the resources on Windows out of
chrome.dll. I made a change a few weeks back that moved theme resources
into chrome.dll and there was no noticeable change on the bots. I imagine
moving them back
Yes it was erroring out at the same point S32A_Opaque_BlitRow32_neon...but I
had not done gclient runhooks --force...Now I am re-doing it...Lets wait and
see how this works.
On Mon, Dec 14, 2009 at 1:07 PM, Erik Corry erik.co...@gmail.com wrote:
2009/12/14 Sofia Tahseen
Anyhow, what's our best practices for disabling tests? I think ideally we'd
always log a tracking bug and add a comment, akin to what we do in the
test_expectations file for layout tests. This might be too much of a burden
on sheriffs, so an alternative is for people who are working on
If you're using the safesync URL
http://build.chromium.org/buildbot/continuous/LATEST/REVISION in
your .gclient file, your gclient sync command should be failing
now.
This is because the URL has been replaced by three platform-specific
URLs:
UI Jank Task Force Status Update
Last meeting until 2010.
*Status*
Carlos
-
Keep trying to build PGO. Trying to build just a part of Chrome
(instrument just the ‘browser’ project) to get around the problem.
Chase
-
Tab switching tests problem resolved; re-enabled. Cause is
On Mon, Dec 14, 2009 at 1:30 PM, Sofia Tahseen sofia.tahs...@gmail.comwrote:
Hi Antoine/All,
This is what I did:
export GYP_DEFINES=target_arch=arm
sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
disable_nacl=1 use_system_ffmpeg=1
gclient runhooks --force
I'm in the process of writing a bookmark manager in HTML. So far I've
written it as an extension but I'm now considering changing this to a
DOM UI page instead. [*]
I would like to be able to expose the extensions API for bookmarks to
the DOM UI (and eventually make all DOM UI pages use extension
On Mon, Dec 14, 2009 at 11:06 AM, Peter Kasting pkast...@google.com wrote:
On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher da...@chromium.org wrote:
I think for parity with other apps, we should provide a command line
switch
to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
On Mon, Dec 14, 2009 at 4:34 PM, Evan Stade est...@chromium.org wrote:
I think adding a --disposition= field is overkill and will be harder to
maintain (which is the worst part about command line flags). If a new
disposition is added to webkit, one is renamed, or one is deleted, are you
On Mon, Dec 14, 2009 at 4:43 PM, Peter Kasting pkast...@google.com wrote:
On Mon, Dec 14, 2009 at 4:34 PM, Evan Stade est...@chromium.org wrote:
I think adding a --disposition= field is overkill and will be harder to
maintain (which is the worst part about command line flags). If a new
+chromium-dev
I don't think having a third mode makes sense. We should have terse
(default) and verbose (--verbose). One is for running locally and one is for
the bots. Having the flexibility of the --log option is fine, but we should
pick a default for terse mode that most people are happy with.
Seems like a bad idea.
Extensions and DOMUI are basically two competing systems for doing the
same thing, it would get confusing combining them. I would rather
either:
a) add new (possibly experimental) APIs for the issues you've run into.
b) manually plumb the extension APIs you need through
On Mon, Dec 14, 2009 at 4:47 PM, Evan Stade est...@chromium.org wrote:
we have had a lot of bug reports asking for NEW_WINDOW, but none for these
two dispositions. What use cases do you envisage?
Wanting to open pages in either of these ways? Firefox used to have options
to control this and
OK. Dirk and I talked offline and we came to this conclusion:
We default to --log detailed-progress,unexpected. For now,
detailed-progress does nothing if --experimental-fully-parallel isn't also
specified. If it is also specified, then it logs directories + dots a la
upstream webkit. In a
Layout Tests Task Force meeting notes 12/14/2009
*
*
AI for jeffreyc/dglazkov: We will be sending out a spreadsheet tomorrow with
general future areas of work that folks can sign up for.
LTTF and Beyond
Next steps:
- Fix or triage remaining failures (short-term)
- Drain the finders
On Mon, Dec 14, 2009 at 16:48, Aaron Boodman a...@chromium.org wrote:
Seems like a bad idea.
Extensions and DOMUI are basically two competing systems for doing the
same thing, it would get confusing combining them. I would rather
either:
a) add new (possibly experimental) APIs for the
On Mon, Dec 14, 2009 at 5:29 PM, Erik Arvidsson a...@chromium.org wrote:
On Mon, Dec 14, 2009 at 16:48, Aaron Boodman a...@chromium.org wrote:
Seems like a bad idea.
Extensions and DOMUI are basically two competing systems for doing the
same thing, it would get confusing combining them. I
On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman a...@chromium.org wrote:
Seems like a bad idea.
Extensions and DOMUI are basically two competing systems for doing the
same thing, it would get confusing combining them.
While I can see this in principle, I'm not sure I see what the problems
I've gone through and gardened the bugs per our goals for stable:
Win, linux: http://bit.ly/5s4lrp
Mac: http://bit.ly/8hHpdO
Surely I'm missing some, but this should be a start.
- a
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or
There have been some changes to the ffmpeg.gyp file recently. Dominic makes
a good point that the GYP_DEFINES will make a large difference.
Thiago, what GYP_DEFINES do you have set?
Note that ffmpeg_asm is not a build dependency. It's a target in the
ffmpeg.gyp file that must somehow be
2009/12/10 John Abd-El-Malek j...@chromium.org
On Thu, Dec 10, 2009 at 1:22 PM, Evan Stade est...@chromium.org wrote:
On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.comwrote:
On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.orgwrote:
In essence:
return
Building Chromium for Chromium OS now depends on libpam0g-dev.
cheers,
cmasone
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
38 matches
Mail list logo
