Lucas Forschler írta:
to 0.8.6p1
Will be back online when complete.
Lucas
Hi All,
Unfortunately there are too annoying bugs introduced
with upgrading build master to 0.8.6p1 :
Problem 1
--
Builders are alphabetically ordered on http://build.webkit.org/waterfall
instead of the given
HI Ossy,
I did notice the display order change as well. I think I am going to open a
bug to rename all of the Apple bots to prefix them with 'Apple'. We (at Apple)
would like to get our bots into a more conforming naming convention. I realize
that won't solve the problem with having a
I continued to work on this, more complete patches have been sent in
https://bugs.webkit.org/show_bug.cgi?id=87872 and
https://bugs.webkit.org/show_bug.cgi?id=84457. It's not because I don't
understand your points, but it's better to debate on an actual patch
that just theoretically :) I think
What I'm seeing is that parts of v8 support are already leaking into
cross-platform WebKit2 code. WebKitTestRunner cannot just use
WebCoreTestSupport, it needs an ifdef for Qt:
#if PLATFORM(QT)
DumpRenderTreeSupportQt::injectInternalsObject(context);
#else
On the other hand, this looks like a regression. Can we file a bug against
buildbot and see what they have to say about it?
On May 31, 2012 9:22 AM, Lucas Forschler lforsch...@apple.com wrote:
HI Ossy,
I did notice the display order change as well. I think I am going to open
a bug to rename
I added the following Wiki page to provide some information on testharness.js
(the JavaScript framework from W3C recently landed in WebKit):
http://trac.webkit.org/wiki/Writing%20testharness%20Tests
I also updated the text under Writing JavaScript-based DOM only test cases on
this page
On Thu, May 31, 2012 at 11:18 AM, Jacob Goldstein jac...@adobe.com wrote:
I added the following Wiki page to provide some information on
testharness.js (the JavaScript framework from W3C recently landed in
WebKit):
http://trac.webkit.org/wiki/Writing%20testharness%20Tests
I also updated the
I am thinking we should rename layoutTestController to testController. Or if
you don’t like that name, maybe testHarness or some even better name.
The old name is too long and the word “layout” is so strange.
We could expose the object under the new name and the old one, and then over
time
On 5/31/12 11:56 AM, Darin Adler da...@apple.com wrote:
I am thinking we should rename layoutTestController to testController. Or
if you don¹t like that name, maybe testHarness or some even better name.
testHarness is probably not a good choice as the W3C JavaScript framework
that recently
testController seems fine to me. I agree it's an improvement.
On the other hand there are other tasks that have more benefit in terms of
code maintenance for people wanting to spend time working in this area. A
couple ideas:
- Move more APIs that only depend WebCore code to internals. Reduces
On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote:
I am thinking we should rename layoutTestController to testController. Or
if you don’t like that name, maybe testHarness or some even better name.
testController seems like a misnomer since it doesn't really control the
test
On Thu, May 31, 2012 at 12:07 PM, Ojan Vafai o...@chromium.org wrote:
testController seems fine to me. I agree it's an improvement.
On the other hand there are other tasks that have more benefit in terms of
code maintenance for people wanting to spend time working in this area. A
couple
On May 31, 2012, at 12:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote:
I am thinking we should rename layoutTestController to testController. Or if
you don’t like that name, maybe testHarness or some even better name.
On May 31, 2012, at 9:36 AM, commit-qu...@webkit.org wrote:
Revision
119113
Author
commit-qu...@webkit.org
Date
2012-05-31 09:36:29 -0700 (Thu, 31 May 2012)
Modified: trunk/Source/WebKit/gtk/ChangeLog (119112 = 119113)
--- trunk/Source/WebKit/gtk/ChangeLog 2012-05-31 16:32:33 UTC
+mrobinson
Looks like the odd ChangeLog was in a patch uploaded by mrobinson:
https://bugs.webkit.org/attachment.cgi?id=143171action=review
Adam
On Thu, May 31, 2012 at 1:43 PM, Dan Bernstein m...@apple.com wrote:
On May 31, 2012, at 9:36 AM, commit-qu...@webkit.org wrote:
2012/5/31 Ojan Vafai o...@chromium.org:
testController seems fine to me. I agree it's an improvement.
On the other hand there are other tasks that have more benefit in terms of
code maintenance for people wanting to spend time working in this area. A
couple ideas:
Move more APIs that only
2012/5/31 Dan Bernstein m...@apple.com:
On May 31, 2012, at 12:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote:
I am thinking we should rename layoutTestController to testController. Or
if you don’t like that name, maybe
Darin, sorry for derailing this thread. I suppose I should have changed the
subject. :)
On Thu, May 31, 2012 at 1:51 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote:
Just a heads-up: there is a meta bug tracking this at
https://bugs.webkit.org/show_bug.cgi?id=87284 .
A few folks have been
On May 31, 2012, at 3:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote:
I am thinking we should rename layoutTestController to testController. Or if
you don’t like that name, maybe testHarness or some even better name.
On Thu, May 31, 2012 at 2:05 PM, Maciej Stachowiak m...@apple.com wrote:
On May 31, 2012, at 3:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote:
I am thinking we should rename layoutTestController to testController. Or
if you
On May 31, 2012, at 2:18 PM, Jacob Goldstein jac...@adobe.com wrote:
I added the following Wiki page to provide some information on testharness.js
(the JavaScript framework from W3C recently landed in WebKit):
http://trac.webkit.org/wiki/Writing%20testharness%20Tests
I also updated the
2012/5/31 Ojan Vafai o...@chromium.org:
Darin, sorry for derailing this thread. I suppose I should have changed the
subject. :)
Fixed. :)
On Thu, May 31, 2012 at 1:51 PM, Jesus Sanchez-Palencia je...@webkit.org
wrote:
We were following the
I haven't found that to be the case for the tests I have written for each
suite, the output from testharness can be as simple as PASS or FAIL, or
include additional debug information defined by the test author. That being
said, my experience is likely more limited than yours. Peter Linss, who
Actually, I misspoke, it's not Peter Linss who maintains testharness, it's
James Graham.
From: Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com
To: Maciej Stachowiak m...@apple.commailto:m...@apple.com
Cc: WebKit Development
webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org
On Thu, May 31, 2012 at 11:18 AM, Jacob Goldstein
jac...@adobe.commailto:jac...@adobe.com wrote:
I added the following Wiki page to provide some information on testharness.js
(the JavaScript framework from W3C recently landed in WebKit):
http://trac.webkit.org/wiki/Writing%20testharness%20Tests
Is there any difference between Settings::devicePixelRatio [1] and
Settings::defaultDeviceScaleFactor [2] ? They appear to be used by
disjoint sets of ports. Shall we delete one in favor of the other?
Adam
[1] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L478
[2]
I don' t think devicePixelRatio() belongs in settings. It should be either be
obtained from the platform code in WebCore/WebKit, or pushed in via API.
Simon
On May 31, 2012, at 3:48 PM, Adam Barth wrote:
Is there any difference between Settings::devicePixelRatio [1] and
(top-posting to fit in)
Doesn't the same argument apply to *deviceScaleFactor? That doesn't make
sense as a Setting either.
Pushing one or both out of settings doesn't answer the question of whether
they are redundant. My gut feeling is that they are and we should fold
them together.
I agree, having this in Settings seems to imply that the browser's physical
device remains the same for its entire lifetime which is not true.
- Dana
On Thu, May 31, 2012 at 6:52 PM, James Robinson jam...@google.com wrote:
(top-posting to fit in)
Doesn't the same argument apply to
I've been working on patches that remove target-densitydpi and/or
defaultDeviceScaleFactor, which is what caused me to ask this
question. I suspect they can both be removed, but I might need some
help from folks with development environments for the various ports
that use one or the other.
Adam
On Thu, May 31, 2012 at 1:46 PM, Adam Barth aba...@webkit.org wrote:
+mrobinson
Looks like the odd ChangeLog was in a patch uploaded by mrobinson:
https://bugs.webkit.org/attachment.cgi?id=143171action=review
Apologies. I'm unsure how this patch became corrupted. I've fixed the ChangeLog.
On Thu, May 31, 2012 at 3:33 PM, Jacob Goldstein jac...@adobe.com wrote:
On Thu, May 31, 2012 at 11:18 AM, Jacob Goldstein jac...@adobe.comwrote:
I added the following Wiki page to provide some information on
testharness.js (the JavaScript framework from W3C recently landed in
WebKit):
On May 31, 2012, at 7:55 PM, Maciej Stachowiak wrote:
On May 31, 2012, at 5:51 PM, Jacob Goldstein jac...@adobe.com wrote:
I haven't found that to be the case for the tests I have written for each
suite, the output from testharness can be as simple as PASS or FAIL, or
include
33 matches
Mail list logo
