Re: [webkit-dev] EditBugs permission

Hi Eric, I've asked for EditBugs permission on this mailing list before, but got no replies, so I"m afraid this is a good chance to ask again. :) Thanks! > -Original Message- > From: webkit-dev-boun...@lists.webkit.org > [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Eric Sei

Re: [webkit-dev] EditBugs permission

Hi, to keep the thread count low, I'll borrow this one and request for the EditBugs permission myself. The email address is zandober...@gmail.com Thanks in advance! On Fri, Apr 13, 2012 at 12:47 AM, Eric Seidel wrote: > Done. > > % webkit-patch add-users-to-groups shezbaig...@gmail.com > Add u

Re: [webkit-dev] Feature Announcement: Link Prerendering API

On Thu, Apr 12, 2012 at 9:37 PM, Ryosuke Niwa wrote: > 2012/4/12 Gavin Peters (蓋文彼德斯) > > I'd also like to ask specifically for guidance from reviewers, especially >> on ports other than Chromium, about how to handle the new files in WebCore >> that are part of the Link Prerendering API. Should

Re: [webkit-dev] Feature Announcement: Link Prerendering API

2012/4/12 Gavin Peters (蓋文彼德斯) > I'd also like to ask specifically for guidance from reviewers, especially > on ports other than Chromium, about how to handle the new files in WebCore > that are part of the Link Prerendering API. Should I add them to other > ports build files? > We most certain

Re: [webkit-dev] Feature Announcement: Link Prerendering API

I'd also like to ask specifically for guidance from reviewers, especially on ports other than Chromium, about how to handle the new files in WebCore that are part of the Link Prerendering API. Should I add them to other ports build files? The new files in WebCore that are only important to ports

[webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[This is actually an enhancement announcement to an existing feature] Over at , Edward O’Connor has proposed enhancements to CanvasRenderingContext2D to allow authors to take full advantage of high-resolution backing st

[webkit-dev] Dfg phase.

Hi. I have some questions about methods: Can you tell me how take constants, variables in different vectors for each functions ? Thanks a lot ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] EditBugs permission

Done. % webkit-patch add-users-to-groups shezbaig...@gmail.com Add users matching "shezbaig...@gmail.com" which groups? 1. canconfirm 2. editbugs Enter one or more numbers (comma-separated), or "all": Reading Keychain for bugs.webkit.org account and password. Click "Allow" to continue... Loggin

[webkit-dev] EditBugs permission

Hello, When I submit a patch to bugzilla, I get an error that EditBugs is not set on my account. Can someone add this permission to my bugzilla account please? I sent a message to as instructed, but that doesn't get through. My login is: shezbaig...@gmail.com My patch submitted to: https://bug

[webkit-dev] Feature Announcement: Link Prerendering API

Link Prerendering is a feature of chromium to load entire web pages ahead of navigation. The feature has been enabled in our release branch for some time, and prerender links are found on many web sites, and are emitted by Google Web Search for first results sometimes. To learn more about prerend

Re: [webkit-dev] CMake for Apple's Windows port

On 2012-04-12, at 14:28, Dirk Pranke wrote: > > On Apr 12, 2012 1:17 PM, "Mark Rowe" wrote: > > > > > > On 2012-04-12, at 12:08, Adam Treat wrote: > > > > > If my memory serves me the problem was that Apple couldn't figure out how > > > to get cmake installed on the Apple build system machin

[webkit-dev] Fwd: Is converting pixel tests to reftests kosher for imported libraries?

-- Forwarded message -- From: James Graham Date: Thu, Apr 12, 2012 at 2:17 PM Subject: Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries? To: Ryosuke Niwa Cc: webkit-dev@lists.webkit.org, Ms2ger , Ehsan Akhgari < eh...@mozilla.com>, James Graham

Re: [webkit-dev] Handling failing reftests

On Apr 12, 2012 2:25 PM, "Ojan Vafai" wrote: > > On Thu, Apr 12, 2012 at 2:18 PM, Dirk Pranke wrote: >> >> On Apr 12, 2012 1:53 PM, "Ryosuke Niwa" wrote: >> > >> > My suggestion is to try to make it platform-independent but it's significantly harder than rebaselining the results for pixel tests.

Re: [webkit-dev] CMake for Apple's Windows port

On Apr 12, 2012 1:17 PM, "Mark Rowe" wrote: > > > On 2012-04-12, at 12:08, Adam Treat wrote: > > > If my memory serves me the problem was that Apple couldn't figure out how to get cmake installed on the Apple build system machine. > > It has little to do with installing software and everything to

Re: [webkit-dev] Handling failing reftests

