Re: [webkit-dev] We should rename layoutTestController to testController

On May 31, 2012, at 3:11 PM, Ryosuke Niwa wrote: > On Thu, May 31, 2012 at 11:56 AM, Darin Adler 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 misn

Re: [webkit-dev] testharness Wiki page added

On May 31, 2012, at 2:18 PM, Jacob Goldstein 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 text under "Wr

Re: [webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two

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 wrote: > We might also want to define the layoutTestController object with IDL > so we don't have to hand-write bindings every time we change

Re: [webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two

Jun 3, 2012, at 5:17 PM, Ryosuke Niwa wrote: > On Sun, Jun 3, 2012 at 1:45 PM, Maciej Stachowiak wrote: > Already done for the WebKit2 WebKitTestRunner. It should be straightforward > to adapt its IDL compiler. > > I've considered adapting WebKitTestRunner's code gener

Re: [webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two

Sent from my iPad On Jun 3, 2012, at 8:05 PM, Ryosuke Niwa wrote: > On Sun, Jun 3, 2012 at 3:55 PM, Maciej Stachowiak 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 the WKTR approac

Re: [webkit-dev] can we stop using Skipped files?

On Jun 10, 2012, at 9:26 AM, Ojan Vafai wrote: > On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen 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 >> tests. But if I already have

Re: [webkit-dev] DOM tree traversal on detached nodes

On Jun 6, 2012, at 6:27 PM, Darin Adler wrote: > On Jun 6, 2012, at 6:14 PM, Kentaro Hara 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 efficiently. I believe that

[webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)

On Jun 11, 2012, at 6:06 PM, Maciej Stachowiak 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 to be that it was rena

[webkit-dev] Adding nonstandard features (was Re: Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore)

On Jun 7, 2012, at 1:10 PM, Adam Barth wrote: > On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa wrote: >> On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan >> wrote: >>> >>> I wanted to let you know that I plan to add support for >>> navigator.buildType (e.g., "nightly", "beta", "final") to WebKit.

Re: [webkit-dev] are fuzzer tests appropriate layout tests?

On Jun 13, 2012, at 1:32 PM, Geoffrey Garen 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 these tests

Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...

On Jun 13, 2012, at 3:58 PM, Darin Adler wrote: > On Jun 13, 2012, at 3:53 PM, Dirk Pranke 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 escape sequence. > > On th

Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...

On Jun 14, 2012, at 1:47 PM, Ryosuke Niwa wrote: > > On Thu, Jun 14, 2012 at 1:44 PM, Peter Kasting wrote: > On Thu, Jun 14, 2012 at 1:39 PM, Elliot Poger wrote: > Can someone please remind me why IMAGE+TEXT even exists? > > Wouldn't it be simpler to just mark a test as follows? > IMAGE : al

Re: [webkit-dev] IMAGE+TEXT WAS: TestExpectations syntax changes, last call (for a while, at least) ...

On Jun 14, 2012, at 9:06 PM, Adam Barth wrote: > On Thu, Jun 14, 2012 at 9:02 PM, Ojan Vafai 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 with another name, like Pixe

Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)

On Jun 15, 2012, at 12:12 AM, Roland Steiner 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 > "self"? Why is it ne

Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)

On Jun 15, 2012, at 10:31 AM, Darin Adler wrote: > On Jun 15, 2012, at 10:15 AM, Maciej Stachowiak 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. Thin

Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)

On Jun 15, 2012, at 12:22 PM, Ryosuke Niwa wrote: > On Fri, Jun 15, 2012 at 12:14 PM, Maciej Stachowiak 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 > saying anyth

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

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,

Re: [webkit-dev] DOM tree traversal on detached nodes

>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 wrote: > I wrote a document and impleme

Re: [webkit-dev] Feature announcement: webkit-patch patches-to-review

On Jun 28, 2012, at 6:44 AM, Thiago Marcos P. Santos 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 patches pend

[webkit-dev] Class-level comments in the source code

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 wrote: > The biggest annoyance I found is lack of class-level comments. For example > what is an Interpreter? How many inst

Re: [webkit-dev] Class-level comments in the source code

tes to other objects. > > For some classes, yes. > > On Fri, Jul 6, 2012 at 2:02 PM, Maciej Stachowiak wrote: > On Jul 6, 2012, at 12:54 PM, Per Bothner wrote: > > > The biggest annoyance I found is lack of class-level comments. For example > > what is an Interpreter?

Re: [webkit-dev] Class-level comments in the source code

On Jul 6, 2012, at 2:37 PM, Per Bothner 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 a

Re: [webkit-dev] Parallel image decoders are up for review

