The test is logged as having failed:
2012-01-20 13:31:01,307 914 worker.py:180 DEBUG worker/9
compositing/geometry/limit-layer-bounds-transformed-overflow.html
failed:
2012-01-20 13:31:01,307 914 worker.py:182 DEBUG worker/9 Text diff mismatch
And the results zip file
results.html only links unexpected failures, and this is an expected
failure on Snow Leopard.
Mihai
On Tue, Jan 24, 2012 at 10:02 AM, W. James MacLean
wjmacl...@chromium.orgwrote:
I should add ... if I hunt through the raw directories in the results I
can find the *actual* raw output, but
I usually search the copy of WebKit that's in the Chromium sub-index of code
search. It's at most one day behind ToT WebKit (plus Code Search
crawl/indexing delays):
http://www.google.com/codesearch#search/exact_package=chromiumq=file%3A%5Esrc/third_party/WebKit
Mihai
Mihai
On Fri, Sep 30,
Somewhat related to all this, if you'd like to keep an eye on your Xcode
build times, you can use:
$ defaults write com.apple.Xcode ShowBuildOperationDuration YES
To have the build time show up in the status bar (at least with Xcode 3.x).
Mihai
On Mon, Apr 25, 2011 at 7:51 PM, Alexey
Hi Peter,
I think you should say User Agent String in the title and maybe in
the first paragraph say User Agent (UA) string, so that it's not
quite as cryptic.
The inline URLs are a bit ugly, perhaps some changes could be turned
into a link to the tracking bug and similar changes in Firefox 4
It looks like Drew checked in baselines with
http://trac.webkit.org/changeset/79034 (which may be why
rebaseline-chromium-webkit-tests isn't doing anything, since it
already has correct pixel baselines), but given
http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew,
any ideas why?
, 2011 at 6:46 AM, Mihai Parparita mih...@chromium.org
wrote:
It looks like Drew checked in baselines with
http://trac.webkit.org/changeset/79034 (which may be why
rebaseline-chromium-webkit-tests isn't doing anything, since it
already has correct pixel baselines), but given
http://trac.webkit.org
The SL bot is now green
(http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Tests)),
ever since http://trac.webkit.org/changeset/79390 rolled out a change
that resulted in all layout tests are crashing on Snow Leopard per
the comment. It doesn't look like the cq has done a full
For those who are interested in this, I've included the draft inline below.
Mihai
Web Inspector: Styles Enhanced http://webkit.org/blog/?p=1463Posted
by *Alexander
Pavlov* on Wednesday, February 9th, 2011 at 9:43 am
During the past months, we’ve been working hard to improve the CSS editing
On Mon, Feb 7, 2011 at 12:32 PM, Adam Barth aba...@webkit.org wrote:
There is no PerformanceTest framework that deals with network latency.
Please feel encouraged to build one. :)
Note that http://code.google.com/p/web-page-replay/ was created with
this goal (to simulate realistic network
and people find it…
Thanks,
Song
*From:* webkit-dev-boun...@lists.webkit.org [mailto:
webkit-dev-boun...@lists.webkit.org] *On Behalf Of *ext Mihai Parparita
*Sent:* Wednesday, January 26, 2011 10:24 AM
*To:* WebKit Development
*Subject:* [webkit-dev] Blog post(s) about layout tests
You should also make sur that you're doing the same kind of build (i.e.
debug vs. release) on both the command-line and in Xcode.
Mihai
On Tue, Jan 25, 2011 at 12:18 AM, Won J Jeon wjj...@gmail.com wrote:
Thanks for your response. However, even though I changed the build
directory to
I noticed that we haven't done any posts on the WebKit blog about layout
tests. Since getting good reductions in bug reports is very helpful, it
seems like educating web developers about how we test things is helpful.
I've written a draft pair of posts that talk about layout tests in
The rebaseline server is checked in.
https://trac.webkit.org/wiki/RebaselineServer has instructions on how
to use it, please let me know if anything is unclear.
Right now it only works well with local layout test results. I have a
patch up at https://bugs.webkit.org/show_bug.cgi?id=52039 that
If this is the same as http://webkit.org/b/51807, then it's actually
been broken for a couple of weeks.
Mihai
On Tue, Jan 18, 2011 at 10:12 PM, Adam Barth aba...@webkit.org wrote:
I investigated this issue for a while. Disabling the test just causes
the next test to fail. I'm not very
I'm not sure which category purple bots fall into, but getting notified
about those would be useful (e.g. for the Chromium bots that Dimitri, James
and I try to keep up).
Mihai
On Thu, Jan 13, 2011 at 7:29 PM, Eric Seidel e...@webkit.org wrote:
Interesting. both warning and problem builds
Looks like http://trac.webkit.org/changeset/74899 will fix things.
Mihai
On Mon, Jan 3, 2011 at 9:56 AM, Mihai Parparita mih...@chromium.org wrote:
I'm Chromium gardener, and I'll take a look at the Chromium compile errors.
Mihai
On Mon, Jan 3, 2011 at 9:46 AM, Darin Adler da...@apple.com
I've filed https://bugs.webkit.org/show_bug.cgi?id=51841 about making
the change for Chromium/Skia.
Mihai
On Mon, Jan 3, 2011 at 11:45 AM, Simon Fraser simon.fra...@apple.com wrote:
I just landed support for CSS3 gradients (see
http://dev.w3.org/csswg/css3-images/#gradients), via
On Tue, Dec 21, 2010 at 6:12 PM, Ryosuke Niwa rn...@webkit.org wrote:
Why don't we do this as we change the format of render tree dumps. We can
remove expected tests from LayoutTests, move tests to RegressionTests with
new expected results.
I don't think an incremental migration will work
James Robinson and I* have been working on updating the pixel
baselines in platform/mac so that they pass on Snow Leopard (we've
been moving existing baselines to platform/mac-leopard so that things
still work on Leopard too). Having up to date pixel baselines is
helpful when making layout code
on disk
during operation), so this means a savings of 12 seconds on your machine!
-eric
On Tue, Dec 7, 2010 at 4:04 PM, Mihai Parparita mih...@chromium.org
wrote:
After complaining to a Linux-using friend for the n-th time that git
status was much slower on my Snow Leopard machine than
:14 PM, Eric Seidel e...@webkit.org wrote:
Can we evangelize the code.google.com project?
On Dec 7, 2010 4:04 PM, Mihai Parparita mih...@chromium.org wrote:
After complaining to a Linux-using friend for the n-th time that git
status was much slower on my Snow Leopard machine than on his Linux
On Mon, Dec 6, 2010 at 12:30 PM, David Hyatt hy...@apple.com wrote:
What do people think of this idea? How can we make sure that a rebaselining
like this goes smoothly?
I think this is a great idea.
As far as how to do this, prompted by the Leopard - Snow Leopard
switch (which is causing
A workaround until this is fixed is to pass --release (or --debug as
appropriate) to NRWT.
Mihai
On Fri, Nov 19, 2010 at 7:47 AM, W. James MacLean
wjmacl...@chromium.org wrote:
I'm trying to generate baselines for a new test, using the command
WebKitTools/Scripts/new-run-webkit-tests
I've been working on updating pixel baselines for Snow Leopard, and
ran into a test that fails due to missing pixel baselines
(http/tests/incremental/slow-utf8-text.pl) and was surprised how we
ever passed this test.
As it turns out, this test just outputs a text/plain response, which
is
On Fri, Nov 19, 2010 at 11:19 AM, David Levin le...@chromium.org wrote:
Would you figure out which tests would be affected by this change? And then
reply with that list of tests.
As best as I can tell, the test that I originally mentioned
(http/tests/incremental/slow-utf8-text.pl) is the only
FWIW, I needed NRWT to support --tolerance for something else today
(mainly because when using it with the Mac port, it defaults to 0.1
tolerance, with no way to override it), so I added NRWT support for
it: http://webkit.org/b/47959.
Mihai
On Thu, Oct 14, 2010 at 2:44 PM, Dirk Pranke
Barth aba...@webkit.org wrote:
On Mon, Aug 16, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote:
On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak m...@apple.com wrote:
1) It means the access control goes in fewer places - we don't
, Mihai Parparita mih...@chromium.orgwrote:
On Fri, Aug 13, 2010 at 9:59 AM, Mihai Parparita mih...@chromium.org
wrote:
I've asked Joseph (the original reporter of http://crbug.com/17325)
where he ran into this.
Joseph replied and said While there is a proprietary web app that
relies
On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak m...@apple.com wrote:
1) It means the access control goes in fewer places - we don't have to have
access control on every document property, only window properties.
I'm not quite sure I understand this. At least for the location
object, I see
On Fri, Aug 13, 2010 at 9:59 AM, Mihai Parparita mih...@chromium.org wrote:
I've asked Joseph (the original reporter of http://crbug.com/17325)
where he ran into this.
Joseph replied and said While there is a proprietary web app that
relies on this, but it is used at a small company I no longer
I was wondering if it would be a reasonable change to make accessing
location.href (and other location properties) throw SECURITY_ERR when
accessed across origins (https://webkit.org/b/43504). This initially was
reported on the Chrome side (http://crbug.com/17325), but it looks like
neither the
Nope, it's from Chromium:
http://blog.chromium.org/2009/06/launching-sputnik-into-orbit.html
http://blog.chromium.org/2010/03/does-your-browser-behave.html
Mihai
On Tue, Aug 10, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote:
I thought Sputnik came from Microsoft?
-- Dirk
On Tue,
33 matches
Mail list logo