On Thu, Apr 12, 2012 at 2:18 PM, Dirk Pranke wrote: > On Apr 12, 2012 1:53 PM, "Ryosuke Niwa" wrote: > > > > My suggestion is to try to make it platform-independent but it's > significantly harder than rebaselining the results for pixel tests. As you > point out, it defeats one of the benefits o

Re: [webkit-dev] Handling failing reftests

On Apr 12, 2012 1:53 PM, "Ryosuke Niwa" wrote: > > My suggestion is to try to make it platform-independent but it's significantly harder than rebaselining the results for pixel tests. As you point out, it defeats one of the benefits of reftests if we end up introducing platform-specific reference

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

Correction: the person from Opera who tried to add reference files is Geoffrey Sneddon as Anne pointed out. +Ms2ger, +ehsan from Mozilla, and +jgraham from Opera. Also note that both Ehsan and James have pointed out that my concern that a test and the corresponding ref will match for wrong reason

Re: [webkit-dev] Handling failing reftests

My suggestion is to try to make it platform-independent but it's significantly harder than rebaselining the results for pixel tests. As you point out, it defeats one of the benefits of reftests if we end up introducing platform-specific reference files. - Ryosuke On Thu, Apr 12, 2012 at 1:46 PM,

Re: [webkit-dev] Handling failing reftests

Right, but when those differences come to light, should the goal be to adjust the ref test to make it platform-independent, or is having platform-specific ref tests acceptable? Doesn't that put us in the same situation as having platform-specific pixel tests? From: Ryosuke Niwa mailto:rn...@we

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

I've done more digging and talked with folks from Mozilla and Opera about this topic. Here's a summary. Daniel Glazman from Opera has tried adding reference files for W3C's: http://lists.w3.org/Archives/Public/public-css-testsuite/2010Sep/0030.html However, some people in the CSS working group op

Re: [webkit-dev] Handling failing reftests

Right but you wouldn't know platform-specific issues until you land them. e.g. rounding errors, subtle font differences in edge cases, etc... On Thu, Apr 12, 2012 at 1:30 PM, Jacob Goldstein wrote: > Isn't the goal of writing a ref test that it is not platform specific? > > From: Ryosuke Niwa >

Re: [webkit-dev] Handling failing reftests

At that point, we should probably just make it a pixel test? At some level we just don't have enough experience with reftests to understand what the common problems with them are and make broad policy recommendations. On Thu, Apr 12, 2012 at 1:30 PM, Jacob Goldstein wrote: > Isn't the goal of wr

Re: [webkit-dev] Handling failing reftests

Isn't the goal of writing a ref test that it is not platform specific? From: Ryosuke Niwa mailto:rn...@webkit.org>> Date: Thu, 12 Apr 2012 12:29:42 -0700 To: Ojan Vafai mailto:o...@chromium.org>> Cc: Dirk Pranke mailto:dpra...@chromium.org>>, WebKit Development mailto:webkit-dev@lists.webkit.org>

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

On Thu, Apr 12, 2012 at 12:50 PM, Robert Hogan wrote: > On Thursday 12 April 2012 00:58:47 Ryosuke Niwa wrote: > > On Wed, Apr 11, 2012 at 4:45 PM, Ojan Vafai wrote: > > > I agree with the sentiment that we should be upstreaming these to the > > > W3C, but I don't see why we would require upstrea

Re: [webkit-dev] CMake for Apple's Windows port

On 2012-04-12, at 12:08, Adam Treat wrote: > If my memory serves me the problem was that Apple couldn't figure out how to > get cmake installed on the Apple build system machine. It has little to do with installing software and everything to do with the complexity involved in making a new bui

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

On Thursday 12 April 2012 00:58:47 Ryosuke Niwa wrote: > On Wed, Apr 11, 2012 at 4:45 PM, Ojan Vafai wrote: > > I agree with the sentiment that we should be upstreaming these to the > > W3C, but I don't see why we would require upstreaming them first > > instead of committing them locally and then

Re: [webkit-dev] CMake for Apple's Windows port

On Thu, Apr 12, 2012 at 3:08 PM, Adam Treat wrote: > If my memory serves me the problem was that Apple couldn't figure out how > to get cmake installed on the Apple build system machine. > @WebKitMemes you're up > > From: webkit-dev-boun...@lists.webkit

Re: [webkit-dev] Handling failing reftests

On Thu, Apr 12, 2012 at 11:53 AM, Ojan Vafai wrote: > > I agree that it's hard sometimes to construct reftests that work, but once > you've done so, the cost on the project of maintaining the test is usually > considerably lower than pixel tests. > Not so sure. There are cases where we have these

Re: [webkit-dev] NPAPI plugin may be broken in mac latest sources?

added, with sample plugin that calls CFShow for each NPP call. On Apr 11, 2012, at 3:21 PM, Eric Seidel wrote: > The first step is to file a bug. Then we can CC the right people and > triage your troubles. > > http://www.webkit.org/quality/report

