On Nov 2, 2012, at 12:45 AM, Adam Barth aba...@webkit.org wrote:
On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak m...@apple.com wrote:
(3) I suspect that we can handle this without adding an IDL attribute at
all. C++ overloaded functions could let the bindings do something different
These slides present the information really well. Thanks for sharing them.
Cheers,
Maciej
On Oct 31, 2012, at 7:30 PM, Adam Barth aba...@webkit.org wrote:
Below are some slides I presented yesterday that give a high-level
overview of how WebKit works:
On Oct 31, 2012, at 9:32 PM, Ojan Vafai o...@chromium.org wrote:
I'd like to r+ https://bugs.webkit.org/show_bug.cgi?id=96335, but wanted to
give a heads up in case anyone wants to object.
Every native platform that has scrollbars does *not* move focus when you
click on them. Every
On Nov 1, 2012, at 6:36 PM, Adam Barth aba...@webkit.org wrote:
We currently use two different approaches for associating JavaScript
wrappers with DOM objects. For some objects, we store the wrapper
inline in the object itself by making object inherit from
ScriptWrappable. For other types
On Oct 28, 2012, at 10:09 PM, Peter Kasting pkast...@chromium.org wrote:
On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak m...@apple.com wrote:
I am not sure a blanket rule is correct. If the Foo* is logically related to
the object with the foo() method and effectively would give access
On Oct 28, 2012, at 3:30 PM, Antti Koivisto koivi...@iki.fi wrote:
We could clear the cache between tests but run each test twice in a row.
Second run will then happen with deterministically pre-populated cache. That
would both make things more predictable and improve our test coverage for
On Oct 29, 2012, at 3:47 PM, Antti Koivisto koivi...@iki.fi wrote:
I don't think the original proposal was meant to apply to the basic container
types. Would this be a sensible rule to adopt for WebCore only for example?
Like all our blanket rules, this one should be ignored when it
On Oct 26, 2012, at 7:21 PM, Rik Cabanier caban...@gmail.com wrote:
On Fri, Oct 26, 2012 at 9:06 AM, Peter Kasting pkast...@google.com wrote:
On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier caban...@gmail.com wrote:
It is valid for a const method to return you a new object ie a const
On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
I’m sure Antti, Alexey, and others who have worked on the loader and other
parts of WebKit are happy to write those tests or list the kind of things
they want to test. Heck, I don’t mind writing those tests if someone
Apple did not ship the last release of Safari to SnowLeopard and we have no
plans to maintain SnowLeopard support on trunk. We haven't actively ripped out
SL-specific ifdefs because we were under the impression that the Chromium port
still targets SL and sometimes uses Mac code paths.
That
On Oct 15, 2012, at 9:56 AM, Michael Saboff msab...@apple.com wrote:
I recently landed r131311 which adds code to handle 8-bit strings in the
render text path. The code also puts HTML text into 8-bit strings.
The reason for this announcement is that the handling of 8-bit text on the
I agree with this position as well. It seems good to have a transition period
and to gather some data.
- Maciej
On Oct 11, 2012, at 9:59 PM, Darin Fisher da...@chromium.org wrote:
I agree with what Adam wrote in
https://bugs.webkit.org/show_bug.cgi?id=99116#c5. Even if a lot of sites
The best way to find out would be to file a bug at http://bugs.webkit.org/ with
a test case demonstrating the problem.
- Maciej
On Oct 12, 2012, at 6:26 PM, Blake Fiddler blake.fidd...@gmail.com wrote:
Hi.
I have some example in which my function recompiling in dfg jit (it's parsing
in
On Oct 10, 2012, at 8:49 AM, Adam Barth aba...@webkit.org wrote:
On Wed, Oct 10, 2012 at 12:04 AM, Maciej Stachowiak m...@apple.com wrote:
On Oct 9, 2012, at 1:50 PM, Adam Barth aba...@webkit.org wrote:
That raises the question of what the cache-size to hit-rate curve
looks like. I don't
On Oct 9, 2012, at 1:24 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Oct 9, 2012 at 12:17 PM, Antti Koivisto koivi...@iki.fi wrote:
On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth aba...@webkit.org wrote:
This is interesting data, but it seems to be related to whether we
should make the
Adding support for custom variants of HTML is not really in line with the goals
of the WebKit project. It sounds like CE-HTML and OIPF are both HTML variants.
I don't think these types of features are a good fit for WebKit, because:
(1) Custom HTML dialects tend to create excessive maintenance
On Oct 8, 2012, at 5:28 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Oct 8, 2012 at 2:17 PM, Brady Eidson beid...@apple.com wrote:
On Oct 8, 2012, at 12:17 PM, Adam Barth aba...@webkit.org wrote:
Would there be any design or implementation constraints on WebCore?
For example, would
On Oct 1, 2012, at 10:55 PM, Adam Barth aba...@webkit.org wrote:
According to
http://stackoverflow.com/questions/1851299/is-it-possible-to-tell-the-branch-predictor-how-likely-it-is-to-follow-the-branc,
__builtin_expect (what our LIKELY and UNLIKELY macros expand to [1])
doesn't do anything
be made without relying on
what specific standards bodies explicitly ask for, but I did not want to
rewrite it that much,
Cheers,
Maciej
On Sep 21, 2012, at 6:21 PM, Adam Barth aba...@webkit.org wrote:
[+Tab]
On Fri, Sep 21, 2012 at 5:50 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 21
Our recent practice and policy has been that the person asking for removal has
to present information to show that it's likely safe.For example by gathering
usage statistics. See: https://trac.webkit.org/wiki/DeprecatingFeatures
Note that 'text-align: -webkit-auto' can have an effect even if
Since TPAC is less than a month away, I don't understand why we can't wait for
that discussion. I do support the idea in general, and I plan to be at TPAC and
will advocate for it.
I understand that sometimes we need to move ahead of the spec. If there's a
reason not to wait a few extra weeks
I'm not hung up on the name. But if we are worried about name collision, we
could do data gathering on use of Path or other candidate names instead of just
guessing.
- Maciej
On Sep 24, 2012, at 12:22 PM, Dirk Schulze dschu...@adobe.com wrote:
On Sep 24, 2012, at 12:03 PM, Rik Cabanier
On Sep 21, 2012, at 5:34 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Sep 21, 2012 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote:
Yeah, obligation is probably too loaded a word. Here's some updated text:
[[
* Standards citizenship. Many W3C working groups, including the CSS
I like having static analysis results available - that seems useful.
I think static analysis tools are more useful when we can set a blanket policy
of fixing all warnings they report. For example, our warning levels combined
with -Werror are a very strong tool in this regard, despite the
On Sep 17, 2012, at 8:13 PM, Hajime Morrita morr...@chromium.org wrote:
And/Or are we going to allow inline annotations?
The practice Coverity suggested is to adding such annotations.
http://scan.coverity.com/best-practice.html
I personally think it's worth having inline annotations
On Sep 16, 2012, at 2:30 AM, Allan Sandfeld Jensen k...@carewolf.com wrote:
On Thursday 13 September 2012, Dan Bernstein wrote:
On Sep 13, 2012, at 1:29 AM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
Hi there,
I was telling people to use unsigned instead of unsigned
On Sep 12, 2012, at 10:36 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote:
- Is this approach substantially less time and effort than adding a
histogram-style metric? I expect you have added a histogram to Chrome at some
point
On Sep 13, 2012, at 11:15 PM, Darin Fisher da...@google.com wrote:
On Thu, Sep 13, 2012 at 6:16 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Sep 13, 2012 at 5:13 PM, Adam Barth aba...@webkit.org wrote:
Another metric we have is for Blob.webkitSlice:
Ratio of Blob.webkitSlice calls
On Sep 12, 2012, at 5:10 PM, Adam Barth aba...@webkit.org wrote:
I've posted a patch to delete webkitPostMessage in favor of the
identically behaving, unprefixed postMessage:
https://bugs.webkit.org/show_bug.cgi?id=96577
We've discussed this topic previously in
On Sep 12, 2012, at 5:51 PM, Adam Barth aba...@webkit.org wrote:
On Wed, Sep 12, 2012 at 5:34 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 12, 2012, at 5:10 PM, Adam Barth aba...@webkit.org wrote:
I've posted a patch to delete webkitPostMessage in favor of the
identically behaving
On Sep 12, 2012, at 6:17 PM, Adam Barth aba...@webkit.org wrote:
I don't think we should adopt policies without some evidence that they
work. I'm glad that we had a discussion about this topic at the
contributor's meeting, and I'm also glad that we tried out
operator+ is now efficient (potentially more so than using a StringBuilder if
you can do it all in one statement). operator+= still sucks, and I don't think
we came up with an obvious way to get good performance with the same syntax.
One possibility: we could add operator+=(String) to
On Sep 4, 2012, at 4:44 PM, Dirk Schulze dschu...@adobe.com wrote:
Yes, looks like the efforts didn't went further. Anyway, is there no
possibility to improve operator+= further? It is very likely that even future
code will land with this operator instead of StringBuilder. I think it is
On Sep 4, 2012, at 5:16 PM, Mike Lawther mikelawt...@chromium.org wrote:
On 5 September 2012 09:44, Dirk Schulze dschu...@adobe.com wrote:
It is very likely that even future code will land with this operator instead
of StringBuilder.
Not if Adam removes the operator as he proposed
I like the idea of this change. Using key and value makes things more readable
at the site of use than a generic first/second. It's unfortunate that it is
hard to deploy, but I think it's worth it to work through those challenges. `
-Maciej
On Aug 28, 2012, at 3:24 PM, Caio Marcelo de
to be had without
breaking WebVTT? If so, we can think about whether removing the scaffolding and
reconstructing it when needed is worthwhile.
- Maciej
On Thu, Mar 15, 2012 at 1:58 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 15, 2012, at 1:29 PM, Eric Seidel wrote:
It seems
On Aug 27, 2012, at 3:48 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Aug 27, 2012 at 3:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 27, 2012, at 2:45 PM, Eric Seidel e...@webkit.org wrote:
Checking back in:
Curious if this effort is still underway. Adam and I would like
On Aug 27, 2012, at 4:28 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Aug 27, 2012 at 4:02 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 27, 2012, at 3:48 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Aug 27, 2012 at 3:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 27, 2012
On Aug 27, 2012, at 5:02 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Aug 27, 2012 at 4:46 PM, Dirk Schulze dschu...@adobe.com wrote:
Ha! So the reason for removing the code is simplifying the HTML5 parser,
just to undo the simplification once the original writer has the time to
come
What's the difference between the ASCIILiteral and ConstructFromLiteral
versions?
- Maciej
On Aug 24, 2012, at 8:00 PM, Benjamin Poulain benja...@webkit.org wrote:
Dear webkit-dev,
Some recent changes improved the way we can use string classes with literals.
There are 3 new
On Aug 21, 2012, at 3:23 PM, Ojan Vafai o...@chromium.org wrote:
On Mon, Aug 20, 2012 at 6:03 PM, Maciej Stachowiak m...@apple.com wrote:
Here's how I imagine the workflow when a sheriff or just innocent bystander
notices a deterministically failing test. Follow this two-step algorithm:
1
On Aug 18, 2012, at 1:08 AM, Filip Pizlo fpi...@apple.com wrote:
I like your idea of having both the result-we-currently-expect and the
result-we-think-may-be-more-correct to be checked in. I still prefer Dirk's
naming scheme though.
I think if we had both checked in, the
to -expected-failure/-unexpected-pass as a naming scheme,
along with the approach of keeping both around when they are used?
Regards,
Maciej
-Filip
On Aug 18, 2012, at 2:01 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 18, 2012, at 1:08 AM, Filip Pizlo fpi...@apple.com wrote:
I like your
My understanding of the current proposal is this:
1) This applies to tests that fail deterministically, for reasons other than a
crash or hang.
2) If the test has a new result that you're confident is a progression (or
neither better or worse), you simply update the -expected.txt file.
3) If
On Aug 15, 2012, at 12:27 PM, Filip Pizlo fpi...@apple.com wrote:
This sounds like it's adding even more complication to an already complicated
system.
Given how many tests we currently have, I also don't buy that continuing to
run a test that is already known to fail provides much
images in the viewport.
Alpha
2012/8/13 Maciej Stachowiak m...@apple.com
The thing I'm not confident of is whether an image's position in absolute
coordinates can be changed by an ancestor after RenderImage::layout
completes. It would be helpful if a layout expert would weigh
On Aug 10, 2012, at 3:47 PM, Alpha Lam hc...@chromium.org wrote:
This is a very valid concern. The question you raised is one topic I want to
discuss more broadly.
Chromium has a separate rasterization stage so there is some time for
decoders to work, synchronization can happen in
, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak m...@apple.com wrote:
Why not start asynchronous decoding immediately as the image is loading, and
synchronize at paint time? What is the benefit of waiting until layout time
to start decoding the image data?
Uninformed guess (since I haven't
On Aug 8, 2012, at 5:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
It appears that we recommend the use of non-secure HTTP connection on many
webkit.org documents:
e.g. https://www.webkit.org/building/checkout.html
Can we move away from this and recommend the use of HTTPS instead?
On Aug 1, 2012, at 4:36 PM, Elliott Sprehn espr...@chromium.org wrote:
On Tue, Jul 31, 2012 at 7:35 PM, Bruno Abinader brunoabina...@gmail.com
wrote:
Hi all :)
As suggested by Ojan, I am writing a mail to you about my intention to
implement all updated and missing text-decoration*
Has anything been done to verify security and stability of the feature, for
example, fuzz testing? I'd like to request that before enabling for Apple's
ports.
- Maciej
On Jul 30, 2012, at 11:35 PM, Arko Saha ngh...@motorola.com wrote:
I am planning to enable MICRODATA feature by default in
On Jul 25, 2012, at 2:08 AM, Yury Semikhatsky yu...@chromium.org wrote:
On Tue, Jul 24, 2012 at 10:34 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 24, 2012, at 12:39 AM, Yury Semikhatsky yu...@chromium.org wrote:
On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak m
On Jul 24, 2012, at 12:39 AM, Yury Semikhatsky yu...@chromium.org wrote:
On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak m...@apple.com wrote:
On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky yu...@chromium.org wrote:
First option we consider is to define a class with the same
On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky yu...@chromium.org wrote:
First option we consider is to define a class with the same set of fields as
the instrumented one, then have a compile time assert that size of the
reference class equals to the size of the instrumented one. See
On Jul 19, 2012, at 11:01 AM, Oliver Buchtala oliver.bucht...@googlemail.com
wrote:
Hi,
I am probably one of those people who much dislike printf-debugging.
What is your problem with using a debugger?
Maybe because the displayed information is not appropriate?
E.g., you would like
On Jul 10, 2012, at 8:52 AM, Brady Eidson beid...@apple.com wrote:
On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org
wrote:
On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:
On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org
On Jul 13, 2012, at 5:57 AM, Stephen Chenney schen...@chromium.org wrote:
I'd be happy to add a term to the cost function:
Cost per year with good comments: t_maintainComments * n_patches +
t_understandWithComment * n_engineersNeedingToUnderstand +
t_discoverAndFixBadCommend *
On Jul 13, 2012, at 11:03 AM, Dana Jansens dan...@chromium.org wrote:
On Fri, Jul 13, 2012 at 1:56 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jul 13, 2012 at 5:57 AM, Stephen Chenney schen...@chromium.org
wrote:
I don't doubt there are poor comments, both outdated and useless.
On Jul 13, 2012, at 11:13 AM, Alec Flett alecfl...@chromium.org wrote:
And yes while incorrect behavior can be observed through automated testing,
automated testing does not catch all incorrect behavior, especially
unexpected never-before-seen behavior. Why do you think people write
On Jul 12, 2012, at 6:50 AM, John Mellor joh...@chromium.org wrote:
To take an arbitrary example, lets say that while iterating through a
ListHashSet something causes entries to be deleted. Intuitively it seems this
needn't invalidate the iterator, as long as the entry the iterator is
On Jul 12, 2012, at 1:47 PM, Stephen Chenney schen...@chromium.org wrote:
On Thu, Jul 12, 2012 at 3:44 PM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, Jul 12, 2012 at 10:53 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Jul 12, 2012 at 10:43 AM, Stephen Chenney
On Jul 9, 2012, at 1:30 AM, KwangYul Seo sk...@company100.net wrote:
Hi,
Our team at Company 100 has worked on parallel image decoders for past a few
weeks and some patches are pending for review now. Here is the master bug for
parallel image decoders:
Starting a new thread, since this has wandered a fair bit off topic (and Eric
had a good point that it's kind of a threadjack).
On Jul 6, 2012, at 12:54 PM, Per Bothner per.both...@oracle.com wrote:
The biggest annoyance I found is lack of class-level comments. For example
what is an
On Jul 6, 2012, at 2:37 PM, Per Bothner per.both...@oracle.com wrote:
On 07/06/2012 02:02 PM, Maciej Stachowiak wrote:
[... reasonable stuff I fully agree with - but one question ...]
Documenting ownership and lifetime relationships is also useful. We have
tended to do that as diagrams
On Jun 28, 2012, at 6:44 AM, Thiago Marcos P. Santos tmpsan...@gmail.com
wrote:
Hi WebKit,
webkit-patch patches-to-review was reworked [1] and now, instead of giving
you the list of attachment ID of all the patches pending review, it will give
you the list of bugs + description + age of
From your design document, it sounds like this approach retains
guardRef/selfOnlyRef, and will not let a disconnected subtree keep the owner
document's children alive. Am I understanding correctly?
- Maciej
On Jun 27, 2012, at 5:55 AM, Kentaro Hara hara...@chromium.org wrote:
I wrote a
Is there a way to reduce these costs other than deleting the slower-maintained
JITs? For example, could we temporarily freeze the JIT (perhaps the whole JSC
engine somehow) at old versions somehow for architectures that may take time to
catch up?
Regards,
Maciej
On Jun 22, 2012, at 10:52 AM,
On Jun 15, 2012, at 12:12 AM, Roland Steiner rolandstei...@google.com wrote:
Sorry for the late reply, this thread flew under my radar.
I made the original name change, because I honestly was entirely confused
about the meaning of selfOnlyRef (it's done by Node on Document, so what is
On Jun 15, 2012, at 10:31 AM, Darin Adler da...@apple.com wrote:
On Jun 15, 2012, at 10:15 AM, Maciej Stachowiak m...@apple.com wrote:
But it's hard to explain fully in a function name w/o excess verbosity.
I think my favorite excess verbosity version is refDocumentButNotOtherNodes
On Jun 15, 2012, at 12:22 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 15, 2012 at 12:14 PM, Maciej Stachowiak m...@apple.com wrote:
I am not sure how to get the key points across without being accurate or
misleading. A version that I think explains the complete design without
On Jun 14, 2012, at 1:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Jun 14, 2012 at 1:44 PM, Peter Kasting pkast...@chromium.org wrote:
On Thu, Jun 14, 2012 at 1:39 PM, Elliot Poger epo...@chromium.org wrote:
Can someone please remind me why IMAGE+TEXT even exists?
Wouldn't it be
On Jun 14, 2012, at 9:06 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jun 14, 2012 at 9:02 PM, Ojan Vafai o...@chromium.org wrote:
Seems like it will be a common error to mark a reftest failure as
ImageOnlyFail and then be confused why it's not working, no?
Maybe that can be solved
On Jun 13, 2012, at 1:32 PM, Geoffrey Garen gga...@apple.com wrote:
These tests regularly timeout on the Chromium debug bots and occasionally
timeout on the Apple Lion bots.
WebKit has a clear policy about this: Tests must be fast enough not to time
out. We can fix this issue by making
On Jun 13, 2012, at 3:58 PM, Darin Adler da...@apple.com wrote:
On Jun 13, 2012, at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote:
* we use \ (backslash) as a delimiter instead of : and =
Seems worse to me. When I see a backslash I assume it’s a line continuation
character or a C
On Jun 10, 2012, at 9:26 AM, Ojan Vafai o...@chromium.org wrote:
On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen kbal...@webkit.org wrote:
So the unit tests are superfluous. In particular, if I had to pick between
only having unit tests or only having regression tests, I might pick unit
On Jun 6, 2012, at 6:27 PM, Darin Adler da...@apple.com wrote:
On Jun 6, 2012, at 6:14 PM, Kentaro Hara hara...@chromium.org wrote:
IMHO, (a) would be the best semantics.
I agree, and I think that the specification actually does require this.
The real issue here is how to fix this bug
On Jun 11, 2012, at 6:06 PM, Maciej Stachowiak m...@apple.com wrote:
not a self-only reference (at some point renamed to guardRef).
BTW I was able to find where it was renamed but not a good explanation of why.
I think selfOnlyRef() was a much clearer name.
The history seems
On Jun 7, 2012, at 1:10 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan sulli...@chromium.org
wrote:
I wanted to let you know that I plan to add support for
navigator.buildType
Already done for the WebKit2 WebKitTestRunner. It should be straightforward to
adapt its IDL compiler.
- Maciej
On Jun 2, 2012, at 11:03 PM, Adam Barth aba...@webkit.org wrote:
We might also want to define the layoutTestController object with IDL
so we don't have to hand-write bindings
, 2012, at 5:17 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Jun 3, 2012 at 1:45 PM, Maciej Stachowiak m...@apple.com wrote:
Already done for the WebKit2 WebKitTestRunner. It should be straightforward
to adapt its IDL compiler.
I've considered adapting WebKitTestRunner's code generator
Sent from my iPad
On Jun 3, 2012, at 8:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Jun 3, 2012 at 3:55 PM, Maciej Stachowiak m...@apple.com wrote:
I am on vacation so I won't be able to review your patch in detail, but from
your description it sounds less appealing to me than
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 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
On May 30, 2012, at 4:24 PM, John Mellor joh...@chromium.org wrote:
Maciej Stachowiak wrote:
Can you explain why the target-densitydpi feature even exists? It
seems ill-conceived to me, and the most straightforward fix would
be to remove it. I have not heard anyone explain the use case
Can you explain why the target-densitydpi feature even exists? It seems
ill-conceived to me, and the most straightforward fix would be to remove it. I
have not heard anyone explain the use case for it. (I'm also not clear on the
details of what it actually does, and neither the name nor the
On May 23, 2012, at 2:16 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
The only sane argument I've heard so far to gate pixel tests is that the
correctness of such tests need to be manually inspected, which requires
a
lot
On May 23, 2012, at 3:13 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak m...@apple.com wrote:
Are you concerned just about the actual pixel results or also about keeping
render tree dumps up to date?
Both are more maintenance than a text
On May 21, 2012, at 12:16 PM, Andrew Wilson atwil...@google.com wrote:
On Mon, May 21, 2012 at 2:17 AM, Jochen Eisinger joc...@chromium.org wrote:
Hey,
in https://bugs.webkit.org/show_bug.cgi?id=86969 I'm changing window.focus
and window.blur to match Firefox's behavior: window.blur
, Internet
Explorer).
- There is no specification about it.
- It was added in 2005 http://trac.webkit.org/changeset/11481.
[...]
This function was added by Dave Hyatt and reviewed by Maciej
Stachowiak, maybe you guys can tell us why you added it back then (if
your memory is very good as we
On May 21, 2012, at 12:24 PM, Andrew Wilson atwil...@google.com wrote:
On Mon, May 21, 2012 at 12:21 PM, Maciej Stachowiak m...@apple.com wrote:
On May 21, 2012, at 12:16 PM, Andrew Wilson atwil...@google.com wrote:
On Mon, May 21, 2012 at 2:17 AM, Jochen Eisinger joc
On May 17, 2012, at 5:39 PM, Dirk Pranke dpra...@chromium.org wrote:
I probably polarized things by saying that your input was less
valuable than those of people who were long-time users. I did not mean
to offend, and I'm sorry. I certainly didn't mean to imply that I was
not listening or
On May 16, 2012, at 10:39 PM, Dirk Pranke dpra...@chromium.org wrote:
There was a semi-logical basis, in that the stuff on the right of the
test clearly specified the outcome of the test (PASS, IMAGE, TEXT,
etc.). The stuff on the left was less well defined: there's the bug
numbers, the
On May 17, 2012, at 11:28 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 17, 2012 at 11:08 AM, Peter Kasting pkast...@google.com wrote:
On Thu, May 17, 2012 at 9:26 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
I actually quite like
the clear delineation between test modifiers and
On May 17, 2012, at 12:53 PM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, May 17, 2012 at 12:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
I find either all-lowercase or all-caps to be much harder to read than
capitalized words. They look like a blob of letters to me.
We might have to
On May 17, 2012, at 3:37 PM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, May 17, 2012 at 3:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 17, 2012 at 3:01 PM, Dirk Pranke dpra...@chromium.org wrote:
As I said before, I believe they increase the readability of the file.
I
On May 17, 2012, at 4:17 PM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, May 17, 2012 at 4:00 PM, Maciej Stachowiak m...@apple.com wrote:
On May 17, 2012, at 12:53 PM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, May 17, 2012 at 12:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
I
On May 17, 2012, at 1:42 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, May 17, 2012 at 1:37 PM, Peter Kasting pkast...@chromium.org wrote:
On Thu, May 17, 2012 at 1:34 PM, Ojan Vafai o...@chromium.org wrote:
2. Make outcomes optional. If they are left out, then the test is skipped
(unless
On May 17, 2012, at 4:40 PM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, May 17, 2012 at 4:16 PM, Maciej Stachowiak m...@apple.com wrote:
Let's take an example. TEXT next to a test name apparently means that the
text fails. There is no way in the world I would guess that just from
On May 17, 2012, at 7:27 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, May 17, 2012 at 4:29 PM, Maciej Stachowiak m...@apple.com wrote:
On May 17, 2012, at 1:42 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, May 17, 2012 at 1:37 PM, Peter Kasting pkast...@chromium.org wrote:
On Thu
On May 16, 2012, at 9:08 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
There has been some complaints / discussions about how syntax in
test_expectations.txt is confusing (and I agree with you) on webkit-dev and
at contributors' meeting.
So I have a patch on
401 - 500 of 1378 matches
Mail list logo