On Jul 9, 2012, at 1:30 AM, KwangYul Seo 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: > > https://bugs.webkit.org/show_bug.cgi?id=90375

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Jul 12, 2012, at 6:50 AM, John Mellor 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 > currently poi

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Jul 12, 2012, at 1:47 PM, Stephen Chenney wrote: > > > On Thu, Jul 12, 2012 at 3:44 PM, Dirk Pranke wrote: > On Thu, Jul 12, 2012 at 10:53 AM, Ryosuke Niwa wrote: > > On Thu, Jul 12, 2012 at 10:43 AM, Stephen Chenney > > wrote: > >> > >> As several people have shown, it is quite easy to

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Jul 13, 2012, at 5:57 AM, Stephen Chenney 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 * n_badComments > > I do

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Jul 13, 2012, at 11:03 AM, Dana Jansens wrote: > On Fri, Jul 13, 2012 at 1:56 PM, Ryosuke Niwa wrote: > On Fri, Jul 13, 2012 at 5:57 AM, Stephen Chenney > wrote: > > I don't doubt there are poor comments, both outdated and useless. That's a > reviewing failure. You have simply highlighte

Re: [webkit-dev] Comments in the code (Was Please include function-level comments in change log entries)

On Jul 13, 2012, at 11:13 AM, Alec Flett 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 fuzzers? > This is yet

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

On Jul 19, 2012, at 11:01 AM, Oliver Buchtala 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 > someString.utf8().d

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

On Jul 10, 2012, at 8:52 AM, Brady Eidson wrote: > > On Jul 10, 2012, at 5:25 AM, Alexis Menard > wrote: > >> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson wrote: >>> >>> On Jul 9, 2012, at 2:43 PM, Alexis Menard >>> wrote: >>> Hi, For those who "secretly" use printf debu

Re: [webkit-dev] WebKit memory instrumentation

On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky 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 > https://bugs.w

Re: [webkit-dev] WebKit memory instrumentation

On Jul 24, 2012, at 12:39 AM, Yury Semikhatsky wrote: > > > On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak wrote: > > On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky wrote: > >> >> >> First option we consider is to define a class with the same s

Re: [webkit-dev] WebKit memory instrumentation

On Jul 25, 2012, at 2:08 AM, Yury Semikhatsky wrote: > > > On Tue, Jul 24, 2012 at 10:34 PM, Maciej Stachowiak wrote: > > On Jul 24, 2012, at 12:39 AM, Yury Semikhatsky wrote: > >> >> >> On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak wrote: >

Re: [webkit-dev] Enable MICRODATA feature by default

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 wrote: > I am planning to enable MICRODATA feature by default in WebKit. > > Micro

Re: [webkit-dev] Add support for CSS3 text-decoration* properties

On Aug 1, 2012, at 4:36 PM, Elliott Sprehn wrote: > > On Tue, Jul 31, 2012 at 7:35 PM, Bruno Abinader > 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* properties from > CSS3 spec (currently in

Re: [webkit-dev] We should encourage the use of httpS://svn.webkit.org

On Aug 8, 2012, at 5:41 PM, Ryosuke Niwa 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? It's very >

Re: [webkit-dev] Status of multithreaded image decoding

On Aug 10, 2012, at 3:47 PM, Alpha Lam 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 rasterization stage.

Re: [webkit-dev] Status of multithreaded image decoding

at 1:24 PM, Maciej Stachowiak 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 tou

Re: [webkit-dev] Status of multithreaded image decoding

: > https://bugs.webkit.org/show_bug.cgi?id=90375#c80 > > In the above link, Hin-Chung shows how to determine whether an image > is actually painted. > > 2012/8/13 Maciej Stachowiak : >> I that case, starting async decoding at layout time makes sense if and only >> if at layout

Re: [webkit-dev] Status of multithreaded image decoding

too, as page scrolls need to > iterate images in the viewport. > > Alpha > > 2012/8/13 Maciej Stachowiak > > 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 > c

Re: [webkit-dev] A proposal for handling "failing" layout tests and TestExpectations

On Aug 15, 2012, at 12:27 PM, Filip Pizlo 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 benefit. If the

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling "failing" layout tests and TestExpectations

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 th

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling "failing" layout tests and TestExpectations

4) I'd want to work through the various branches in the workflow more >> before I felt comfortable with this. When I was coming up with my >> original proposal I originally wanted to allow -passing and -expected >> to live side-by-side, but all sorts of complications arose,

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling "failing" layout tests and TestExpectations

On Aug 18, 2012, at 1:08 AM, Filip Pizlo 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 result-we-think-may-be-more-co

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling "failing" layout tests and TestExpectations

