Re: [webkit-dev] Do we have a style preference about const member functions?

2011-05-31 Thread Maciej Stachowiak
On May 30, 2011, at 4:19 PM, Geoffrey Garen wrote: Updated: Const member functions: Do use const member functions in classes that are independent data holders, to help distinguish between references that can modify the data and references that can't. Do not use const member

Re: [webkit-dev] Do we have a style preference about const member functions?

2011-05-31 Thread Maciej Stachowiak
On May 31, 2011, at 10:54 AM, Peter Kasting wrote: On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak m...@apple.com wrote: A linked list node or tree node could useful have const methods, which give only const pointers/references to other nodes. If there is a reason const references

Re: [webkit-dev] Do we have a style preference about const member functions?

2011-05-31 Thread Maciej Stachowiak
On May 31, 2011, at 12:08 PM, Geoffrey Garen wrote: I agree that const should be used for logical constness. The rule should not be merely doesn't alter any data members of this object but rather does not alter observable state of this object or vend any type of pointer or reference by

Re: [webkit-dev] Do we have a style preference about const member functions?

2011-05-31 Thread Maciej Stachowiak
On May 31, 2011, at 5:55 PM, Brent Fulgham wrote: Hi, On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak m...@apple.com wrote: I agree that one useful distinction is whether a particular kind of object is every manipulated via const pointers or references. If we never use const references

Re: [webkit-dev] Do we have a style preference about const member functions?

2011-06-01 Thread Maciej Stachowiak
On May 31, 2011, at 10:00 PM, Brent Fulgham wrote: On May 31, 2011, at 8:44 PM, Maciej Stachowiak wrote: For example, the compiler does not tell you that the following implementation of Node::previousSibling() (currently in our code!) is totally wrong from the logical const perspective

Re: [webkit-dev] Do we have a style preference about const member functions?

2011-06-02 Thread Maciej Stachowiak
On Jun 1, 2011, at 8:11 PM, James Robinson wrote: On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen gga...@apple.com wrote: I agree that const should be used for logical constness. The rule should not be merely doesn't alter any data members of this object but rather does not alter

[webkit-dev] LocalStorage spec and structured cloning

2011-06-02 Thread Maciej Stachowiak
Does anyone have an opinion on this Web Storage spec bug? The input of the WebKit community is desired. And probably Safari and Chrome folks in particular, if opinions differ. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that

Re: [webkit-dev] LocalStorage spec and structured cloning

2011-06-02 Thread Maciej Stachowiak
. Of course, one answer is that people should just use IndexedDB. FWIW, Jorlow (when he was still working on chrome) expressed similar sentiments. On Jun 2, 2011 4:13 PM, Maciej Stachowiak m...@apple.com wrote: Does anyone have an opinion on this Web Storage spec bug? The input

Re: [webkit-dev] Do we have a style preference about const member functions?

2011-06-03 Thread Maciej Stachowiak
On Jun 3, 2011, at 7:50 AM, Darin Adler wrote: On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote: All functions passed to enclosingNodeOfType in htmlediting.cpp are such clients: Node* enclosingNodeOfType(const Position p, bool (*nodeIsOfType)(const Node*), EditingBoundaryCrossingRule

Re: [webkit-dev] Do we have a style preference about const member functions?

2011-06-08 Thread Maciej Stachowiak
On Jun 7, 2011, at 4:22 PM, Darin Adler wrote: I think the “make some things non-const” part of this would be the first part to put up for review and land. To expand on Darin's remark in two different ways: 1) We definitely have consensus to fix the broken non-logically-const accessors by

Re: [webkit-dev] Do we have a style preference about const member functions?

2011-06-09 Thread Maciej Stachowiak
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote: On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com wrote: 1) We definitely have consensus to fix the broken non-logically-const accessors by making them non-const; consensus on also adding const accessors is less clear

Re: [webkit-dev] Do we have a style preference about const member functions?

2011-06-09 Thread Maciej Stachowiak
On Jun 9, 2011, at 11:13 AM, Peter Kasting wrote: On Thu, Jun 9, 2011 at 2:49 AM, Maciej Stachowiak m...@apple.com wrote: I'm not really convinced that casting away const from a return value is intrinsically safer than casting away const from this. Allowing the caller to mutate the return

Re: [webkit-dev] JS bindings: Adding EventTarget to the prototype chain

