Hi there,
Since Blink forked none of the build bots are running pixel tests.
This means that we are not catching painting regressions where the
rendertree text dump is unaffected by the regression.
Given that in the vast majority of cases a rebaseline to the pixel result
also entails a
Hi there,
The commit queue is stuck and 19 patches are now pending. Looks like the
problem started about 8 hours ago.
Thanks,
Robert
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
This will allow us to rebaseline BOTH test and image expected results
PRIOR to landing patches.
You're welcome.
Great stuff. Thanks for doing this!
A question for the Qt/gtk/efl ports: do you plan to put some testers on the
EWS queue? If not, I think you should shout if you do not want
On Wednesday, 20 March 2013, Ryosuke Niwa wrote:
Please don't add lines to TestExpectations saying that they just need
rebaselines and then leave.
OK. That means I will have to pull the new results from the bots, which is
fine - but in the case of the Mac port (and any other bot that does not
On Thursday, 21 March 2013, Ryosuke Niwa wrote:
I used to pull results from the bots where possible but creating
inconsistency between png/text results is not good.
It is unfortunate but it's much better than losing the complete test
coverage.
If that's the case then I'm happy to land
On Thursday, 21 March 2013, Ryosuke Niwa wrote:
On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan
li...@roberthogan.netjavascript:_e({}, 'cvml', 'li...@roberthogan.net');
wrote:
On Thursday, 21 March 2013, Ryosuke Niwa wrote:
I used to pull results from the bots where possible but creating
This has started happening again I think. As of 8.30pm GMT Monday evening.
On Sunday 01 July 2012 15:34:36 William Siegrist wrote:
There was a network issue that has since been resolved. If you're still
having trouble, please let me know.
-Bill
On Jun 30, 2012, at 8:17 PM, Dirk Pranke
Looks like the problem (for me at least) is with Google's DNS servers -
8.8.8.8 and 8.8.4.4.
OpenDNS and co. work fine.
On Tuesday 03 July 2012 20:37:30 Robert Hogan wrote:
This has started happening again I think. As of 8.30pm GMT Monday
evening.
On Sunday 01 July 2012 15:34:36 William
On Thursday 12 April 2012 00:58:47 Ryosuke Niwa wrote:
On Wed, Apr 11, 2012 at 4:45 PM, Ojan Vafai o...@chromium.org 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
On Wednesday 11 April 2012 20:11:23 Alan Stearns wrote:
The best way to judge whether a reference result is correct is to submit
the result to the W3C CSS 2.1 test suite and have it reviewed. The only
way this test suite will get more reference results is if people like us
volunteer to submit
On Tuesday 10 April 2012 22:35:13 Ryosuke Niwa wrote:
As we have previous discussed following
https://lists.webkit.org/pipermail/webkit-dev/2012-March/019782.html,
it's hard to judge whether a given reference result is enough to cover
everything the test intends to test. e.g. you can have a
On Wednesday 11 April 2012 20:27:23 Dirk Pranke wrote:
What does clean up the existing folder entail?
Just move any -expected.html file out of there and generate pixel results.
Or move the test and its -expected.html into a folder in fast/css.
___
On Wednesday 11 April 2012 23:29:56 Dirk Pranke wrote:
1) What is the best way to add these tests to the tree? Should we add
them one-at-a-time with -expected files that we have created? Should
we add them all at once and SKIP the tests until we have generated
-expected results for each
Hi there,
We currently add tests from the CSS 2.1 suite as we fix them. They get added
to the css2.1/20110323 folder in LayoutTests. Most of them don't have
native reference tests yet in the suite so we (mostly I) have been adding
homebrew reference results to the folder to avoid generating
On Monday 09 April 2012 22:42:33 Dirk Pranke wrote:
Hi all,
Recently I've noticed more people making changes and adding test
failure suppressions to various ports' test_expectations.txt files.
This is great!
Hi Dirk,
It would be good to have a page describing the right thing to do for each
On Wednesday 14 March 2012 08:44:46 Ashod Nakashian wrote:
From: Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de
To: WebKit Development webkit-dev@lists.webkit.org
Cc:
Sent: Wednesday, March 14, 2012 1:31 AM
Subject: [webkit-dev] Git/SVN is slow
G ood morning WebKit crowd,
On Wednesday 25 January 2012 21:09:35 Dirk Pranke wrote:
On Wed, Jan 25, 2012 at 11:20 AM, Robert Hogan rob...@roberthogan.net
wrote:
On Wednesday 25 January 2012 07:38:07 Ryosuke Niwa wrote:
On somewhat related note, can we simplify the output of
new-run-webkit-tests on bots? It's way too
Hi,
I am trying to build a set of requirements for an anti-fingerprinting API in
WebKit. I have a wiki page where I've started dumping all the things such
an API needs to worry about:
https://trac.webkit.org/wiki/Fingerprinting
From an implementation point of view I've started by looking at
On Thursday 13 January 2011 17:02:15 Alexey Proskuryakov wrote:
As a specific example discussed in this thread, we'd
break some browser extensions like Incognito if resource loading could
bypass onbeforeload.
Could you elaborate on this a bit? I don't understand the potential
breakage.
Hi,
I committed http://trac.webkit.org/changeset/74869 from a git-svn checkout.
The change hasn't propagated to git.webkit.org for some reason.
My git-svn copy is set up to point directly to refs/remotes/origin/master
per the recommendation in:
Looks like this was a false alarm. The revision is now in git.
It took an awfully long time to sync though. Was there a problem, or does
the git repo wait for a minimum number of revisions before sync'ing?
On Sunday 02 January 2011 18:47:40 Robert Hogan wrote:
Hi,
I committed http
On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote:
Hi WebKit folks,
I'm thinking about porting Hunspell-based spellchecking code
from Chromium to WebKit/WebCore.
The Qt folks on the list can correct me if I'm wrong but this would be very
welcome for Qt. I don't see how a WebCore
obviously Qt-specific.
- WBR, Alexey Proskuryakov
On 27.03.2010, at 5:46, rob...@webkit.org wrote:
Revision
56661
Author
rob...@webkit.org
Date
2010-03-27 05:46:35 -0700 (Sat, 27 Mar 2010)
Log Message
2010-03-26 Robert Hogan rob...@roberthogan.net
Reviewed
2010-03-26 Robert Hogan rob...@roberthogan.net
Reviewed by Simon Hausmann.
Allow plugins implemented by the application, such as mimetype
'x-qt-plugin',
when pluginsEnabled is false.
The purpose of disabling plugins is to prevent the execution
Hi there,
At the moment WebKit does not deliberately expose any of the properties of
Javascript objects to clients. Those it does expose seem to be as much by
luck as anything else. One example is navigator.useragent, which in Qt's
case ultimately returns whatever the client has set in
25 matches
Mail list logo