bject 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 wrote: > >> >> On Aug 18, 2012, at 1:08 AM, Filip Pizl

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling "failing" layout tests and TestExpectations

for marking an expected failure reult. Regards, Maciej > > -- Dirk > > On Fri, Aug 17, 2012 at 6:51 PM, Ojan Vafai wrote: >> That matches my understanding. You proposed modification sounds fine to me. >> >> On Fri, Aug 17, 2012 at 6:40 PM, Maciej Stachowiak wrote:

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling "failing" layout tests and TestExpectations

On Aug 21, 2012, at 3:23 PM, Ojan Vafai wrote: > On Mon, Aug 20, 2012 at 6:03 PM, Maciej Stachowiak 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) Ar

Re: [webkit-dev] Initializing String and AtomicString with literals

What's the difference between the ASCIILiteral and ConstructFromLiteral versions? - Maciej On Aug 24, 2012, at 8:00 PM, Benjamin Poulain wrote: > Dear webkit-dev, > > > Some recent changes improved the way we can use string classes with literals. > > There are 3 new constructors for initi

Re: [webkit-dev] Initializing String and AtomicString with literals

On Aug 24, 2012, at 10:18 PM, Adam Barth wrote: > The wiki page says: > > [[[ > The difference between the version is if the length of the string is > included or not. Having the size given in the constructor makes the > constructor faster. Having the size also makes the code bigger, which > is

Re: [webkit-dev] Is the New XMLParser dead?

simplicity win 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 wrote: >> >> On Mar 15, 2012, at 1:29 PM, Er

Re: [webkit-dev] Is the New XMLParser dead?

On Aug 27, 2012, at 3:48 PM, Adam Barth wrote: > On Mon, Aug 27, 2012 at 3:06 PM, Maciej Stachowiak wrote: >> On Aug 27, 2012, at 2:45 PM, Eric Seidel wrote: >>> Checking back in: >>> >>> Curious if this effort is still underway. Adam and I would like

Re: [webkit-dev] Is the New XMLParser dead?

On Aug 27, 2012, at 4:28 PM, Adam Barth wrote: > On Mon, Aug 27, 2012 at 4:02 PM, Maciej Stachowiak wrote: >> On Aug 27, 2012, at 3:48 PM, Adam Barth wrote: >>> On Mon, Aug 27, 2012 at 3:06 PM, Maciej Stachowiak wrote: >>>> On Aug 27, 2012, at 2:45 PM, Eric Seid

Re: [webkit-dev] Is the New XMLParser dead?

On Aug 27, 2012, at 5:02 PM, Adam Barth wrote: > On Mon, Aug 27, 2012 at 4:46 PM, Dirk Schulze 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 back to it. Seems like well

Re: [webkit-dev] Proposal: WTF HashMap iterators to use key/value instead first/second

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 Oliveir

Re: [webkit-dev] String::operator+= considered harmful

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 StringBu

Re: [webkit-dev] String::operator+= considered harmful

On Sep 4, 2012, at 4:44 PM, Dirk Schulze 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 > better to try to

Re: [webkit-dev] String::operator+= considered harmful

On Sep 4, 2012, at 5:16 PM, Mike Lawther wrote: > On 5 September 2012 09:44, Dirk Schulze 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 earlier :) > > If operator+= cannot be made

Re: [webkit-dev] Removing the prefix from webkitPostMessage

On Sep 12, 2012, at 5:10 PM, Adam Barth 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 >

Re: [webkit-dev] Removing the prefix from webkitPostMessage

On Sep 12, 2012, at 5:51 PM, Adam Barth wrote: > On Wed, Sep 12, 2012 at 5:34 PM, Maciej Stachowiak wrote: >> On Sep 12, 2012, at 5:10 PM, Adam Barth wrote: >>> I've posted a patch to delete webkitPostMessage in favor of the >>> identically behaving, unpref

Re: [webkit-dev] Removing the prefix from webkitPostMessage

On Sep 12, 2012, at 6:17 PM, Adam Barth 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 >

Re: [webkit-dev] Removing the prefix from webkitPostMessage

On Sep 12, 2012, at 10:36 PM, Ojan Vafai wrote: > On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak 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, and so can

Re: [webkit-dev] Removing webkitSlice (was Re: Existing metrics for deprecated features)

On Sep 13, 2012, at 11:15 PM, Darin Fisher wrote: > > > On Thu, Sep 13, 2012 at 6:16 PM, Adam Barth wrote: > On Thu, Sep 13, 2012 at 5:13 PM, Adam Barth wrote: > > Another metric we have is for Blob.webkitSlice: > > > > Ratio of Blob.webkitSlice calls to Blob.slice: 14.87% > > Ratio of Blob.

Re: [webkit-dev] unsigned vs unsigned int

On Sep 16, 2012, at 2:30 AM, Allan Sandfeld Jensen wrote: > On Thursday 13 September 2012, Dan Bernstein wrote: >> On Sep 13, 2012, at 1:29 AM, Kenneth Rohde Christiansen > wrote: >>> Hi there, >>> >>> I was telling people to use "unsigned" instead of "unsigned int", as I >>> have been told t

Re: [webkit-dev] Pre-proposal: Adding a Coverity instance for WebKIt

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 limite

Re: [webkit-dev] Pre-proposal: Adding a Coverity instance for WebKIt

On Sep 17, 2012, at 8:13 PM, Hajime Morrita 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 because it can also

Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)

On Sep 21, 2012, at 4:30 PM, Adam Barth wrote: > On Wed, Sep 12, 2012 at 7:13 PM, Adam Barth wrote: >> On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak wrote: >>> That seems like a reasonable approach to gathering usage data indirectly, >>> so I'd say that t

Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)