2011-06-09 Thread Maciej Stachowiak
I don't have a personal opinion on which way is technically better myself. But I think the key is getting our code aligned with where standards are going, wether by changing he code or the standards. EventTarget in the prototype chain seems neither especially awesome nor especially terrible to

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

2011-06-09 Thread Maciej Stachowiak
On Jun 9, 2011, at 3:00 PM, Tony Chang wrote: On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig wei...@apple.com wrote: Why should we implement this spec? We already have one flex box implementation that we can never remove (and corresponds closely to Firefox's) so it seems to me that we should

Re: [webkit-dev] Implementing new WebSocket protocol

2011-06-14 Thread Maciej Stachowiak
Getting on the latest protocol in place would be great, so long as we minimize the risk of anyone shipping a halfway mix. - Maciej On Jun 14, 2011, at 10:47 AM, Ian Fette (イアンフェッティ) wrote: I thought Kitamura-san had patches mostly ready to switch us over? Either way, I agree we don't want

Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more

2011-06-18 Thread Maciej Stachowiak
On Jun 18, 2011, at 5:52 PM, Darin Adler wrote: 1: Recently, Alexey has encouraged me to use PassRefPtr less for function arguments. The PassRefPtr optimization pays off when the object in question is possibly being handed off from one PassRefPtr to another. For an argument, that can

Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more

2011-06-19 Thread Maciej Stachowiak
On Jun 18, 2011, at 10:47 PM, Alexey Proskuryakov wrote: 18.06.2011, в 22:15, Maciej Stachowiak написал(а): - I think having a rule for using PassRefPtr for arguments that depends on how callers use the function is likely to be hard to use in practice, since it requires global

Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more

2011-06-20 Thread Maciej Stachowiak
. Note that I listed using PassRefPtr for arguments less often (but not never) as a separate option. On Jun 18, 2011, at 10:58 PM, Maciej Stachowiak wrote: (1) Use PassRefPtr for every parameter that takes ownership. I still think this is the appropriate rule, and always have, but I think

Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more

2011-06-20 Thread Maciej Stachowiak
On Jun 20, 2011, at 9:19 AM, Alexey Proskuryakov wrote: 20.06.2011, в 03:22, Maciej Stachowiak написал(а): For a shared ownership model there are multiple possible definitions of whether a function takes ownership to an object passed as an argument. Here are some of my attempts

Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore

2011-06-28 Thread Maciej Stachowiak
On Jun 27, 2011, at 9:49 AM, Ojan Vafai wrote: Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just

Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore

2011-06-28 Thread Maciej Stachowiak
On Jun 28, 2011, at 12:22 PM, Ojan Vafai wrote: On Tue, Jun 28, 2011 at 10:10 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 27, 2011, at 9:49 AM, Ojan Vafai wrote: Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail

Re: [webkit-dev] Writing a new XML parser with no external libraries

2011-06-28 Thread Maciej Stachowiak
Consolidating replies to avoid spamming the thread: On Jun 28, 2011, at 6:26 PM, Adam Barth wrote: A question and a comment: 1) Will this let us to remove the code for both the libxml2 and the QtXml parsers? I'd certainly much rather have one XML parser than three. If the new parser

Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing

2011-06-29 Thread Maciej Stachowiak
On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote: On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an

Re: [webkit-dev] Writing a new XML parser with no external libraries

2011-06-29 Thread Maciej Stachowiak
On Jun 29, 2011, at 2:13 AM, Konstantin Tokarev wrote: 29.06.2011, 07:42, TAMURA, Kent tk...@chromium.org: I'm a little negative of developing a new XML parser. I'm afraid that the new parser introduces a lot of security/stability problems which existing parsers already resolved. How

Re: [webkit-dev] Writing a new XML parser with no external libraries

2011-06-29 Thread Maciej Stachowiak
On Jun 29, 2011, at 7:14 AM, Alex Milowski wrote: On Tue, Jun 28, 2011 at 10:10 PM, Dirk Schulze k...@webkit.org wrote: Am 29.06.2011 um 05:42 schrieb TAMURA, Kent: I'm a little negative of developing a new XML parser. I'm afraid that the new parser introduces a lot of

Re: [webkit-dev] Does NRWT let you indicate that a test should fail with a particular failure diff?

2011-07-05 Thread Maciej Stachowiak
On Jul 5, 2011, at 12:29 PM, Dirk Pranke wrote: The problem with your idea is I think what brought this idea up in the first place: if you just track that the test is failing using the test_expectations.txt file, but don't track *how* it is failing (by using something like the -failing.txt

