I think a different way works: hooking window.setTimeout,
window.setInterval, window.clearTimeout and window.clearInterval after
the page is loaded and before any script is run, like the following:
(function() {
var orgSetTimeout = window.setTimeout;
window.setTimeout = function(f, t) {
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
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.
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?
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
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
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
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
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
On Thu, Oct 7, 2010 at 12:41 PM, Simon Fraser simon.fra...@apple.com 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
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
--tolerance 0 on my 10.5
On Fri, Oct 8, 2010 at 9:21 AM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de 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
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
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,
On Fri, Oct 8, 2010 at 9:21 AM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de 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
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
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
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
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
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 we
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
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 da...@apple.com wrote:
On Oct 8, 2010, at 2:46 PM, Jian Li wrote:
Currently all these typed array supports are put under 3D_CANVAS feature
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.
-
On Fri, Oct 8, 2010 at 3:29 PM, Maciej Stachowiak m...@apple.com 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
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
div id=test contenteditablehello/div
script
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
26 matches
Mail list logo