On Sep 21, 2012, at 5:34 PM, Adam Barth wrote: > On Fri, Sep 21, 2012 at 5:21 PM, Maciej Stachowiak wrote: > > Yeah, "obligation" is probably too loaded a word. Here's some updated text: > > [[ > * Standards citizenship. Many W3C working groups, including

Re: [webkit-dev] New Feature: Canvas Path object

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 wrote: > > > On Sep 24, 2012, at 12:03 PM, "Rik Cabanier" wrote: > >>

Re: [webkit-dev] Constructors for DOM4 Events

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

Re: [webkit-dev] Time to remove LIKELY and UNLIKELY macros?

On Oct 1, 2012, at 10:55 PM, Adam Barth wrote: > According to > , > __builtin_expect (what our LIKELY and UNLIKELY macros expand to [1]) > doesn't do anything on modern C

Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)

argument could 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 wrote: > [+Tab] > > On Fri, Sep 21, 2012 at 5:50 PM, Maciej Stachowiak wrote: >>

Re: [webkit-dev] Remove support for -webkit-auto as a specifiable value for CSS text-align property?

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: Note that 'text-align: -webkit-auto' can have an effect even if

Re: [webkit-dev] HbbTV support within Webkit

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

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

On Oct 8, 2012, at 5:28 PM, Adam Barth wrote: > On Mon, Oct 8, 2012 at 2:17 PM, Brady Eidson wrote: >> On Oct 8, 2012, at 12:17 PM, Adam Barth wrote: >>> >>> Would there be any design or implementation constraints on WebCore? >>> For example, would WebCore need to understand any concurrency o

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

On Oct 9, 2012, at 1:24 PM, Adam Barth wrote: > On Tue, Oct 9, 2012 at 12:17 PM, Antti Koivisto wrote: >> On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth wrote: >>> This is interesting data, but it seems to be related to whether we >>> should make the MemoryCache content addressable rather than wh

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

On Oct 9, 2012, at 1:50 PM, Adam Barth wrote: > > That raises the question of what the cache-size to hit-rate curve > looks like. I don't think that's something we've ever measured for > the MemoryCache, but it would be interesting to know, for example, > whether increasing the cache size by 4

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

On Oct 10, 2012, at 8:49 AM, Adam Barth wrote: > On Wed, Oct 10, 2012 at 12:04 AM, Maciej Stachowiak wrote: >> On Oct 9, 2012, at 1:50 PM, Adam Barth wrote: >>> That raises the question of what the cache-size to hit-rate curve >>> looks like. I don't t

Re: [webkit-dev] HbbTV support within Webkit

On Oct 11, 2012, at 7:40 AM, Mark Toller wrote: >> -Original Message- >> From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com] >> >> On 10/10/2012 10:26 AM, Mark Toller wrote: >>> What we would like to see initially is Webkit based browsers (Chrome, >>> Safari, Minibrowser, etc)

Re: [webkit-dev] Unprefixing requestAnimationFrame

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 wrote: > I agree with what Adam wrote in > https://bugs.webkit.org/show_bug.cgi?id=99116#c5. Even if a lot of sites > will magically fa