Re: [webkit-dev] Does NRWT let you indicate that a test should fail with a particular failure diff?

2011-07-06 Thread Maciej Stachowiak
On Jul 5, 2011, at 4:51 PM, Dirk Pranke wrote: On Tue, Jul 5, 2011 at 3:46 PM, Ojan Vafai o...@chromium.org wrote: We could simplify the syntax somewhat to not require the = PASS at the end. We could also change the bug format to be actual links instead (e.g. webkit.org/b/12345 and

Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)

2011-07-07 Thread Maciej Stachowiak
On Jul 7, 2011, at 10:03 AM, Eric Seidel wrote: I do not know the history as to why Chromium removed support for test_expectations cascading. Ideally we would have fewer test expectations, not more in the future. :) The cascading is really really useful for supporting multiple different

Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)

2011-07-07 Thread Maciej Stachowiak
On Jul 7, 2011, at 10:39 AM, Dirk Pranke wrote: On Thu, Jul 7, 2011 at 10:27 AM, Tony Chang t...@chromium.org wrote: One difference with the chromium port is that we try to use a single test_expectations.txt that covers all platforms and OS versions (win xp, vista, 7, mac leopard, snow

Re: [webkit-dev] LayoutTests results fallback graph

2011-07-11 Thread Maciej Stachowiak
On Jul 10, 2011, at 12:11 PM, Adam Barth wrote: On Sun, Jul 10, 2011 at 12:01 PM, James Robinson jam...@google.com wrote: On Jul 10, 2011 10:53 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, In trying to understand how our LayoutTest results system works, I've created a digram of

Re: [webkit-dev] LayoutTests results fallback graph

2011-07-11 Thread Maciej Stachowiak
On Jul 10, 2011, at 3:55 PM, Adam Barth wrote: Because the LayoutTest fallback graph is a mess, hence this email thread. :) More proximately, because when the chromium-mac-leopard (for example) fallback path flows through mac-leopard, it flows to mac-snowleopard alongside the fallback

Re: [webkit-dev] Current legacy argument refactoring -- behavior changes?

2011-08-05 Thread Maciej Stachowiak
Hi Adam, I have a hard time reading this wall of text, but it seems to me there were at least three things wrong with what happened: 1) Patches mixing refactoring and behavior changes. This is bad. We should aim whenever possible to separate behavior changes from refactoring. Reviewers

Re: [webkit-dev] Current legacy argument refactoring -- behavior changes?

2011-08-05 Thread Maciej Stachowiak
On Aug 5, 2011, at 1:39 PM, Adam Barth wrote: My proposal is to revert all the patches that changed behavior without incorporating tests, and we can decide how to proceed from there. If it's hard to even tell which those are, then we should just revert the whole patch set. Then we can

Re: [webkit-dev] Chromium Mac moving to Skia

2011-08-16 Thread Maciej Stachowiak
On Aug 16, 2011, at 11:31 AM, Adam Barth wrote: Hi WebKit, In an effort to make the Chromium port more consistent across platforms, we're moving the Chromium Mac port from CoreGraphics to Skia. This should mostly have little effect on the rest of the WebKit community, but you'll be

Re: [webkit-dev] RefPtr/PassRefPtr Question

2011-09-06 Thread Maciej Stachowiak
On Aug 31, 2011, at 3:31 PM, David Levin wrote: Ignore me. I'm missing the . I suppose if you want a RefPtr, then the style checker is wrong and the parameter should be allowed to be a RefPtr. Feel free to file a bug and I'll get to it (-- it may take me a week or two at the moment).

Re: [webkit-dev] make-script-test-wrappers not being maintained

2011-09-08 Thread Maciej Stachowiak
On Sep 7, 2011, at 4:58 PM, Ojan Vafai wrote: On Wed, Sep 7, 2011 at 4:48 PM, Alexey Proskuryakov a...@webkit.org wrote: 16.08.2011, в 17:45, Alexey Proskuryakov написал(а): I think that a style bot rule complaining about new files in script-tests directories (outside fast/js) would

Re: [webkit-dev] make-script-test-wrappers not being maintained

2011-09-12 Thread Maciej Stachowiak
On Sep 8, 2011, at 11:15 AM, Eric Seidel wrote: It seems the sucessfullyParsed question could also be answered by some intelligent onerror handler added to the right script tag. The successfullyParsed thing was originally added to benefit JS tests running in the browser. If you get a bunch

Re: [webkit-dev] Implementing style scoped

