Re: [webkit-dev] Tests that fail across different architectures

Am 08.10.2010 um 20:21 schrieb Evan Martin: On Fri, Oct 8, 2010 at 9:21 AM, Nikolas Zimmermann wrote: Paths are prepared, but the switch is not fully done yet. I'm working on a patch, that rounds the results for each command & coordinate-pair in the path debug string output. Since you a

Re: [webkit-dev] Pixel test experiment

Am 08.10.2010 um 20:14 schrieb Jeremy Orlow: I'm not an expert on Pixel tests, but my understanding is that in Chromium (where we've always run with tolerance 0) we've seen real regressions that would have slipped by with something like tolerance 0.1. When you have 0 tolerance, it is more

Re: [webkit-dev] Unapplying execCommand

On Oct 8, 2010, at 3:47 PM, Ryosuke Niwa wrote: > Does anyone know if this was a UI / functionality decision or it is a bug? This undo behavior you describe in Safari is what is automatically implemented by Cocoa’s NSUndoManager. The concept is that when a user undoes something, they want to un

[webkit-dev] Unapplying execCommand

Greetings all, I realized that the behavior of undo is different on WebKit and Chromium. Namely on Safari, execCommand("undo") undoes all previous execCommands while it undoes exactly one execCommand in Chromium. For example, we if have hello window.getSelection().selectAllChildren(test); docum

Re: [webkit-dev] ArrayBuffer supprot

On Fri, Oct 8, 2010 at 3:29 PM, Maciej Stachowiak wrote: > > On Oct 8, 2010, at 3:05 PM, Jian Li wrote: > > Sounds good. I will add the File API feature guard to it and still keep > those files under html/canvas. > > > Another possibility is to have an ArrayBuffer feature guard and ensure that >

Re: [webkit-dev] ArrayBuffer supprot

On Oct 8, 2010, at 3:05 PM, Jian Li wrote: > Sounds good. I will add the File API feature guard to it and still keep those > files under html/canvas. Another possibility is to have an ArrayBuffer feature guard and ensure that it is on if at least one of the features depending on it is on. -

Re: [webkit-dev] ArrayBuffer supprot

Sounds good. I will add the File API feature guard to it and still keep those files under html/canvas. On Fri, Oct 8, 2010 at 2:55 PM, Darin Adler wrote: > On Oct 8, 2010, at 2:46 PM, Jian Li wrote: > > > Currently all these typed array supports are put under 3D_CANVAS feature > guard. Since the

Re: [webkit-dev] How to save a page

On Oct 7, 2010, at 10:53 AM, Jonas Galvez wrote: > I realize this is probably not the right list to be making this question, and > I apologize in advance for the disruption. > > I'm just having a really hard time finding resources and documentation on > webkit's API. See

Re: [webkit-dev] ArrayBuffer supprot

On Oct 8, 2010, at 2:46 PM, Jian Li wrote: > Currently all these typed array supports are put under 3D_CANVAS feature > guard. Since they're going to be widely used in other areas, like File API > and XHR, should we remove the conditional guard 3D_CANVAS from all the > related files? I suggest

[webkit-dev] ArrayBuffer supprot

Hi, I am looking into hooking up ArrayBuffer support in FileReader and BlobBuilder. It seems that most of the typed array types (ArrayBuffer, ArrayBufferView, Uint8Array, and etc) have already been implemented in WebKit, except TypedArray.get() and DataView. Currently all these typed array suppor

Re: [webkit-dev] X-Purpose, again!

On 08.10.2010, at 6:26, Gavin Peters (蓋文彼德斯) wrote: > Can we go ahead and land this change? I still think that it's a misfeature to have cross-origin prefetch, and that hitting search results with prefetch requests is an abuse of network infrastructure, akin to classical spamming. Since link

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

I think the best solution to this pixel matching problem is ref tests. How practical would it be to use ref tests for SVG? Simon On Oct 8, 2010, at 12:43 PM, Dirk Pranke wrote: > Jeremy is correct; the Chromium port has seen real regressions that > virtually no concept of a fuzzy match that I c

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

Jeremy is correct; the Chromium port has seen real regressions that virtually no concept of a fuzzy match that I can imagine would've caught. new-run-webkit-tests doesn't currently support the tolerance concept at al, and I am inclined to argue that it shouldn't. However, I frequently am wrong abo

Re: [webkit-dev] Tests that fail across different architectures

On Fri, Oct 8, 2010 at 9:21 AM, Nikolas Zimmermann wrote: > Paths are prepared, but the switch is not fully done yet. I'm working on a > patch, that rounds the results for each command & coordinate-pair in the > path debug string output. Since you are going to cause rebaselines for all of these t