Re: [webkit-dev] CMake for Apple's Windows port

If my memory serves me the problem was that Apple couldn't figure out how to get cmake installed on the Apple build system machine. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Dirk Pranke [dpra...@chromium.o

Re: [webkit-dev] Process for making changes that affect layout test results

On Wed, Apr 11, 2012 at 4:58 PM, Dirk Pranke wrote: > On Wed, Apr 11, 2012 at 4:56 PM, Tony Payne wrote: > > Some of these test result changes turn out to be the effect of incorrect > > test cases. > > > > For example, compositing/color-matching/image-color-matching.html > compares > > an image

Re: [webkit-dev] Handling failing reftests

Ossy, I think the right thing to do, in general, with failing reftests is to skip them. Dave, you can see the chromium win/linux failures here (it passes on chromium mac): http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&showLargeExpectations=true&revision=

Re: [webkit-dev] Handling failing reftests

That reftest is mine. It was supposed to work cross-platform. I am happy to fix, but I'd need to understand what about it didn't work on other platforms. Can someone send me a screenshot of what it looks like? (This is actually why I hate reftests for pagination. It's very hard to construct an

Re: [webkit-dev] CMake for Apple's Windows port

I think this is great; I've been meaning to spend some time on the apple win port trying to fix the remaining bugs holding up the switch to NRWT, but the fact that the apple win port still uses VS2005 is definitely an impediment (yes, I can probably just pull the binaries down from a bot for my pur

Re: [webkit-dev] Handling failing reftests

On Thu, Apr 12, 2012 at 10:57 AM, Dirk Pranke wrote: > > This is an interesting situation; does it make sense to require our > reftests to be generic, or is that unrealistic? I also wonder if we > should allow platform-specific pixel tests to coexist with > platform-specific reference tests (sinc

Re: [webkit-dev] Handling failing reftests

On Thu, Apr 12, 2012 at 12:36 AM, Ryosuke Niwa wrote: > On Thu, Apr 12, 2012 at 12:12 AM, Osztrogonac Csaba > wrote: >> >> I ran into a failing reftest and I didn't find a proper way for handling >> it. >> fast/multicol/cell-shrinkback.html is a new reftest introduced in >> http://trac.webkit.org

[webkit-dev] CMake for Apple's Windows port

Hi, it's more than a year since the last discussion about the build system of Apple's Windows port. In the meantime I merged most of the general changes into the CMake files in the repository and have a working patch with a few CMake files at [1] as written in [2]. I don't think that it is read

Re: [webkit-dev] Reg.use of WTF_CHANGES in FastMalloc.cpp...

FastMalloc is a fork of tcmalloc: http://trac.webkit.org/browser/trunk/Source/WTF/wtf/FastMalloc.cpp#L37 http://goog-perftools.sourceforge.net/doc/tcmalloc.html from several years ago. On Thu, Apr 12, 2012 at 2:11 AM, Hajime Morrita wrote: > Hi, > > The code was brought from a third party library

Re: [webkit-dev] Reg.use of WTF_CHANGES in FastMalloc.cpp...

Hey, in the future send these kind of questions to webkit-help please. For answer check bug: https://bugs.webkit.org/show_bug.cgi?id=69435 (you can also do a search in bugzilla) Cheers, On Thu, 12 Apr 2012 11:01:30 +0200, Arunprasad Rajkumar wrote: I don't understand the use of define

Re: [webkit-dev] Reg.use of WTF_CHANGES in FastMalloc.cpp...

Hi, The code was brought from a third party library and WebKit (WTF) needs some changes to the original code. It looks such changes are marked by WTF_CHANGES. For example, WTF shouldn't depend on gflags, which is disabled by the WTF_CHANGES guard. -- morrita On Thu, Apr 12, 2012 at 6:01 PM, Arun

[webkit-dev] Reg.use of WTF_CHANGES in FastMalloc.cpp...

I don't understand the use of define WTF_CHANGES in FastMalloc.cpp & TCSystemAlloc.cpp. Any body help me to understand that? Thanks in advance. -- Arunprasad Rajkumar ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mai

Re: [webkit-dev] Handling failing reftests

On Thu, Apr 12, 2012 at 12:12 AM, Osztrogonac Csaba wrote: > > I ran into a failing reftest and I didn't find a proper way for handling > it. > fast/multicol/cell-shrinkback.**html is a new reftest introduced in > http://trac.webkit.org/**changeset/113738. >

[webkit-dev] Handling failing reftests

Hi All, I ran into a failing reftest and I didn't find a proper way for handling it. fast/multicol/cell-shrinkback.html is a new reftest introduced in http://trac.webkit.org/changeset/113738 . But unfortunately it fails almost everywhere (Chromium, GTK, Qt). Chromium guys added platform specifi