Re: [webkit-dev] recompilation in dfg

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 wrote: > Hi. > I have some example in which my function recompiling in dfg jit (it's parsing > in second time without OS

Re: [webkit-dev] 8 Bit String Handling in Render Text Code

On Oct 15, 2012, at 9:56 AM, Michael Saboff 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 > render path is d

Re: [webkit-dev] build-webkit stopped working for me

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 bei

Re: [webkit-dev] On returning mutable pointers from const methods

On Oct 25, 2012, at 12:48 PM, Andreas Kling wrote: > > So, I propose that we allow only these two signature formats for raw pointers: > > - const Foo* foo() const; > - Foo* foo(); > > Moreover, for methods that return references to objects where call sites are > expected to take a strong ref

Re: [webkit-dev] On returning mutable pointers from const methods

On Oct 26, 2012, at 7:21 PM, Rik Cabanier wrote: > > > On Fri, Oct 26, 2012 at 9:06 AM, Peter Kasting wrote: > On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier wrote: > It is valid for a const method to return you a new object ie a const factory > object. > In that case, const-ness would not

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa 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 could > make a l

Re: [webkit-dev] On returning mutable pointers from const methods

On Oct 28, 2012, at 10:09 PM, Peter Kasting wrote: > On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak 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 to mutable > internal

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

On Oct 28, 2012, at 3:30 PM, Antti Koivisto 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 > cached cas

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

On Oct 28, 2012, at 10:09 PM, Dirk Pranke wrote: > > On Sun, Oct 28, 2012 at 6:32 AM, Maciej Stachowiak wrote: >> >> I think the nature of loader and cache code is that it's very hard to make >> tests which always fail deterministically when regressions are

Re: [webkit-dev] On returning mutable pointers from const methods

On Oct 29, 2012, at 3:47 PM, Antti Koivisto 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 doesn't make >

Re: [webkit-dev] moving focus when clicking on scrollbars

On Oct 31, 2012, at 9:32 PM, Ojan Vafai 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 browser engine, ex

Re: [webkit-dev] Making more use of ScriptWrappable

On Nov 1, 2012, at 6:36 PM, Adam Barth 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 of objects, we

Re: [webkit-dev] Making more use of ScriptWrappable

On Nov 2, 2012, at 12:45 AM, Adam Barth wrote: > On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak 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 >&g

Re: [webkit-dev] Slide deck: How WebKit Works

These slides present the information really well. Thanks for sharing them. Cheers, Maciej On Oct 31, 2012, at 7:30 PM, Adam Barth wrote: > Below are some slides I presented yesterday that give a high-level > overview of how WebKit works: > > https://docs.google.com/presentation/pub?id=1ZRIQbU

Re: [webkit-dev] …Inlines.h vs …InlineMethods.h

On Nov 3, 2012, at 1:48 AM, Mark Lam wrote: > FYI, some time in the near future (maybe this weekend), I plan to do some > work to break inline methods in JavaScriptCore out of header files into their > own inline header files. > > Naming-wise, the existing JSC code has a few inline headers na

Re: [webkit-dev] Making more use of ScriptWrappable

On Nov 5, 2012, at 5:07 PM, Adam Barth wrote: > > On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak wrote: >> Sounds like a good idea. Three additional thoughts: >> >> (1) It would be best to choose the objects to apply this to in some >> data-driven way. >

Re: [webkit-dev] Adding Web Animations to WebCore

I don't think we should support this API in WebKit at this time, because: * At least in its current form, it is overengineered and unusable. An animation API should focus on ease of use, not combining every conceivable animation concept ever invented. * It hasn't even reached FPWD yet so it's n

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

You could either put the code in the headers for the relevant classes, or the base mechanism in WTF and specific overloads in a catchall header for WebCore. You don't have to put the basic mechanism in WebCore just to have overloads for WebCore types. - Maciej On Nov 9, 2012, at 9:29 AM, Raf

Re: [webkit-dev] Adding blending mode to WebKit canvas

On Nov 11, 2012, at 6:59 PM, Rik Cabanier wrote: > > > > Wouldn't it be better to add a new property to canvas for blending? At the > beginning, implementations are just require to use different blend modes in > combination with 'source-over'. > > That could work too. > There was a maili

Re: [webkit-dev] Adding blending mode to WebKit canvas

On Nov 11, 2012, at 9:06 PM, Rik Cabanier wrote: > > > On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak wrote: > > On Nov 11, 2012, at 6:59 PM, Rik Cabanier wrote: > >> >> >> >> Wouldn't it be better to add a new proper

Re: [webkit-dev] Adding blending mode to WebKit canvas

ly when it is all defined in the same spec. Regards, Maciej > > Rik > > On Mon, Nov 12, 2012 at 3:46 PM, Rik Cabanier wrote: > > > On Mon, Nov 12, 2012 at 12:14 PM, Maciej Stachowiak wrote: > > On Nov 11, 2012, at 9:06 PM, Rik Cabanier wrote: > >> >

<    1   2   3   4   5   6   7   8   9   10   >