2011-09-12 Thread Maciej Stachowiak
On Sep 8, 2011, at 2:28 PM, Roland Steiner wrote: Hi all, After several discussions on the whatwg@ mailing list and others, we would like to go forward with adding style scoped to WebKit. Overview: Style rules within style scoped only apply to the parent element of style scoped

Re: [webkit-dev] run-bindings-tests

2011-09-12 Thread Maciej Stachowiak
On Sep 8, 2011, at 12:25 PM, Darin Adler wrote: On Sep 8, 2011, at 11:49 AM, Alexey Proskuryakov wrote: As discussed on IRC, I do not think that bots should run this test at all. It has a non-trivial maintenance cost, but provides very little benefit. Even the time spent by multiple

Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit

2011-10-13 Thread Maciej Stachowiak
On Oct 12, 2011, at 4:12 PM, Ryosuke Niwa wrote: Given that Gecko is implementing the unprefixed getItems (see https://bugzilla.mozilla.org/show_bug.cgi?id=591467), I don't see benefits in implementing with webkit prefix. Also, it's still under a compile-time flag so we can prefix it

Re: [webkit-dev] Add a set of new APIs for the Custom Scheme and Content Handler.

2011-11-29 Thread Maciej Stachowiak
On Nov 28, 2011, at 8:54 PM, DongWoo Im wrote: Hi webkit-dev, I would like to let you know that I'm planning to add a set of new APIs for the Custom Scheme and Content Handler. ** Specification link : http://dev.w3.org/html5/spec/Overview.html#custom-handlers ** Bugs - Custom

Re: [webkit-dev] CORS Access-Control-Expose-Headers not supported by webkit?

2011-11-29 Thread Maciej Stachowiak
On Nov 21, 2011, at 2:00 PM, Ojan Vafai wrote: Just curious, how is it different from Access-Control-Allow-Headers? Access-Control-Allow-Headers is a response header which signals that specific custom request headers may be sent by the client.

Re: [webkit-dev] Add a set of new APIs for the Custom Scheme and Content Handler.

2011-11-29 Thread Maciej Stachowiak
Looks like I was mistaken and misread the spec, so I withdraw this comment. Do other browsers that implement the register functions also implement the related isRegistered and unregister functions? - Maciej On Nov 29, 2011, at 12:08 AM, Maciej Stachowiak wrote: On Nov 28, 2011, at 8:54

Re: [webkit-dev] Using Go in WebKit

2011-12-08 Thread Maciej Stachowiak
I think it would be good to limit the number of languages used for WebKit development. We already have important tools that use all of Perl, Python and Ruby. To date, we've been gradually converging on new scripts being mostly in Python. I think it would be really valuable for the project.

Re: [webkit-dev] Implementing Shadow DOM spec in WebKit

2012-01-11 Thread Maciej Stachowiak
Hi Dmitri! I remember last time this came up, there was some controversy, both within the WebKit community and among browser implementors more broadly. Kudos for writing a much more comprehensive spec and taking more of the feedback into account. For example, I am delighted to see that there

Re: [webkit-dev] Changing the implementation of KURL

2012-01-27 Thread Maciej Stachowiak
On Jan 27, 2012, at 12:22 AM, Darin Fisher wrote: On Fri, Jan 27, 2012 at 12:03 AM, Benjamin Poulain benja...@webkit.org wrote: On Thu, Jan 26, 2012 at 11:17 PM, Darin Fisher da...@chromium.org wrote: Instead of doing all of this work, have you considered just treating GoogleURL in much

Re: [webkit-dev] Changing the implementation of KURL

2012-01-27 Thread Maciej Stachowiak
On Jan 27, 2012, at 2:39 AM, Adam Barth wrote: On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL

Re: [webkit-dev] Changing the implementation of KURL

2012-01-28 Thread Maciej Stachowiak
, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should

Re: [webkit-dev] Changing the implementation of KURL

2012-01-29 Thread Maciej Stachowiak
On Jan 28, 2012, at 8:01 PM, Darin Fisher wrote: Right. In Firefox, the problem was that the cookie code used some hand-rolled string parsing code instead of reusing the URL parsing code. That resulted in a subtle bug that could be exploited to steal cookies. In Safari's case, I

Re: [webkit-dev] Removing HTML notifications from WebKit (Was: Web Notifications API)

2012-02-08 Thread Maciej Stachowiak
On Feb 8, 2012, at 6:15 PM, Aaron Boodman wrote: On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee jon...@apple.com wrote: 2. Remove HTML notifications. It has been removed from the spec, and we don't intend on ever supporting HTML notifications. I brought this issue up before; is there an update on

Re: [webkit-dev] Removing HTML notifications from WebKit (Was: Web Notifications API)

2012-02-13 Thread Maciej Stachowiak
This plan sounds reasonable to me. No disruption of Chrome extensions in the short term, but we would better align with each other and with standards in the longer term. Jon? Regards, Maciej On Feb 9, 2012, at 2:48 PM, Aaron Boodman wrote: On Wed, Feb 8, 2012 at 7:50 PM, Maciej Stachowiak

Re: [webkit-dev] JavaScriptCore Debugger - Non-Browser Implementation

2012-02-13 Thread Maciej Stachowiak
On Feb 7, 2012, at 10:18 PM, Matt Veenstra wrote: Hello, I am looking for a tool to help debug JavaScript code for JavaScriptCore when NOT using a browser? I did a bit of research and did not find anything that seems to attach and debug at a code level and ignore the DOM. Is there

Re: [webkit-dev] When should we turn on new features?

2012-02-13 Thread Maciej Stachowiak
On Feb 10, 2012, at 4:09 PM, Ryosuke Niwa wrote: Hi all, In general, the decision of whether a given feature is enabled or not is made by each port. However, at last year's W3C TPAC, there were complaints from other participants about WebKit shipping half-baked implementations and

Re: [webkit-dev] test_expectations.txt for non-chromium ports

2012-02-13 Thread Maciej Stachowiak
On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote: I think at one point Adam indicated he wanted to use them for the Apple Win port, but he is still using the Skipped files since the Win port is still using ORWT on the bots. That said, I understand why you're asking this (I think), but I

Re: [webkit-dev] test_expectations.txt for non-chromium ports

2012-02-13 Thread Maciej Stachowiak
On Feb 13, 2012, at 1:40 PM, Ojan Vafai wrote: On Mon, Feb 13, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote: For example, we might want to use only Skipped files for tests that are always planned to be skipped

Re: [webkit-dev] When should we turn on new features?

2012-02-13 Thread Maciej Stachowiak
On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote: On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another

Re: [webkit-dev] When should we turn on new features?

2012-02-13 Thread Maciej Stachowiak
. -- morrita On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote: On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: I think you raise a good point. Another point worth mentioning

Re: [webkit-dev] test_expectations.txt for non-chromium ports

2012-02-13 Thread Maciej Stachowiak
On Feb 13, 2012, at 3:22 PM, Ojan Vafai wrote: On Mon, Feb 13, 2012 at 3:09 PM, Maciej Stachowiak m...@apple.com wrote: I do agree that distinguishing test not applicable to this port from this test is temporarily failing for unknown reasons is a good thing to do. It is unfortunate

Re: [webkit-dev] test_expectations.txt for non-chromium ports

2012-02-13 Thread Maciej Stachowiak
On Feb 13, 2012, at 6:47 PM, Ryosuke Niwa wrote: On Mon, Feb 13, 2012 at 6:41 PM, Stephen White senorbla...@chromium.org wrote: On Mon, Feb 13, 2012 at 9:16 PM, Maciej Stachowiak m...@apple.com wrote: I don't know about other organizations, but from Apple's point of view, it's rare

Re: [webkit-dev] optimizing browser handling of Facebook Timeline scrolling

2012-02-14 Thread Maciej Stachowiak
On Feb 14, 2012, at 10:25 AM, Steven Young wrote: (2) 50% of time spent painting images... This is a simple speed vs quality tradeoff. If you down-sampled the images on the server, they'd download and paint much faster. Thanks. Downsampling sounds like a straightforward solution. We

Re: [webkit-dev] Including new IETestCenter tests in the LayoutTests

2012-02-15 Thread Maciej Stachowiak
On Feb 15, 2012, at 2:26 AM, Alexis Menard wrote: The code we submit in WebKit has to be BSD or LGPL compatible code. (/me remember how hard it is to find real world CSS BSD compatible chunk to write a perf test) I found http://msdn.microsoft.com/en-us/cc300389.aspx then you have to see

Re: [webkit-dev] Should we move methods from layoutTestController/etc... to internals?

2012-02-21 Thread Maciej Stachowiak
Would you move the interface objects or just the methods? - Maciej On Feb 21, 2012, at 12:15 PM, Ryosuke Niwa wrote: Hi, It appears to me window.internals is a superior solution to expose cross-platform features to our test harness compared to other interfaces implemented in

Re: [webkit-dev] Should we move methods from layoutTestController/etc... to internals?

2012-02-21 Thread Maciej Stachowiak
On Feb 21, 2012, at 1:21 PM, Ryosuke Niwa wrote: I'd prefer getting rid of the entire interface when possible. We're obviously removing layoutTestController, textInputController, etc... at the moment though. I think it's helpful to organize the methods by functional area instead of

Re: [webkit-dev] Should we move methods from layoutTestController/etc... to internals?

2012-02-21 Thread Maciej Stachowiak
On Feb 21, 2012, at 5:40 PM, Hajime Morrita wrote: Hi, Thanks for starting this discussion! To summarize, there is a rough consensus which is like: * A. LayoutTestController (LTC) is for control test harness. dumpAsText() and waitUntilDone() is great example of this. * B. EventSender

Re: [webkit-dev] WebKit modularization

2012-02-24 Thread Maciej Stachowiak
On Feb 24, 2012, at 9:57 AM, Alexey Proskuryakov wrote: 22.02.2012, в 22:08, Kentaro Hara написал(а): TL;DR: We are starting WebKit modularization. Self-contained features like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved from WebCore/ to WebCore/Modules/. Looking at

Re: [webkit-dev] Making DOMWindow less epic (was Re: WebKit modularization)

2012-02-24 Thread Maciej Stachowiak
On Feb 24, 2012, at 10:27 AM, Adam Barth wrote: 2012/2/24 Maciej Stachowiak m...@apple.com: I too am surprised that HTML-related APIs would be refactored as a result of modularization. This change may be justifiable on its own merits, but it doesn't seem like a logical part of a project

Re: [webkit-dev] Removing obsolete File attributes

2012-02-24 Thread Maciej Stachowiak
On Feb 24, 2012, at 11:52 AM, Darin Fisher wrote: As I mentioned in the bug, it is encouraging news that Mozilla has already removed these attributes (for a couple releases now). I would like to see them go away too. There's unfortunately, the real possibility that there may be some

Re: [webkit-dev] Making DOMWindow less epic (was Re: WebKit modularization)

2012-02-24 Thread Maciej Stachowiak
On Feb 24, 2012, at 11:58 AM, Adam Barth wrote: On Fri, Feb 24, 2012 at 11:50 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 24, 2012, at 10:27 AM, Adam Barth wrote: 2012/2/24 Maciej Stachowiak m...@apple.com: I too am surprised that HTML-related APIs would be refactored as a result

Re: [webkit-dev] Removing obsolete File attributes

2012-02-24 Thread Maciej Stachowiak
On Feb 24, 2012, at 12:06 PM, Darin Fisher wrote: On Fri, Feb 24, 2012 at 12:00 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 24, 2012, at 11:52 AM, Darin Fisher wrote: As I mentioned in the bug, it is encouraging news that Mozilla has already removed these attributes

Re: [webkit-dev] RDF related stuff in WebKit.

2012-02-28 Thread Maciej Stachowiak
I think many of us in the WebKit community are skeptical of the value of implementing RDFa on the client side, at least for now. The proposed API is rather complicated, the processing rules are quite complicated, and it's not clear there is demand for authors. HTML Microdata is a similar

Re: [webkit-dev] The Care and Feeding of WebCore Modules

2012-02-28 Thread Maciej Stachowiak
One thing that would be helpful to add is an explanation of what types of subsystems should be turned into Modules and what types should not. Also advantages and disadvantages of turning a particular piece of code into a Module. I think part of the confusion/controversy around these changes

Re: [webkit-dev] The Care and Feeding of WebCore Modules

2012-02-29 Thread Maciej Stachowiak
Here's an update of my lists based on the notes from you, Adam and others: == Existing Modules == gamepad geolocation indexeddb (work in progress) intents mediastream vibration websockets == Likely Future Modules == filesystem notifications pagevisibility protocolhandler websql webaudio ==

Re: [webkit-dev] CSS properties vs. their JS bindings on the style object

2012-03-01 Thread Maciej Stachowiak
I agree with Hyatt. It's not like this behavior is especially harmful or confusing. Authors are unlikely to run into properties with hyphens in the names unless they go looking. And it can be useful if you ever want to pass around actual CSS property names by string in an API - no need to

Re: [webkit-dev] scoping Node destruction during DOM modifications

2012-03-01 Thread Maciej Stachowiak
I agree with Adam's remarks. The safety benefit seems great, but we should investigate ways to get it at less performance cost (ideally no measurable cost). I'm also curious what impact this change has on less micro- but still DOM-oriented benchmarks, such as Dromaeo's DOM tests, Peacekeeper,

Re: [webkit-dev] Web Notifications update

2012-03-06 Thread Maciej Stachowiak
On Mar 6, 2012, at 9:00 PM, Jon Lee wrote: Whoops, I forgot to mention this also: I would like to add a new ENABLE(LEGACY_NOTIFICATION_DEPRECATION) flag which allows ports to deprecate the legacy API. This saves us from the hazards of refactoring the code to use a different ENABLE flag

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

2012-03-07 Thread Maciej Stachowiak
I'd prefer we not modify imported test suites. That will just make it more confusing to update. Perhaps future CSS test suites will be changed to a reftest model. Regards, Maciej On Mar 7, 2012, at 1:41 PM, Ojan Vafai wrote: I just did a first pass a greening the Chromium Lion bot:

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

2012-03-07 Thread Maciej Stachowiak
I too am mildly concerned about references not being sufficiently independent of the tests, which is why I hoped we could get the WG in the business of reviewing references along with tests. However, another possibility is looking at what Mozilla uses for reference for these tests, since those

Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Maciej Stachowiak
It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn. It seems like there are two possible changes we can make, and it is not really clear to me

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Maciej Stachowiak
Here's my thoughts based on this and other comments On Mar 8, 2012, at 2:30 PM, Alexis Menard wrote: To the global infrastructure : - Local history for git. svn log access to the server every time you call that command. Will improve the load of the server. - Performance of checkouts/pull

[webkit-dev] Version control survey

2012-03-09 Thread Maciej Stachowiak
Since the answer to this factual question seems to be of interest to some people, here's a survey about what version control tools people use to access the WebKit repository, and approximate contribution level. http://www.surveymonkey.com/s/JQMW2QV (Note that it doesn't ask about preference

Re: [webkit-dev] Version control survey

2012-03-09 Thread Maciej Stachowiak
wrote: Can you add an option for folks who use both git and SVN? I use both frequently. Thanks, Adam On Fri, Mar 9, 2012 at 10:20 PM, Maciej Stachowiak m...@apple.com wrote: Since the answer to this factual question seems to be of interest to some people, here's a survey about what

Re: [webkit-dev] Version control survey

2012-03-10 Thread Maciej Stachowiak
: Where can we see the results to date? Also there should be a closing date for the survey and it should also be announced to this DL. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Saturday

Re: [webkit-dev] Version control survey

2012-03-10 Thread Maciej Stachowiak
On Mar 10, 2012, at 10:56 AM, Ryosuke Niwa wrote: On Sat, Mar 10, 2012 at 10:05 AM, Maciej Stachowiak m...@apple.com wrote: Unfortunately SurveyMonkey sucks and I can't give everyone access to live responses without paying them money. Current results: - 97 people have answered - About

[webkit-dev] UPDATED Re: Version control survey

2012-03-10 Thread Maciej Stachowiak
, 2012, at 11:52 AM, Maciej Stachowiak wrote: On Mar 10, 2012, at 10:56 AM, Ryosuke Niwa wrote: On Sat, Mar 10, 2012 at 10:05 AM, Maciej Stachowiak m...@apple.com wrote: Unfortunately SurveyMonkey sucks and I can't give everyone access to live responses without paying them money. Current

Re: [webkit-dev] UPDATED Re: Version control survey

2012-03-10 Thread Maciej Stachowiak
Regards, Maciej On Mar 10, 2012, at 11:52 AM, Maciej Stachowiak wrote: On Mar 10, 2012, at 10:56 AM, Ryosuke Niwa wrote: On Sat, Mar 10, 2012 at 10:05 AM, Maciej Stachowiak m...@apple.com wrote: Unfortunately SurveyMonkey sucks and I can't give everyone access to live responses without

Re: [webkit-dev] Version control survey

2012-03-10 Thread Maciej Stachowiak
meant being listed on this page http://trac.webkit.org/wiki/WebKit%20Team even though I've landed 10+ patches. I don't want my vote to be discounted. I use git only. Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Maciej Stachowiak [mailto:m...@apple.com] Sent

Re: [webkit-dev] UPDATED Re: Version control survey

2012-03-10 Thread Maciej Stachowiak
with svn, or making everyone switch to git. My counter argument to git-svn is slow so we should all use git is git-svn is slow and this annoys me so i'm going to contribute patches to git to fix that. --Oliver On Mar 10, 2012, at 1:00 PM, Maciej Stachowiak wrote: I will also post

Re: [webkit-dev] Moving to Git?

2012-03-10 Thread Maciej Stachowiak
I think one factor that makes many people stick with SVN is that emulating the SVN-style workflow in Git is pretty complicated. Let's consider a typical SVN user's process: 1) Develop one patch at a time. 2) During development, often update his sources to match the repository. 3) When done,

