Re: [webkit-dev] Trouble tracking down flaky test results ...

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 wrote: > I should add ... if I hunt through the raw directories in the results I > can find the *actual* raw output, but it's not linked in via r

Re: [webkit-dev] Trouble tracking down flaky test results ...

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 (http://build.chromium.org/

Re: [webkit-dev] Code Search for webkit.org

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=chromium&q=file%3A%5Esrc/third_party/WebKit Mihai Mihai On Fri, Sep 30, 20

Re: [webkit-dev] Some compile time data

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 Proskuryak

Re: [webkit-dev] UA string changes blog draft

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 Firefo

Re: [webkit-dev] Snow Leopard

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 cyc

Re: [webkit-dev] Trouble with updating Chromium' slayout test expectations

stay green. >> -atw >> >> On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parparita >> wrote: >>> >>> It looks like Drew checked in baselines with >>> http://trac.webkit.org/changeset/79034 (which may be why >>> rebaseline-chromium-webkit-tests isn

Re: [webkit-dev] Trouble with updating Chromium' slayout test expectations

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?

Re: [webkit-dev] Web Inspector blog post draft

For those who are interested in this, I've included the draft inline below. Mihai Web Inspector: Styles Enhanced Posted 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 exp

Re: [webkit-dev] Question regarding priorities of subresource content retrieval

On Mon, Feb 7, 2011 at 12:32 PM, Adam Barth 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 behavior). http://c

Re: [webkit-dev] Blog post(s) about layout tests

manage the doc 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 Deve

[webkit-dev] Blog post(s) about layout tests

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 general/theor

Re: [webkit-dev] How to add a new file to mac build system?

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 wrote: > Thanks for your response. However, even though I changed the build > directory to WebKit/WebKitBuild and

Re: [webkit-dev] Best way to rebaseline 400+ tests?

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 make

Re: [webkit-dev] Leopard Bot has been broken for 5 days.

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 wrote: > I investigated this issue for a while.  Disabling the test just causes > the next test to fail.  I'm not very familiar with this cod

Re: [webkit-dev] New mailling list for buildbot events?

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 wrote: > Interesting. both "warning" and "problem" builds sound useful t

Re: [webkit-dev] Support for CSS3 gradients landed; ports will need minor changes

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 wrote: > I just landed support for CSS3 gradients (see > ), via >

Re: [webkit-dev] Fixing Qt and Chromium builds

Looks like http://trac.webkit.org/changeset/74899 will fix things. Mihai On Mon, Jan 3, 2011 at 9:56 AM, Mihai Parparita 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 wrot

Re: [webkit-dev] Fixing Qt and Chromium builds

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 wrote: > To fix Qt I need to add includes of ExceptionCode.h to two source files. > > To fox Chromium I have to figure out why my code change to not use > defaultChecked

Re: [webkit-dev] Renaming directories

On Tue, Dec 21, 2010 at 6:12 PM, Ryosuke Niwa 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 well here, especi

[webkit-dev] Snow Leopard Pixel Baselines

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 cha

Re: [webkit-dev] Tip: Use 64-bit git binaries on Mac OS X

t version 1.7.3.3), and were 6.0 seconds after. >> > -eric >> > >> > On Wed, Dec 8, 2010 at 2:20 PM, Eric Seidel wrote: >> >> >> >> I've posted a patch to make webkit-patch warn users when they're on a >> 64-bit system with a 32-bi

Re: [webkit-dev] Tip: Use 64-bit git binaries on Mac OS X

Git+OS X > maintainer which combination of settings is the best.  :) > > On Tue, Dec 7, 2010 at 4:14 PM, Eric Seidel wrote: >> Can we evangelize the code.google.com project? >> >> On Dec 7, 2010 4:04 PM, "Mihai Parparita" wrote: >>> After complaining to

[webkit-dev] Tip: Use 64-bit git binaries on Mac OS X

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 box, I decided to look into why this is. As it turns out, most people get git binaries from http://code.google.com/p/git-osx-installer/, which are 32-bit. Switc

Re: [webkit-dev] Rebaselining render tree dumps

On Mon, Dec 6, 2010 at 12:30 PM, David Hyatt 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 lots of pixel ba

Re: [webkit-dev] Pixel output for text/plain responses in layout tests

On Fri, Nov 19, 2010 at 11:19 AM, David Levin 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 one that's affecte

[webkit-dev] Pixel output for text/plain responses in layout 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 special-c

Re: [webkit-dev] Trouble running new-run-webkit-tests

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 wrote: > > I'm trying to generate baselines for a new test, using the command > WebKitTools/Scripts/new-run-webkit-tests --new-baseline > I have pre

Re: [webkit-dev] pixel tests and --tolerance (was Re: Pixel test experiment)

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 wrote: > O

Re: [webkit-dev] Disable sheriffbot bug posts?

Perhaps if they included a link to the bot output (or at least the build permalink for that revision on that bot) they would be more useful (even if they're false positives, they could be checked and rejected that much faster). Mihai On Thu, Sep 23, 2010 at 1:36 PM, Adam Barth wrote: > Hi webkit

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

ai On Tue, Aug 17, 2010 at 3:28 PM, Adam Barth wrote: > On Mon, Aug 16, 2010 at 7:49 PM, Maciej Stachowiak wrote: >> On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote: >>> On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak wrote: >>>> 1) It means the access control

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

like an > issue, we can remove it if we want to, but have found it useful in the > past. > > I agree with Maciej that the current behavior is in many ways better, so I > am not in a rush to change this just to be more spec compliant. > > -Sam > > On Mon, Aug 16, 2010 at 1:5

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

19 AM, Mihai Parparita wrote: > On Fri, Aug 13, 2010 at 9:59 AM, Mihai Parparita > 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 >

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

On Fri, Aug 13, 2010 at 9:59 AM, Mihai Parparita 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 lon

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak 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 an explicit c

[webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

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 JSC

Re: [webkit-dev] Why are we running Sputnik?

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 wrote: > I thought Sputnik came from Microsoft? > > -- Dirk > > On Tue, Aug 10, 2010 at