Re: [webkit-dev] Pixel test experiment

I'm not an expert on Pixel tests, but my understanding is that in Chromium (where we've always run with tolerance 0) we've seen real regressions that would have slipped by with something like tolerance 0.1. When you have 0 tolerance, it is more maintenance work, but if we can avoid regressions, it

Re: [webkit-dev] Pixel test experiment

> The problem I worry about is that on future Mac OS X releases, rendering of > shapes may change in some tiny way that is not visible but enough to cause > failures at tolerance 0. In the past, such false positives arose from time to > time, which is one reason we added pixel test tolerance in

Re: [webkit-dev] Tests that fail across different architectures

On Fri, Oct 8, 2010 at 9:21 AM, Nikolas Zimmermann wrote: > we just switched over to a platform independant way to dump circles, rect, > ellipses etc. > Paths are prepared, but the switch is not fully done yet. I'm working on a > patch, that rounds the results for each command & coordinate-pair in

Re: [webkit-dev] Pixel test experiment

Am 08.10.2010 um 19:53 schrieb Maciej Stachowiak: On Oct 8, 2010, at 12:46 AM, Nikolas Zimmermann wrote: Am 08.10.2010 um 00:44 schrieb Maciej Stachowiak: On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote: Good evening webkit folks, I've finished landing svg/ pixel test baselines,

Re: [webkit-dev] Pixel test experiment

On Oct 8, 2010, at 12:46 AM, Nikolas Zimmermann wrote: > > Am 08.10.2010 um 00:44 schrieb Maciej Stachowiak: > >> >> On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote: >> >>> Good evening webkit folks, >>> >>> I've finished landing svg/ pixel test baselines, which pass with >>> --toleran

Re: [webkit-dev] setTimeout and Safari

On Thu, Oct 7, 2010 at 12:41 PM, Simon Fraser wrote: > On Oct 7, 2010, at 12:23 PM, Steve Conover wrote: > >> So that I don't have to guess whether a page is "done" rendering. >> Many developers defer rendering using setTimeout, I'd like to wait >> until setTimeouts are done and then just after ch

Re: [webkit-dev] Tests that fail across different architectures

Am 08.10.2010 um 18:16 schrieb Martin Robinson: The GTK+ port runs layout tests on both a x86_64 and i386 operating system installations. We have a growing list of tests that generate different expected results between achitectures. These are almost all SVG tests. Last night tests were added th

Re: [webkit-dev] Tests that fail across different architectures

On Oct 8, 2010, at 9:16 AM, Martin Robinson wrote: > The GTK+ port runs layout tests on both a x86_64 and i386 operating > system installations. We have a growing list of tests that generate > different expected results between achitectures. These are almost all > SVG tests. Last night tests were

[webkit-dev] Tests that fail across different architectures

The GTK+ port runs layout tests on both a x86_64 and i386 operating system installations. We have a growing list of tests that generate different expected results between achitectures. These are almost all SVG tests. Last night tests were added that even have different results between our debug and

Re: [webkit-dev] X-Purpose, again!

On Oct 8, 2010, at 6:26 AM, Gavin Peters (蓋文彼德斯) wrote: > In particular, Safari sends "X-Purpose: preview" headers on requests for > resources and subresources motivated by the previw feature of Safari. That’s incorrect. The header is only present in the request for the main resource._

[webkit-dev] X-Purpose, again!

Two weeks ago, I tried to land a patch in bug 46529 to add an "X-Purpose: prefetch" request header to link prefetch motivated requests from WebKit. I'd like to land this change, as I think it's an important part of making link prefetch work well. Link prefetching is part of HTML5. Link prefetchi

Re: [webkit-dev] Pixel test experiment

Am 07.10.2010 um 22:28 schrieb Evan Martin: Chromium also runs pixel tests (for all tests). For SVG, I recall we have problems where 32-bit and 64-bit code will end up drawing (antialiasing) curves differently. Does this sound familiar? Do you have any suggestions on how to address it? Thi

Re: [webkit-dev] Pixel test experiment

We missed many changes because of an existent tolerance level in the past. We made a baseline for MacOS Leopard as well as Snow Leopard and I would active pixel tests just for those two bots. I don't expect any problems. Niko and I run pixel tests on different machines and get the same results.

Re: [webkit-dev] Pixel test experiment

Am 08.10.2010 um 00:44 schrieb Maciej Stachowiak: On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote: Good evening webkit folks, I've finished landing svg/ pixel test baselines, which pass with -- tolerance 0 on my 10.5 & 10.6 machines. As the pixel testing is very important for the SVG