Re: [webkit-dev] UPDATED Re: Version control survey

2012-03-10 Thread Maciej Stachowiak
and (I think) from which platforms. If there's interest, I can dig up what we did and see if we can use the same technique on our tools. -- Dirk On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com wrote: Hi folks, I made a bad choice of survey site. They want to charge me

Re: [webkit-dev] Moving to Git?

2012-03-10 Thread Maciej Stachowiak
On Mar 10, 2012, at 9:55 PM, Kalle Vahlman wrote: 2012/3/11 Maciej Stachowiak m...@apple.com: The interaction with the version-control system for each of these steps is an obvious single step with SVN. With git, for at least some of these, you will end up needing multiple non-obvious

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

2012-03-15 Thread Maciej Stachowiak
On Mar 15, 2012, at 1:29 PM, Eric Seidel wrote: It seems the New XML Parser hasn't been touched in about 8 months: http://trac.webkit.org/browser/trunk/Source/WebCore/xml/parser Are there any plans to continue work on such, or can it be removed? The refactoring which was done to support

Re: [webkit-dev] Upstreaming Support for W3C Sensor API

2012-03-16 Thread Maciej Stachowiak
I think this feature is pretty far out relative to WebKit project goals, even independent of spec maturity level. We've had controversy (though ultimately tentative agreement on adding) APIs for hardware found in some but not all classes of mainstream hardware that runs a browser. For

