Looking at the buildbot, there are a bunch of LayoutTests that are
supposed to fail, timeout, or crash, but which actually pass. We
should update our test expectations / close the cooresponding bugs.
I'll do this tomorrow afternoon if no one beats me to it.
Enjoy:
Expected to fail, but passed
Wow, there are even more on Mac:
Expected to fail, but passed (39)
Adam
On Tue, Jul 14, 2009 at 12:38 AM, Adam Barthaba...@chromium.org wrote:
Looking at the buildbot, there are a bunch of LayoutTests that are
supposed to fail, timeout, or crash, but which actually pass. We
should update
https://bugs.webkit.org/show_bug.cgi?id=27187
-- dean
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
On Tue, Jul 14, 2009 at 3:40 AM, Adam Barthaba...@chromium.org wrote:
Wow, there are even more on Mac:
Expected to fail, but passed (39)
If some of those are plugin related, it's because I didn't remember
last night that the --enable-plugins flag I checked in didn't affect
test shell, so many
On Tue, Jul 14, 2009 at 3:38 AM, Adam Barthaba...@chromium.org wrote:
Expected to crash, but passed (9):
LayoutTests/fast/dom/offset-parent-positioned-and-inline.html
LayoutTests/fast/events/message-channel-gc-2.html
LayoutTests/fast/events/message-channel-gc-4.html
On Tue, Jul 14, 2009 at 01:52, Evan Martine...@chromium.org wrote:
I've used it to browse on real hardware; the Beagleboard, an OMAP3
based ARM board with 128MB of RAM.
Wow, impressive. How much do you think multi-process hurts us?
The full story is 128MB of RAM + 128MB of swap on a slow
On Tue, Jul 14, 2009 at 03:09, Craig Schlentercraig.schlen...@gmail.com wrote:
I've mentioned this to Joel off-list but in case anyone else is interested,
I have code that runs background tabs at lower scheduling priorities
on linux.
Thanks. Are you able to post the newer version you
Lets wait a bit before re-enabling tests, but they seem to act happy, unlike
last night. If no one re-enables them, I can do it when I get home around 6
EST.
-- Mohamed Mansour
On Tue, Jul 14, 2009 at 8:24 AM, Amanda Walker ama...@chromium.org wrote:
On Tue, Jul 14, 2009 at 3:38 AM, Adam
On Tue, Jul 14, 2009 at 00:53, Dan Kegeld...@kegel.com wrote:
It'd be nice if users didn't have to do that...
does HTML 5 specify any kind of low power idle state for applications?
Ideally when the screen blanks, we'd want all the apps to go
into some kind of low power state, wouldn't we?
It
I think we should re-enable them ASAP unless there's some good reason why
you want to wait.
J
On Tue, Jul 14, 2009 at 6:32 AM, Mohamed Mansour m...@chromium.org wrote:
Lets wait a bit before re-enabling tests, but they seem to act happy,
unlike last night. If no one re-enables them, I can do
We (the core extensions subteam) typically spec all new APIs and send
them out for comment to the wider team. This helps keep things
consistent and is easier since we are most familiar with the
capabilities of the system.
- a
On Mon, Jul 13, 2009 at 10:25 PM, Darin Fisherda...@chromium.org
On Tue, Jul 14, 2009 at 12:05 PM, Jeremy Orlowjor...@chromium.org wrote:
I think we should re-enable them ASAP unless there's some good reason why
you want to wait.
They've been stable and passing all morning, so that works for me.
--Amanda
I think Aaron's mail makes the point, but just to be clear: before starting
coding any new APIs, please send a rough proposal to Aaron and myself.
We'll put together an API design based on your proposal and then send it
around for broader feedback. Then we'll start looking at the CLs.
Our
On Tue, Jul 14, 2009 at 5:53 AM, Joel Stanley j...@jms.id.au wrote:
So we do this for GIFs. Can anyone tell me if background tabs
re-paint themselves? If not, I'll add it to the TODO.
IIRC renderers don't actually paint until the browser tells them to.
Background renderers may set dirty
On Tue, Jul 14, 2009 at 10:44 AM, Peter Kastingpkast...@google.com wrote:
On Tue, Jul 14, 2009 at 5:53 AM, Joel Stanley j...@jms.id.au wrote:
So we do this for GIFs. Can anyone tell me if background tabs
re-paint themselves? If not, I'll add it to the TODO.
IIRC renderers don't actually
On Tue, Jul 14, 2009 at 3:11 AM, Dean McNamee de...@chromium.org wrote:
https://bugs.webkit.org/show_bug.cgi?id=27187
Maybe the spec needs to change? It seems like the patch moved away from
spec-compliant behavior to match Gecko.
I'm not sure what chromium-dev can do for you on this issue.
We weren't spec compliant:
http://dev.w3.org/html5/spec/Overview.html
The lineTo(x, y) method must do nothing if the context has no subpaths.
On Tue, Jul 14, 2009 at 8:13 PM, Peter Kastingpkast...@chromium.org wrote:
On Tue, Jul 14, 2009 at 3:11 AM, Dean McNamee de...@chromium.org wrote:
On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee de...@chromium.org wrote:
We weren't spec compliant:
http://dev.w3.org/html5/spec/Overview.html
The lineTo(x, y) method must do nothing if the context has no subpaths.
Isn't that what I just said? That the current behavior doesn't match the
My point was the behavior before the patch was wrong. What they did
now is closer, but still wrong.
On Tue, Jul 14, 2009 at 8:22 PM, Peter Kastingpkast...@chromium.org wrote:
On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee de...@chromium.org wrote:
We weren't spec compliant:
Can someone explain the scope of javascript calls available within PAC
files that chrome parses?
What I'm getting at is, can we use the chrome api javascript calls
within PAC files?
Why would you want/need this? First thought is to determine if the
browser is in incognito mode or not, but
I tend to think incognito mode as a personal (and very private) decision.
As a result, I'd tend to prefer that it be very difficult to leak such
status further than absolutely necessary. Allowing your proxy provider to
detect this status seems like a violation of the need to know, but perhaps
On Jul 14, 12:23 pm, Jim Roskind j...@chromium.org wrote:
I tend to think incognito mode as a personal (and very private) decision.
As a result, I'd tend to prefer that it be very difficult to leak such
status further than absolutely necessary.
Any web page that wishes can determine if you
I guess such a function could be used to 'detect' incognito mode in a
forced - PAC environment, ie where the PAC is served by your employer
at work.
My intention was to devise a way to set an alternate proxy server to
use within incognito mode.
Developers have opposed adding proxy configuration
Dear All,
Just a few hours ago, I switched over webkit.gyp to pull the list of
WebCore and JavaScriptCore files from upstream-living
WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi,
respectively.
This change should alleviate a lot of pain for WebKit gardeners and
those landing
And as soon as I took them out, they started failing again. We're reverting.
--Amanda
On Tue, Jul 14, 2009 at 12:08 PM, Amanda Walkerama...@chromium.org wrote:
On Tue, Jul 14, 2009 at 12:05 PM, Jeremy Orlowjor...@chromium.org wrote:
I think we should re-enable them ASAP unless there's some
2009/7/14 Dimitri Glazkov dglaz...@chromium.org:
This change should alleviate a lot of pain for WebKit gardeners and
those landing two-sided patches. In many cases, this will eliminate
the need for two-sided patches.
I owe you a beer then!:)
--
Gilda Radner - Adopted kids are such a pain
I'd leave decisions about the worker related message port tests for drew and
dimich... the feature isn't fully functional yet in chrome (even if they
don't crash and happen to pass and such).
I've been unable to dup the LayoutTests/fast/events/mouseover-mouseout2.html
failure locally and have no
On Tue, Jul 14, 2009 at 1:28 PM, Michael Nordmanmicha...@google.com wrote:
I'd leave decisions about the worker related message port tests for drew and
dimich... the feature isn't fully functional yet in chrome (even if they
don't crash and happen to pass and such).
Seems like we should turn
Hello,
We reached a point where we have too many build slaves and too many users
to get good performance/latency out of our current buildbot waterfall and
console view page.
We've been tweaking the page a lot lately to make it faster to load, but
the number
of new slaves every day, and the
Hi,
This is an invitation to people from Chromium and other browser/
download application makers to collaborate on Metalink.
Metalink has the potential to improve the usability of the Internet at
a large scale, particularly for users in countries with poor Internet
connectivity (but also for
On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org wrote:
The underlying problem with buildbot is the database format, which is just
hundred of
thousand of files on the harddrive, with no seek capability, and the fact
that the
webserver itself is single threaded.
We
On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
Q3: What kind of auto-refresh do we need?
We used to be at 60 secs for a long time, and I changed it a couple of
weeks ago to 90 secs.
No one complained, so I guess this is good. Should we go even higher than
On Tue, Jul 14, 2009 at 2:24 PM, Ant Bryananthonybr...@gmail.com wrote:
This is an invitation to people from Chromium and other browser/
download application makers to collaborate on Metalink.
This sounds pretty cool, but I suspect you know more about what is
needed to make this work than we
I was just thinking... doesn't it have a reverse proxy in front of it?
It could also force content cache time of 60s or even more...
Something like Squid or Varnish.
Oh, and today morning was probably me scraping the logs. :-( Sorry.
On Tue, Jul 14, 2009 at 14:18, Nicolas
If I understand right, simply serving the auto-refresh requests is
substantial? At least for the main page, a reverse in accelerator
mode could turn that into a constant load.
[I'd offer to help, but I don't know what kind of technology we're
talking about, here.]
-scott
On Tue, Jul 14, 2009
What I'm getting at is, can we use the chrome api javascript calls
within PAC files?
The PAC environment does not allow access to any of the chrome extension APIs.
Moreover, both incognito requests and non-incognito requests flow
through the same PAC script instance, so there is no way to
On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin e...@chromium.org wrote:
On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org
wrote:
The underlying problem with buildbot is the database format, which is
just
hundred of
thousand of files on the harddrive, with no seek
On Tue, Jul 14, 2009 at 2:35 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin e...@chromium.org wrote:
On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org
wrote:
The underlying problem with buildbot is the database format,
On Tue, Jul 14, 2009 at 2:35 PM, Nicolas Sylvainnsylv...@chromium.org wrote:
- Get a better machine. It's already running on a dedicated dual quad
core
nehalem server
with 24gb of RAM and 15k rpm drives.
This is absurdly powerful! It should have all the data necessary to
generate
On Tue, Jul 14, 2009 at 2:35 PM, Eric Roman ero...@chromium.org wrote:
Your suggestion of augmenting the PAC enviroment to expose incognito
information could be done, and I am interested to hear more about the
use-cases.
Incognito isn't designed to hide user details from websites (e.g. by
On Tue, Jul 14, 2009 at 2:40 PM, Albert J. Wong
(王重傑)ajw...@chromium.org wrote:
That is pretty nuts. Is it calling fsync or something crazy? Since you
said strace, I'm assmuming linux. In that case, the buffer cache should be
saving you from disk accesses for most everything.
Of course,
On Tue, Jul 14, 2009 at 2:35 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin e...@chromium.org wrote:
On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org
wrote:
It seems to me a caching layer that only ever hit the backend every
I think there's enough of us that it'd be cheaper to just buy him a keg
together. :-)
On Tue, Jul 14, 2009 at 1:06 PM, Michelangelo De Simone
micde...@gmail.comwrote:
2009/7/14 Dimitri Glazkov dglaz...@chromium.org:
This change should alleviate a lot of pain for WebKit gardeners and
On Tue, Jul 14, 2009 at 2:42 PM, Adam Langley a...@chromium.org wrote:
On Tue, Jul 14, 2009 at 2:40 PM, Albert J. Wong
(王重傑)ajw...@chromium.org wrote:
That is pretty nuts. Is it calling fsync or something crazy? Since you
said strace, I'm assmuming linux. In that case, the buffer cache
On Tue, Jul 14, 2009 at 3:34 PM, Peter O'Brienpeter.j.obr...@gmail.com wrote:
The PAC environment does not allow access to any of the chrome extension
APIs.
Thanks for the clarification.
Your suggestion of augmenting the PAC enviroment to expose incognito
information could be done, and I
I would like to see auto refresh turned off by default. That might help the
load.
-- Mohamed Mansour
On Tue, Jul 14, 2009 at 7:15 PM, Michael Nordman micha...@google.comwrote:
Turning off auto refresh by default sounds reasonable idea right now...
with an option to enable it if really
On Tue, Jul 14, 2009 at 5:48 PM, Drew Wilson atwil...@google.com wrote:
I would actually have expected the normal (non-worker) MessagePort tests to
pass/not-crash, as I don't think that jam has gotten far enough into the
implementation to break the non-cross-process versions :)
I have a work
* If you update your google-chrome-unstable packages and your
development builds start hanging, sync to = 20710 *
Details:
The latest google-chrome packages contain a sandbox binary, which the
development builds of chromium will pick up on automatically. However,
for safety reasons, the sandbox
On Tue, Jul 14, 2009 at 7:12 PM, Adam Langley a...@chromium.org wrote:
* If you update your google-chrome-unstable packages and your
development builds start hanging, sync to = 20710 *
Details:
The latest google-chrome packages contain a sandbox binary, which the
development builds of
On Tue, Jul 14, 2009 at 8:09 PM, Jeremy Orlowjor...@chromium.org wrote:
Also, will the try bots and build bots run with the sandbox on?
No, the build-bots currently run without a sandbox. I agree this
should probably be changed and it's on my TODO list. Unfortunately,
it's a very long list
On Tue, Jul 14, 2009 at 8:14 PM, Antoine Labourpi...@google.com wrote:
Does this part need to be sticky, or is it just to build the
chrome-devel-sandbox ? If the former it is going to be painful.
You only need to build and install it once.
AGL
On Tue, Jul 14, 2009 at 8:19 PM, Adam Langley a...@chromium.org wrote:
On Tue, Jul 14, 2009 at 8:14 PM, Antoine Labourpi...@google.com wrote:
Does this part need to be sticky, or is it just to build the
chrome-devel-sandbox ? If the former it is going to be painful.
You only need to build
On Tue, Jul 14, 2009 at 8:21 PM, Antoine Labourpi...@google.com wrote:
I meant the change in common.gpyi. Once I built the chrome-devel-sandbox I
can revert that file, right ?
Yes.
AGL
--~--~-~--~~~---~--~~
Chromium Developers mailing list:
On Wed, Jul 15, 2009 at 02:12, Adam Langleya...@chromium.org wrote:
* build chrome_sandbox
I think the defines got messed up somewhere...
http://codereview.chromium.org/149667 fixes it for me.
Joel
--~--~-~--~~~---~--~~
Chromium Developers mailing list:
Right now there's a bunch of unexpected passing media layout tests, but they
should start failing again as soon as the WebKit builder bot is clobbered
(we're temporarily expecting them to fail until we sort out some issues).
Andrew
On Tue, Jul 14, 2009 at 5:50 PM, Drew Wilson
On Tue, Jul 14, 2009 at 8:50 PM, Joel Stanleyj...@jms.id.au wrote:
I think the defines got messed up somewhere...
Crap, yes. Thanks for that. Fixed.
AGL
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives,
56 matches
Mail list logo