Re: [webkit-dev] Magic Iframe removal proposed

2012-03-20 Thread Maciej Stachowiak
I'm ok with removing this feature for the reasons you described. I concur with others who think we should update the spec. I am also skeptical of state sharing features that work via newer, less tested API surface instead of latching onto existing features. That seems like a more risky

Re: [webkit-dev] ChangeLogs

2012-03-21 Thread Maciej Stachowiak
On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote: Lately I have observed more and more and more changes going into WebKit that lack any details about why a particular change was made. It is intended that the ChangeLog (and commit message) contain some details about your change, not just

Re: [webkit-dev] ChangeLogs

2012-03-21 Thread Maciej Stachowiak
On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote: On Wed, Mar 21, 2012 at 2:33 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote: Lately I have observed more and more and more changes going into WebKit that lack any details about why

[webkit-dev] Version control survey results

2012-04-07 Thread Maciej Stachowiak
On Mar 22, 2012, at 9:16 PM, Adam Barth wrote: On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com wrote: I made a bad choice of survey site. They want to charge me to see more than 100 responses or to export the data, but they won't take my money. Sadness. Please try

Re: [webkit-dev] Is it OK to remove Frame::setIsDisconnected() and isDisconnected() ?

2012-04-09 Thread Maciej Stachowiak
On Apr 9, 2012, at 12:27 PM, Adam Barth wrote: On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 15, 2009, at 1:29 PM, Sverrir Á. Berg wrote: Hi Adam, Thanks for the links. These are simply exposing the functions as a formal a API's. I understand that you

Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

2012-04-16 Thread Maciej Stachowiak
On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote: Could this be an opportunity to design an asynchronous API for fetching the pixel buffer? It seems like many implementations are GPU backed now, and fetching the pixel buffer is an expensive (blocking) operation. Had you considered

Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

2012-04-16 Thread Maciej Stachowiak
On Apr 16, 2012, at 1:48 PM, Oliver Hunt wrote: On Apr 16, 2012, at 1:44 PM, Darin Fisher da...@chromium.org wrote: I'm not sure why developers would choose to ignore HiDPI. It seems like it helps their apps/pages look better! You really feel like you need to kowtow to developers to

Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

2012-04-16 Thread Maciej Stachowiak
On Apr 16, 2012, at 1:44 PM, Darin Fisher wrote: On Mon, Apr 16, 2012 at 1:42 PM, Oliver Hunt oli...@apple.com wrote: On Apr 16, 2012, at 1:00 PM, Darin Fisher da...@chromium.org wrote: On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 16, 2012, at 10:52

<    4   5   6   7   8   9   10   11   12   13   >