from:"Maciej Stachowiak"


On Sep 28, 2010, at 7:15 AM, Chris Marrin wrote:

 
 On Sep 27, 2010, at 6:37 PM, Maciej Stachowiak wrote:
 
 
 On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:
 
 Webkit's XHR currently does not keep two copies of the data that I can see. 
 I think we should avoid that.
 
 We could keep the raw data around, which hopefully is directly usable as an 
 ArrayBuffer backing store, and only translate it to text format when/if the 
 client requests responseText. 
 
 Yes, the raw data should be usable without translation in an ArrayBuffer. But 
 we'd still need to make a copy of the raw bits when a new ArrayBuffer is 
 created via responseArrayBuffer(), because that object is mutable.

Is there an immutable variant of ArrayBuffer? If not, we really need one. But 
even without that, note that you don't necessarily need to make an immediate 
copy, you can use copy-on-write.

The immutable variant would be helpful since we could avoid implementing 
threadsafe copy-on-write just to allow efficient passing of ArrayBuffers to 
Workers.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XHR responseArrayBuffer attribute


On Sep 28, 2010, at 11:05 AM, Kenneth Russell wrote:

 On Tue, Sep 28, 2010 at 9:45 AM, Maciej Stachowiak m...@apple.com wrote:
 
 On Sep 28, 2010, at 7:15 AM, Chris Marrin wrote:
 
 
 On Sep 27, 2010, at 6:37 PM, Maciej Stachowiak wrote:
 
 
 On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:
 
 Webkit's XHR currently does not keep two copies of the data that I can 
 see. I think we should avoid that.
 
 We could keep the raw data around, which hopefully is directly usable as 
 an ArrayBuffer backing store, and only translate it to text format when/if 
 the client requests responseText.
 
 Yes, the raw data should be usable without translation in an ArrayBuffer. 
 But we'd still need to make a copy of the raw bits when a new ArrayBuffer 
 is created via responseArrayBuffer(), because that object is mutable.
 
 Is there an immutable variant of ArrayBuffer? If not, we really need one. 
 But even without that, note that you don't necessarily need to make an 
 immediate copy, you can use copy-on-write.
 
 The immutable variant would be helpful since we could avoid implementing 
 threadsafe copy-on-write just to allow efficient passing of ArrayBuffers to 
 Workers.
 
 Chris has raised this issue on the public_webgl list, and we've begun
 discussion there, but I would like to point out that having an
 immutable ArrayBuffer and views on it does not help with the situation
 of passing data to or from a web worker. The side that constructs the
 data will necessarily have a mutable view, so it will be able to cause
 changes that can be seen on the other side even if the view on the
 other side is immutable.

Not if the side that got the data got it in immutable form in the first place. 
For example, if you get an immutable ArrayBuffer from XHR in a Worker, then you 
can pass it to another Worker or to the main thread without the need for any 
copying or copy-on-write.

 
 We have a design that will allow efficient zero-copy producer/consumer
 queues to be implemented using TypedArrays while maintaining
 ECMAScript's shared-nothing semantics. I'll be happy to sketch it out,
 but it's probably most appropriate for a mailing list like
 public_webgl.

I'm curious to hear it and I don't follow public_webgl.

I'd specifically like to handle the following case:
- You obtain a chunk of binary data from the network or filesystem and want to 
pass it to another thread without copying.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Should we recommend explicit constructors as part of WebKit style?


On Sep 28, 2010, at 4:26 PM, David Levin wrote:

 This came up before: 
 https://lists.webkit.org/pipermail/webkit-dev/2010-May/012873.html but I'd 
 like to understand it a bit better.
 
 It feels there were two points of view:
 Use explicit only when necessary to prevent an undesirable implicit 
 conversion like int to vector.
 Use explicit except when it is desirable to allow an implicit conversion that 
 makes the code simpler. For example, the String - AtomicString makes the 
 bindings generator code simpler since it doesn't need to know which the 
 underlying method takes.
 Are there any reasons beyond personal preference to select either of these?
 
 Starting list:
 
 Pro's for #1
   It is a pain to remember to put explicit every time you have a constructor 
 with one argument.
 
 Pro's for #2
It would prevent accidental mistakes that happen with implicit 
 constructors.

I think the rule should be something like:

  3. Do not explicit when the single-argument constructor can be thought of as 
a type conversion - the class will be in some sense an alternate form of its 
sole parameter. Do use explicit when the single-argument constructor is *not* 
reasonably thought of as a type conversion - the single argument just happens 
to be the sole initialization parameter. Or to put it another way - can you 
imagine having a type conversion operator overload that does the same thing as 
this constroctor?

Applying this rule to your two examples, Vector(int) should be explicit, 
because it doesn't convert the int to a vector, it uses the int as a size 
instead of the default one. But String(AtomicString) or AtomicString(String) 
need not be explicit, since they convert from one string type to another, 
carrying largely the same data.

I realize this rule requires some judgment, so it's worse than a purely 
mechanical rule, but I think it accurately captures the proper use of explicit.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] X-Purpose on prefetching requests


On Sep 28, 2010, at 4:16 PM, Adam Barth wrote:

 I guess I don't understand your perspective.  Are you arguing that
 prefetch is a misfeature and folks should use image tags instead?
 That doesn't really make sense to me.  For example, using an explicit
 prefect API means the prefetch gets properly prioritized and doesn't
 delay the load event.  Below you characterize prefetch as a hack, but
 it seems like a useful feature that's used by a bunch of sites.
 
 As for X-Purpose, sometimes you seem to be saying that it can't be
 used correctly, whereas other times you seem to be saying that it can
 be used correctly, just that sites will screw it up.  At the beginning
 of the discussion, you seemed worried about the size increase to
 requests.  Reading your messages, it feels like you don't like
 X-Purpose, but you're not quite sure why.  As the discussion
 progresses, your reasons for disliking it seem to shift.
 
 Server operators seem to be sad that we're don't have the same feature
 as Firefox.  I don't understand why we shouldn't make them happier.

I'll try to find out the reasons we added X-Purpose: preview to Safari's 
snapshot fetcher. If similar use cases apply to prefetch, then that seems like 
a strong argument to add X-Purpose: prefetch.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-27 Thread Maciej Stachowiak


On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:

 Webkit's XHR currently does not keep two copies of the data that I can see. I 
 think we should avoid that.

We could keep the raw data around, which hopefully is directly usable as an 
ArrayBuffer backing store, and only translate it to text format when/if the 
client requests responseText. 

 
 On Mon, Sep 27, 2010 at 2:40 PM, Anne van Kesteren 
 annevankeste...@gmail.com wrote:
 (I'm subscribed to webkit-dev with a different address.)
 
 On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman micha...@google.com wrote:
  Yes, if we go with telling xhr up front for the array buffer case, I guess
  an enum would be slightly better.
 
 I do not think this should be told up front. You already need to keep
 the octet buffer in memory for overrideMimeType to work the way it
 does. We designed responseBlob as an optimization so you would not
 have to deal with the other types. I do not think you can optimize the
 reverse with the design as it stands today.
 
 In any event, any discussion on changes to the specification really
 ought to happen on public-weba...@w3.org.
 
 Cheers,
 
 
 --
 Anne van Kesteren
 http://annevankesteren.nl/
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Review tool changes

2010-09-20 Thread Maciej Stachowiak


On Sep 20, 2010, at 10:22 AM, Darin Fisher wrote:

 On Mon, Sep 20, 2010 at 10:10 AM, Adam Barth aba...@webkit.org wrote:
 On Mon, Sep 20, 2010 at 8:37 AM, Alexey Proskuryakov a...@webkit.org wrote:
  16.09.2010, в 18:39, Darin Fisher написал(а):
  Push the publish button to review your comments :-)
 
  Alas, not any more!
 
  https://bugs.webkit.org/show_bug.cgi?id=46074
 
 Yeah.  The machinery is still there for the preview, I'm just not sure
 what the best UI is for triggering it.
 
 Adam
 
 
 How about this?
 
 If any annotations were made to the patch, then the button gets named 
 Preview.  Else, the button is named Publish and when clicked performs its 
 work in one shot.
 
 Was there a strong outcry for removing the preview step?  I only found it 
 bothersome when I wanted to issue a quick r=me on a patch that didn't require 
 any additional changes.


How about having both [Publish] and [Preview] buttons?

Or honestly, I think it would be fine to have just [Preview]. If a blog can 
require you to check what you posted before it appears in comments, then I 
think it is a reasonable requirement for a patch review system.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Testing XHR

2010-09-20 Thread Maciej Stachowiak


On Sep 20, 2010, at 10:19 PM, Ojan Vafai wrote:

 
 How about we create http/tests/xmlhttprequest/w3c-experimental or something 
 like that? That can tide us over until the official version comes out, at 
 which point, we can delete the w3c-experimental directory and just add a w3c 
 directory.
 
 It would be nice if we could start fixing these things before they become 
 part of the official test suite as a way of evaluating whether there are 
 issues with the spec and/or test suite.

That is in fact exactly what we should be doing at this stage of the standards 
process for XHR.

 
 Also, it seems to me like to does make sense to add an 
 update-experimental-w3c-xhr-tests script or something until there is an 
 official version.

Indeed. And even after the test suite is official, it is likely to expand over 
time. We should also look over our own XHR tests to see if there are any that 
it would make sense to contribute to the W3C.

Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Fwd: HTML5 MathML3 entities

2010-09-17 Thread Maciej Stachowiak

Forwarding this because it apparently didn't make it to the list.

Begin forwarded message:

 From: David Carlisle dav...@nag.co.uk
 Date: September 17, 2010 8:44:51 AM PDT
 To: webkit-dev@lists.webkit.org
 Cc: m...@apple.com
 Subject: Re: [webkit-dev] HTML5  MathML3 entities

 Not sure I can post to this list (hence cc to  Maciej)  but replying to the 
 thread from July

 http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11986.html

 there were a couple of points raised.

 * that rang changed definition

 and

 * entities expanding to more than once character not being supported.

 On the first:

 rang did not used to be (directly) a CJK character it was in the math symbol 
 block at 2329 but erroneously given a canonical decomposition to the CJK 
 block at 3008. Unicode recognised the error but never change canonical 
 decompositions so they deprecated 2320 and introduced a new character 27E8 
 that is the same apart from this decomposition.

 http://www.unicode.org/charts/PDF/U2300.pdf

 explicitly says these characters are deprecated:

 Also, even if Unicode had not deprecated 2329, the W3C Unicode Normal Form 
 bans entities using characters that have canonical decompositions as it makes 
 entity expansion and NFC canonicalisation interact badly. Changing the 
 definition is unfortunate but sort of inevitable given the history.

 On the second:
 It's probably worth noting that currently the HTML5 spec only lists entities 
 that expand to a single character, but there is an open bug entry about that:

 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10067

 David

 The Numerical Algorithms Group Ltd is a company registered in England
 and Wales with company number 1249803. The registered office is:
 Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

 This e-mail has been scanned for all viruses by Star. The service is
 powered by MessageLabs. 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] map.d.co.il broken - back out r66156?

2010-09-16 Thread Maciej Stachowiak


On Sep 16, 2010, at 9:14 AM, Jeremy Moskovich wrote:

 Hi,
 
 http://trac.webkit.org/changeset/66156/ broke map.d.co.il which is one of the 
 larger maps sites in Israel.
 
 https://bugs.webkit.org/show_bug.cgi?id=45679 was filed to track this.
 
 Andy: do you have an eta for a fix? Are you ok reverting the change in the 
 interim?

How about we take a shot at fixing it? We don't usually revert just because 
because one site is broken, even for more popular sites than this one. The 
original change fixed serious problems on multiple sites, including at least 
two Alexa top 500 sites, so I'm not sure reverting would even make WebKit more 
compatible on the whole.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation


On Sep 14, 2010, at 9:58 PM, Jian Li wrote:

 Indeed when I implement BlobResourceHandle, I have taken the range request 
 support into consideration and got it work. The problem is that current media 
 element implementation does not route through ResourceHandle.
 
 However, introducing a ResourceHandle subclass does not sound like an elegant 
 solution given that ResoucreHandle is currently treated as a wrapper class to 
 the underlying platform implementation. I agree it would be better if we 
 could find a way to avoid extra roundtrip to pop back to WebCore to do the 
 real handling. But I am not sure how this could be hooked up. The handling of 
 javascript: url is somewhat special. Probably we cannot do the similar thing 
 as it since the handling of blob: url needs to work closely with resource 
 loader and caching layer so that we can get it work in all scenarios.
 
 Do you have any good suggestion on what is the right layer to hook into? Does 
 it make sense if I move the current implementation of BlobResourceHandle to 
 the underlying platform layer for WebKit mac so that I can fix the issue with 
 incorrect subclassing of ResourceHandle?

Subclassing ResourceHandle is somewhat inelegant. It's not a class designed to 
be subclassed, and subclassing it correctly probably requires making more 
methods virtual. In addition, since the blob: URL scheme implementation needs 
to know about other parts of WebCore outside the platform/ directory, it's a 
bit of a layering violation to have a ResouceHandle subclass dealing with it.

One (maybe slightly odd) thought that came to me is that perhaps blob: can be 
handled at the ResourceLoader level. That is the level where higher-level 
concepts are allowed to take over the load - for example, app cache hooks in at 
this layer, as does WebArchive loading, and also the ability to load a premade 
data chunk as a web page instead of loading an actual URL. So in that regard, 
it's a natural place for higher-level Web platform concepts to take over the 
load. This would be different from the way we handle any other URL scheme, but 
one way or another, blob: needs to be special, so maybe that's ok.

Regards,
Maciej


 
 On Tue, Sep 14, 2010 at 6:21 PM, Maciej Stachowiak m...@apple.com wrote:
 
 On Sep 14, 2010, at 6:02 PM, Adam Barth wrote:
 
  On Tue, Sep 14, 2010 at 5:56 PM, David Levin le...@chromium.org wrote:
  On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth aba...@webkit.org wrote:
  What do you think of the idea of having a re-useable BlobCore module
  that all the ports can share?
 
  I don't think this is a good idea. This re-usable module would only be
  used by the Safari WebKit port. As I understand it, Chromium wouldn't be
  able to re-use it due to not re-using WebKit types in general. With only 
  one
  port using it, the module seems like it would not be able to have a good
  design.
 
  So if there is a change, it seems better to just write it for the Safari
  WebKit port and as other ports want to implement it, if they find
  commonality, it would be in their best interest to refractor the existing
  code for better re-use.
 
  Would Chromium be able to re-use the code if it were part of WebCore?
  I guess I don't understand what's different about those two cases.
 
  Another question, does this design allow blob URLs to be used by the
  video element?  My understanding is that video bypasses
  ResourceHandle because ResourceHandle isn't smart enough to handle
  range requests (or something like that).
 
 At least on Mac, the media elements miss out on a number of networking 
 features due to not going through the CachedResource layer and those below. 
 For example they don't work with the app cache. It's something we'd like to 
 fix eventually.
 
 Note: ResourceHandle would probably work and can handle range requests fine, 
 but the media APIs on Mac make it tricky to fully replace the loading that 
 the media framework likes to do for itself. If we had that, we could hook up 
 ResourceHandle pretty easily. The cache layer would need to be enhanced to 
 handle ranges though.
 
 Regards,
 Maciej
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation


On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote:

 On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov a...@webkit.org wrote:
 
 14.09.2010, в 22:15, Darin Fisher написал(а):
 
  I think it makes sense to extend ResourceHandle.cpp to access the 
  BlobRegistry singleton in order to support blob URLs.
 
 
 The problem I see with adding blob support to ResourceHandle is that it makes 
 it too difficult to maintain. It used to be a platform abstraction, and it 
 was hard enough to make sure it worked well across platforms. Adding a 
 significant amount of cross-platform logic on top of that isn't going to make 
 it easier - especially when it's done via subclassing.
 
 I don't understand why this seems so complicated.  ResourceHandle.cpp 
 contains some code that is shared by all WebKit ports that can access their 
 network stack directly from the WebKit main thread.  It already has some 
 common code for handling certain error cases (invalid URL, bad port).  This 
 is the best point in the code to integrate blob URL support.
 
 Maybe subclassing ResourceHandle is not the best way to go about this.  It 
 seems fairly clean to me, but then, I'm not sure what the alternative 
 proposals look like.

I posted a proposal yesterday (do it at the ResourceLoader layer, since that's 
how the app cache hooks in).

 
  
 
 An example that prompted me to look into this was 
 http://trac.webkit.org/changeset/67503. Here, a static function that 
 reported platform capabilities had to become virtual, so that it could take 
 blob loading logic into account. There is nothing in common between are we 
 running on a version of Mac OS X that supports this and are we loading a 
 blob, and remembering this twist won't be easy.
 
 Perhaps the static function should remain but be renamed?  That way it can 
 remain the function that reports platform capabilities.  However, as this 
 patch demonstrates, from WebCore's point of view, this needs to be a property 
 of ResourceHandle.
 
 Maybe it would help if we better formalized the abstraction to the network 
 stack and let ResourceHandle grow to be a smart (contains cross-platform 
 helper code) front-end to that.

I think that's not the right design. ResourceHandle is supposed to be a thin 
abstraction on top of the network library. ResourceLoader is supposed to be the 
smart layer.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation


On Sep 15, 2010, at 1:06 PM, Darin Fisher wrote:

 On Wed, Sep 15, 2010 at 12:56 PM, Maciej Stachowiak m...@apple.com wrote:
 
 On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote:
 
 On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov a...@webkit.org wrote:
 
 14.09.2010, в 22:15, Darin Fisher написал(а):
 
  I think it makes sense to extend ResourceHandle.cpp to access the 
  BlobRegistry singleton in order to support blob URLs.
 
 
 The problem I see with adding blob support to ResourceHandle is that it 
 makes it too difficult to maintain. It used to be a platform abstraction, 
 and it was hard enough to make sure it worked well across platforms. Adding 
 a significant amount of cross-platform logic on top of that isn't going to 
 make it easier - especially when it's done via subclassing.
 
 I don't understand why this seems so complicated.  ResourceHandle.cpp 
 contains some code that is shared by all WebKit ports that can access their 
 network stack directly from the WebKit main thread.  It already has some 
 common code for handling certain error cases (invalid URL, bad port).  This 
 is the best point in the code to integrate blob URL support.
 
 Maybe subclassing ResourceHandle is not the best way to go about this.  It 
 seems fairly clean to me, but then, I'm not sure what the alternative 
 proposals look like.
 
 I posted a proposal yesterday (do it at the ResourceLoader layer, since 
 that's how the app cache hooks in).
 
 That means that app cache doesn't work for HTML5 media in !Chromium.  It also 
 means that blob URLs won't work for HTML5 media in !Chromium.

Both these things are likely to be true anyway, since most media back ends do 
not even use ResourceHandle. We have a design to fix both of these things for 
the Mac port, and it would not suffer from these features being at the 
ResourceLoader layer.

  
 
 
  
 
 An example that prompted me to look into this was 
 http://trac.webkit.org/changeset/67503. Here, a static function that 
 reported platform capabilities had to become virtual, so that it could take 
 blob loading logic into account. There is nothing in common between are we 
 running on a version of Mac OS X that supports this and are we loading a 
 blob, and remembering this twist won't be easy.
 
 Perhaps the static function should remain but be renamed?  That way it can 
 remain the function that reports platform capabilities.  However, as this 
 patch demonstrates, from WebCore's point of view, this needs to be a 
 property of ResourceHandle.
 
 Maybe it would help if we better formalized the abstraction to the network 
 stack and let ResourceHandle grow to be a smart (contains cross-platform 
 helper code) front-end to that.
 
 I think that's not the right design. ResourceHandle is supposed to be a thin 
 abstraction on top of the network library. ResourceLoader is supposed to be 
 the smart layer.
 
 
 I don't see any other examples of URL schemes being handled at the 
 ResourceLoader level.

Indeed, there aren't any. Most URL schemes do not depend on higher-level 
features of the Web platform. The blob: scheme is not quite as magical as 
javascript:, but it is more magical than http:.

 
 I'm not thrilled to introduce more ways in which Chromium and !Chromium 
 differ, but integrating blob URLs at the ResourceLoader is not an option for 
 Chromium.

Chromium has made some different design choices. Often, following these to 
their logical conclusion leads to designs that look like layering violations 
from the pure WebKit perspective. I sympathize with the need to have a design 
that's viable in the face of a process split. We are certainly learning a lot 
about this as we integrate multiprocess functionality into WebKit itself. 
However, as we do more of this work, I become more skeptical that doing 
multiprocess actually requires quite so many layering violations, and so I am 
hesitant to bend the architecture of WebKit around the desire to do things that 
way.

In fairness, we currently have networking running in the Web process, and so 
have not faced down all of the issues related to I/O living in a separate 
process. However, I am pretty confident that the file I/O needs for Blobs can 
be handled without messing with the ResourceHandle layer, in a way that is 
compatible with sandboxing.

Maybe at some point, a few of us should get together in person to talk about 
the right WebCore-level architecture to support multi-process ports while 
continuing to support a single-process design and with good abstractions and 
layering.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation


On Sep 15, 2010, at 2:05 PM, Adam Barth wrote:

 On Wed, Sep 15, 2010 at 1:09 PM, Darin Fisher da...@chromium.org wrote:
 I'm ignoring javascript: URLs because they are super weird... evaluation
 happens synchronously and can have side effects such as causing other
 navigations.  It does not fit the normal mold of URL loading.  Mozilla tries
 to express javascript: URLs as a protocol handler, and it only adds
 complexity.  The WebKit approach of implementing javascript: URLs as special
 cases in FrameLoader is superior because it makes the code easier to
 understand.
 
 Oh man.  If our JavaScript URL handling is easier to understand than
 Firefox's, I'd be really scared to see theirs.  :)

If you do decide to read it, I promise to visit you regularly at the asylum.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Can node-renderer()-node() == node ever be false?

2010-09-14 Thread Maciej Stachowiak


On Sep 14, 2010, at 5:41 PM, Dimitri Glazkov wrote:

 Sorry, I meant node-renderer()-node() != 0. My bad. This loop will
 always exit in in the first iteration.

It definitely is possible for renderers to have a null result from node(). I do 
not know for sure that it's impossible for node-renderer()-node() to be null 
under any circumstances. Anonymous renderers and inline continuations are among 
the ways a null node pointers. It might be that in all such circumstances, the 
renderer won't be returned by any node's renderer() method. It would be worth 
some analysis.

 - Maciej

 
 :DG
 
 On Tue, Sep 14, 2010 at 4:45 PM, Adam Roben aro...@apple.com wrote:
 On Sep 14, 2010, at 6:46 PM, Dimitri Glazkov wrote:
 
 I've been looking at this line here and it doesn't seem to make sense
 to me: 
 http://trac.webkit.org/browser/trunk/WebCore/page/EventHandler.cpp#L2153
 
 It looks like the loop in question will always exit early, because it
 short-circuits to node-renderer()-node() == node, which seems like
 it always will be true. At least, that's what the layout tests say
 when I remove it.
 
 I don't see anything in that loop that is equivalent to 
 node-renderer()-node() == node. All I see are null-checks. Note that line 
 2154 declares a new variable with the name node.
 
 I don't know anything else about this code or what you're asking, though.
 
 -Adam
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Blob scheme implementation

2010-09-14 Thread Maciej Stachowiak


On Sep 14, 2010, at 6:02 PM, Adam Barth wrote:

 On Tue, Sep 14, 2010 at 5:56 PM, David Levin le...@chromium.org wrote:
 On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth aba...@webkit.org wrote:
 What do you think of the idea of having a re-useable BlobCore module
 that all the ports can share?
 
 I don't think this is a good idea. This re-usable module would only be
 used by the Safari WebKit port. As I understand it, Chromium wouldn't be
 able to re-use it due to not re-using WebKit types in general. With only one
 port using it, the module seems like it would not be able to have a good
 design.
 
 So if there is a change, it seems better to just write it for the Safari
 WebKit port and as other ports want to implement it, if they find
 commonality, it would be in their best interest to refractor the existing
 code for better re-use.
 
 Would Chromium be able to re-use the code if it were part of WebCore?
 I guess I don't understand what's different about those two cases.
 
 Another question, does this design allow blob URLs to be used by the
 video element?  My understanding is that video bypasses
 ResourceHandle because ResourceHandle isn't smart enough to handle
 range requests (or something like that).

At least on Mac, the media elements miss out on a number of networking features 
due to not going through the CachedResource layer and those below. For example 
they don't work with the app cache. It's something we'd like to fix eventually.

Note: ResourceHandle would probably work and can handle range requests fine, 
but the media APIs on Mac make it tricky to fully replace the loading that the 
media framework likes to do for itself. If we had that, we could hook up 
ResourceHandle pretty easily. The cache layer would need to be enhanced to 
handle ranges though.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of Frame by ResourceHandle

2010-09-12 Thread Maciej Stachowiak


I like Adam's thinking on this. ResourceHandle depending on Frame, even 
indirectly, is something of a layering violation. It makes more sense to factor 
out the bits that it does need, a la NetworkContext. Using client methods to 
make an association externally seems ok too, but poses more risk that someone 
will fail to call the relevant delegate method.

I have to agree that the way SVG-in-img was done, in particular, has ended up 
causing heaps of trouble even though it was an expedient choice to get the 
feature working quickly. It would be better if more things could be decoupled 
from Frame so we can get out of the business of making fake ones.

Regards,
Maciej

On Sep 11, 2010, at 11:28 PM, Darin Fisher wrote:

 On Sat, Sep 11, 2010 at 11:07 PM, Adam Barth aba...@webkit.org wrote:
 On Sat, Sep 11, 2010 at 10:52 PM, Darin Fisher da...@chromium.org wrote:
  On Sat, Sep 11, 2010 at 10:42 PM, Adam Barth aba...@webkit.org wrote:
  On Sat, Sep 11, 2010 at 10:02 PM, Darin Fisher da...@chromium.org wrote:
   I don't understand.  WebWorkers use ThreadableLoader, which routes the
   network request back to the main thread where there is an associated
   Frame.
(SharedWorkers have a dummy frame associated with them.)
 
  See.  The dummy frame sounds unfortunate.
 
  It solved/avoided a load of problems/complexity.  What are your concerns?
 
 Having fake versions of objects add complexity to all the code that
 expects to talk to real versions of those objects.
 
 This sounds like trading off one form of complexity for another.  Maybe the 
 answer is something like a base class.
 
  
  For example,
 SVG-in-img creates a ton of fake objects and has been the source of
 a lot of bugs (including security bugs).  It seems like having a
 notion of a networking context makes more sense than pretending shared
 workers are associated with a rectangular region of a screen
 somewhere.
 
   In general, there are also
  situations on the main thread where we'd like to perform a load
  without a Frame.  I'd have to look at the details, but there are
  long-standing bugs about applying XSLT to Frame-less documents.  Also,
  the PingLoader doesn't have a Frame available (it's job is to make
  image requests that outlive the Frame).
 
  PingLoader has an associated Frame when it kicks off the load.  That is the
  critical time when Frame association is usually needed.
 
 What happens when code later in the loading cycle assumes this Frame
 is still present?  To avoid exploding, that code needs to understand
 that in this tiny corner of the loader, life is different, which is a
 big testing and maintenance burden.
 
 I agree that those later steps need not have a frame association.  I was 
 referring to the frame association given to a ResourceRequest (via 
 FrameLoaderClient::dispatchWillSendRequest) or via the explicit Frame pointer 
 that was once passed to ResourceHandle.
 
  
 
  For example, you
  cannot load any network requests in Chromium unless you know what Page (you
  need to know the routing ID of the tab) is requesting the resource.  I
  assume PingLoader still generates the
  FrameLoaderClient::dispatchWillSendRequest notification, right?
 
 I don't think so.  PingLoader talks directly to ResourceHandle.
 PingLoader knows about the Frame, but it looks like it only uses it to
 determine the outgoing referrer, to
 addExtraFieldsToSubresourceRequest, and to grab the networking
 context.
 
 
 Hmm... it seems like a bug that it doesn't call dispatchWillSendRequest.  
 That does some important work that should apply to all network requests.
 
 Take a look at FrameLoaderClientImpl::dispatchWillSendRequest under 
 WebKit/chromium/src/.  It calls setFirstPartyForCookies in one case!
 
  
 
  How do you get a frame-less document?  Via XMLHttpRequest.responseXML?
  Perhaps it could use the Frame of the script execution context?  (Which
  script execution context is a good question.)
 
 There are are lots of ways to get a Frameless document.  For example,
 JavaScript can call document.implementation.createDocument.  Also, the
 DOMParser will given you a document.  XMLHttpRequest will give you
 one.  You can get one by having an XSLT.  The PageCache has some.
 
 There was a patch that someone was pushing at some point to chain
 these documents back to a master document that has a frame.  That's
 certainly one approach, but I don't think it should be necessary.
 
 That's the solution I would have expected.  It fits more naturally with our 
 system.
 
  
 
  In general, there is no necessary connection between network requests
  made by WebCore and Frames.  Techniques that aim to associate a frame
  with every network request won't work in some cases because such a
  Frame might not exist.
 
  There always has been such an association.
 
 Right, and there are bugs we've never been able to fix because of that 
 coupling.
 
  I would like to understand the
  concerns better.  I guess it means that I need to understand the

Re: [webkit-dev] Why is ResourceHandle.cpp in WebKit/chromium/src

2010-09-12 Thread Maciej Stachowiak


On Sep 11, 2010, at 9:42 PM, Darin Fisher wrote:

 On Sat, Sep 11, 2010 at 2:49 AM, Adam Barth aba...@webkit.org wrote:
 
  If we like pattern (3), maybe we should replace
 PlatformBridge with (3)?
 
 Yes, perhaps we should do that.  In concert with that, it would be good to 
 create a subdirectory in WebKit/chromium/src for these WebCore class 
 implementations.
 
 I'm concerned that the PlatformStrategies approach adds too much maintenance 
 overhead given the number of interfaces we'd need to add to it.

Is it really more maintenance than PlatformBridge? That class includes 
effectively a bunch of interfaces, they are just demarcated with comments 
instead of actually being separate classes. Modularity is good. Large 
interfaces that are a grab-bag of different things are not good for 
maintainability in the long run. At least that is what we learned from 
WebCoreBridge back in the day.

Furthermore, the PlatformBridge solution is one we cannot use for WebKit2. It 
uses static methods exclusively and so forces the binding to be compile-time. 
But we'd like to be able to use the same copy of WebCore with an in-process 
implementation and an out-of-process one, for many things. Thus, we will need 
the PlatformStrategies approach for a number of things. For the same reason, 
header-in-WebCore-implementation-in-WebKit won't work. Chromium could choose to 
handle the delegation of those things in a completely different way, but that 
won't lower complexity for the project as a whole. 

Can you give a bit more detail on why the PlatformStrategies approach seems 
like too much maintenance overhead to you? I would prefer as much as possible 
to have an approach that works for all ports. In particular, I hope that with 
WebKit2 having many of the same specialized requirements as Chromium, we can 
reduce the amount of Chromium-specific pieces of architecture and find more 
general solutions to these problems.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why is ResourceHandle.cpp in WebKit/chromium/src

2010-09-11 Thread Maciej Stachowiak


On Sep 11, 2010, at 2:49 AM, Adam Barth wrote:

 That makes a certain amount of sense.  It seems like we have three
 ways for WebCore to talk to Webkit/foo:
 
 1) Client interfaces
 2) PlatformBridge
 3) Header-in-WebCore, implementation-in-WebKit/foo
 
 Is there some systematic way of determining which way we should use in
 a given circumstance?  If we like pattern (3), maybe we should replace
 PlatformBridge with (3)?  I think there was some talk earlier of
 WebKit2 using something called a strategy, which seemed a bit like
 (2), but maybe more modular.
 
 To be clear, this came up in my trying to wrap my mine around the
 loader.  I'm not sure there's anything wrong with (3), it just took me
 a while to find Chromium's implementation of ResourceHandle because it
 wasn't where I expected it to be.

We have a start on the strategy pattern, you can see it in: 

WebCore/platform/PlatformStrategies.h
WebProcess/WebCoreSupport/WebPlatformStrategies.cpp
WebKit/mac/WebCoreSupport/WebPlatformStrategies.mm
WebKit/win/WebCoreSupport/WebPlatformStrategies.cpp

The strategy pattern is intended for cases where the implementation of 
something in WebCore is to be virtualized up to the WebKit layer, including 
the possibility of switching at runtime, but it's expected to be a global 
switch for that particular instance of WebCore, not per-object.

Client interfaces, on the other hand, are intended as callback interfaces for 
code that is logically on top of WebCore, to provide notifications and the 
opportunity for policy-type decisions.

I think the modular Strategy pattern is better than the monolithic Bridge 
pattern. Way back in the day we used to have a single WebCoreBridge as the 
interface between WebCore and WebKit. We moved away from that design because it 
was messy and the bridge had a tendency to become a god object over time. Our 
bridge was also a two-way bridge (various methods implemented on each side) 
which I think is not the case with the chromium bridge.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of Frame by ResourceHandle

2010-09-11 Thread Maciej Stachowiak


On Sep 11, 2010, at 4:21 PM, Sam Weinig wrote:

 It seems the dependency on Frame is now gone (as of last night I guess?) with 
 the advent of the NetworkingContext.

Neat. I was going to suggest using factory objects to create ResourceHandles 
(then they can stuff in whatever info they need, or add an external association 
or whatever), but I am not sure of the right scope for the factory. One per 
frame clearly, but Worker and SharedWorker would need separate handling. 
Perhaps they could piggyback off the factory of the initially creating frame.

Regards,
Maciej

 
 -Sam
 
 On Sat, Sep 11, 2010 at 3:42 PM, Maciej Stachowiak m...@apple.com wrote:
 
 On Sep 11, 2010, at 2:57 AM, Adam Barth wrote:
 
  I don't mean to spam this list with design questions, but I'm trying
  to wrap my mind around how the loader is put together today and how
  we'd like it to be put together in the future.
 
  There's a FIXME in ResourceHandle that says that ResourceHandle
  shouldn't depend on Frame.  (For those who aren't familiar with the
  loader, ResourceHandle is the primary platform abstraction WebCore
  uses to communicate with the network.)  This makes sense to me for two
  reasons:
 
  1) ResourceHandle is in WebCore/platform/network and therefore isn't
  allowed to depend on parts of WebCore outside the platform directory.
  2) There are a number of types of network requests that are not
  associated with frames (e.g., XMLHttpRequests from WebWorkers,
  PingLoader, etc).
 
  Do we still believe this FIXME is accurate?  If so, I have some time
  next week to look at removing the dependency.  There's a patch that
  either recently landed or is about to land that furthers the use of
  Frame by ResourceHandle, so I wanted to check with folks more broadly
  about whether this is the right direction.  (Note that I haven't
  studied the code yet, so I'm not sure what would be required to remove
  the dependency.)
 
 I think this is the right way to go. I don't clearly understand the reasons 
 this dependency was added, but I hope we can find an alternate design to meet 
 those needs.
 
 Regards,
 Maciej
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Arena is crufty?

2010-09-02 Thread Maciej Stachowiak


On Sep 2, 2010, at 8:51 AM, Chris Marrin wrote:

 
 On Sep 1, 2010, at 7:20 PM, Kenneth Russell wrote:
 
 I would be happy to not add another Arena client, but the primary
 reason I need an arena is not just for performance but to avoid having
 to keep track of all of the objects I need to delete.
 
 Is there any consensus yet on how to proceed with
 https://bugs.webkit.org/show_bug.cgi?id=45059 ? I'm concerned about
 taking on large-scale restructuring with potential performance impact
 as a prerequisite for my landing any initial code. I could revert my
 PODArena class to use its own memory allocation rather than that in
 Arena.h.
 
 I just posted that it seems like your RB tree could be replaced by 
 std::multimap. And, given comments from others, it seems like the right thing 
 to do with Arena is to put PODArena into the gpu directory like you were 
 originally going to do, but to not use Arena.h (suck it's functionality into 
 PODArena). Alternately, you could try Jeremy's idea and ref count your 
 objects. If you use std::multimap, elements can be of type RefPtrsomething, 
 so you can avoid all memory management issues.

We usually don't use STL containers because they can raise exceptions and it's 
WebKit policy to not use exceptions in code, and to support building with 
exceptions disabled.

Long ago, WebCore had a red-black tree class written by me but we managed to 
replace all uses with hashtables. I am assuming in this case a balanced tree is 
genuinely needed. If that is the case, I'd much prefer to see one that supports 
more than just POD types; a limitation to POD types is a significant loss of 
generality. It is not hard to make a balanced tree class that supports 
arbitrary C++ types, in fact it would be the natural way to code it.

If the arena exists to avoid memory management bookkeeping and not for 
performance reasons, then I'm not sure that is a very good reason to have it. 
If it is required for performance, then it is reasonable to make it an 
implementation detail of the RB tree.

Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Complex and Vector3 classes in WTF?

2010-09-01 Thread Maciej Stachowiak


On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:

 
 But I agree with Maciej that all of the public API is transformation 
 oriented. Even things like inverse() and transpose() have application in 
 doing transforms. I think it would be a stretch to use this 4x4 matrix for 
 general purposes. A general matrix class usually has to deal with different 
 dimensions, for instance.
 
 But I am loath to call it HomogeneousTransform, given the fact that Maciej 
 and I have spelled it differently (both are accepted spellings) and it will 
 be really hard for people to get used to spelling such an uncommon word.
 
 If you look at the Uses section of 
 http://en.wikipedia.org/wiki/Transformation_matrix you'll see that they 
 consider the term improper as well. And they have a good point. Since they 
 recommend the term general transformation matrix to distinguish it from the 
 more restricted affine transformation, then simply calling it Transform 
 seems appropriate.

Transform sounds ok to me, actually, even though it is a little broad.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Arena is crufty?

2010-09-01 Thread Maciej Stachowiak


On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:

 
 Ken's PODRedBlackTree patch has made me go back and take a closer look at 
 WebKit's Arena class. Turns out it's not a class at all, just some structs 
 and macros. That seems very un-WebKit-like to me. Ken's patch also has a 
 PODArena class, which uses Arena in its implementation. Sam suggests that 
 PODRedBlackTree should really go into WTF, which means PODArena and Arena 
 would need to go there as well.
 
 It seems like Arena really needs to be brought into the 21st century and made 
 a proper class. Maybe now is the right time to:
 
 1) Make Arena a class
 
 2) Integrate Ken's PODArena functionality into this new Arena class (or maybe 
 just make Ken's PODArena the new Arena class).
 
 3) Move the new Arena class to WTF
 
 4) Put PODRedBlackTree in WTF
 
 It looks like RenderArena is currently the only client of Arena.h, so this 
 change shouldn't be too hard. Of course, looking at RenderArena, it's a 
 little odd, too. It is not renderer specific at all. It's just an Arena that 
 recycles freed objects. Maybe we should move that functionality into the new 
 Arena class. But RenderArena is used all over the place, so maybe that's 
 going one step too far down this road?

Arena was imported from Mozilla and could certainly benefit from modernization. 
For the rendering use case though, it is essential to handle non-POD types 
correctly.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Arena is crufty?

2010-09-01 Thread Maciej Stachowiak


On Sep 1, 2010, at 7:04 PM, David Hyatt wrote:

 We should just kill Arena and remove it and RenderArena both.

Wasn't it still a measurable slowdown last time we tried that?

 - Maciej

 
 On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:
 
 
 Ken's PODRedBlackTree patch has made me go back and take a closer look at 
 WebKit's Arena class. Turns out it's not a class at all, just some structs 
 and macros. That seems very un-WebKit-like to me. Ken's patch also has a 
 PODArena class, which uses Arena in its implementation. Sam suggests that 
 PODRedBlackTree should really go into WTF, which means PODArena and Arena 
 would need to go there as well.
 
 It seems like Arena really needs to be brought into the 21st century and 
 made a proper class. Maybe now is the right time to:
 
 1) Make Arena a class
 
 2) Integrate Ken's PODArena functionality into this new Arena class (or 
 maybe just make Ken's PODArena the new Arena class).
 
 3) Move the new Arena class to WTF
 
 4) Put PODRedBlackTree in WTF
 
 It looks like RenderArena is currently the only client of Arena.h, so this 
 change shouldn't be too hard. Of course, looking at RenderArena, it's a 
 little odd, too. It is not renderer specific at all. It's just an Arena that 
 recycles freed objects. Maybe we should move that functionality into the new 
 Arena class. But RenderArena is used all over the place, so maybe that's 
 going one step too far down this road?



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Complex and Vector3 classes in WTF?

2010-08-31 Thread Maciej Stachowiak


On Aug 31, 2010, at 2:06 PM, Chris Marrin wrote:

 
 On Aug 31, 2010, at 11:48 AM, Kenneth Russell wrote:
 
 On Tue, Aug 31, 2010 at 11:05 AM, David Hyatt hy...@apple.com wrote:
 On Aug 31, 2010, at 10:36 AM, Chris Marrin wrote:
 
 Or should we get rid of Vector3, added the functionality it needs to 
 FloatPoint3D and use that? Ken Russell already has plans to do add the 
 functions to FloatPoint3D, so I would vote for that.
 
 I would vote for this.  I don't think the geometry classes should move to 
 wtf.
 
 I'd like to unify the math, geometry, and linear algebra classes that
 are scattered around the WebKit tree -- for example, FloatPoint,
 FloatPoint3D, FloatRect, FloatSize, the classes under
 WebCore/platform/graphics/transforms/, these Complex and Vector3
 types, ... -- under a directory like WebCore/math, remove duplicate
 functionality, and provide a cohesive set of interfaces that can be
 easily used by other modules like graphics and audio.
 
 It would be nice if we could do this unification and then later on we can 
 enhance it so the classes play nice together. For instance, 
 TransformationMatrix deals with many, but not all of the other geometric 
 classes. You can't cast between FloatPoint and FloatPoint3D, etc. Maybe we 
 could also use this opportunity to change TransformationMatrix to Matrix. The 
 current name is such a mouthful. And we might also want to think about 
 changing FloatPoint3D to FloatPoint3. That would make it more natural if and 
 when we want to add a FloatPoint4. We should also change AffineTransform to 
 AffineMatrix so it matches Matrix.

Mathematically, you can have an affine transform, or a matrix that represents 
an affine transform. And there's such a thing as an affine space (in fact 
IntPoint and IntSize form an affine space). But there's no such thing as an 
affine matrix.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Complex and Vector3 classes in WTF?

2010-08-31 Thread Maciej Stachowiak


On Aug 31, 2010, at 3:59 PM, Chris Marrin wrote:

 
 On Aug 31, 2010, at 3:43 PM, Kenneth Russell wrote:
 
 On Tue, Aug 31, 2010 at 3:39 PM, Chris Marrin cmar...@apple.com wrote:
 
 On Aug 31, 2010, at 3:25 PM, Maciej Stachowiak wrote:
 
 
 On Aug 31, 2010, at 2:06 PM, Chris Marrin wrote:
 
 
 On Aug 31, 2010, at 11:48 AM, Kenneth Russell wrote:
 
 On Tue, Aug 31, 2010 at 11:05 AM, David Hyatt hy...@apple.com wrote:
 On Aug 31, 2010, at 10:36 AM, Chris Marrin wrote:
 
 Or should we get rid of Vector3, added the functionality it needs to 
 FloatPoint3D and use that? Ken Russell already has plans to do add the 
 functions to FloatPoint3D, so I would vote for that.
 
 I would vote for this.  I don't think the geometry classes should move 
 to wtf.
 
 I'd like to unify the math, geometry, and linear algebra classes that
 are scattered around the WebKit tree -- for example, FloatPoint,
 FloatPoint3D, FloatRect, FloatSize, the classes under
 WebCore/platform/graphics/transforms/, these Complex and Vector3
 types, ... -- under a directory like WebCore/math, remove duplicate
 functionality, and provide a cohesive set of interfaces that can be
 easily used by other modules like graphics and audio.
 
 It would be nice if we could do this unification and then later on we can 
 enhance it so the classes play nice together. For instance, 
 TransformationMatrix deals with many, but not all of the other geometric 
 classes. You can't cast between FloatPoint and FloatPoint3D, etc. Maybe 
 we could also use this opportunity to change TransformationMatrix to 
 Matrix. The current name is such a mouthful. And we might also want to 
 think about changing FloatPoint3D to FloatPoint3. That would make it more 
 natural if and when we want to add a FloatPoint4. We should also change 
 AffineTransform to AffineMatrix so it matches Matrix.
 
 Mathematically, you can have an affine transform, or a matrix that 
 represents an affine transform. And there's such a thing as an affine 
 space (in fact IntPoint and IntSize form an affine space). But there's no 
 such thing as an affine matrix.
 
 Sure there is. It's a matrix that performs affine transformations. 
 Mathematically it's represented as a 3x3 matrix, but like others, we just 
 represent it as a linear transformation matrix (2x2) plus a 2D translation 
 value. I think the name AffineMatrix is descriptive because, unlike a 
 general 3x3 matrix, our truncated representation can only handle affine 
 transformations.
 
 Chris, based on the precision of Maciej's reply, I suspect you do not
 want to get into a semantic argument here... :)
 
 http://www.google.com/search?q=affine+matrix
 
 Oh, Ken, I'll argue about anything, you know that :-)
 
 Yes, I did the Google search and you're right that the term is not in common 
 usage (although I still maintain it's a completely reasonable term). The 
 reason I think it's meaningful is because it really is a matrix of sorts, but 
 a specialized one that handles only affine transformations. We could call it 
 AffineTransform, but then why not call our 4x4 matrix HomogeneousTransform? 
 I'd just like to be consistent.

HomogenousTransform is fine. I would also be fond of PerspectiveProjection.

I think TransformMatrix is not a good name. It immediately raises the question, 
what kind of transform. I also think Matrix does not need to be in the name. 
That is to some extent an implementation detail, from the mathematical 
perspective. It's more important to identify the type of transformation.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Complex and Vector3 classes in WTF?

2010-08-31 Thread Maciej Stachowiak


On Aug 31, 2010, at 5:29 PM, Chris Marrin wrote:

 
 On Aug 31, 2010, at 5:25 PM, Kenneth Russell wrote:
 
 ...Yes, I did the Google search and you're right that the term is not in 
 common usage (although I still maintain it's a completely reasonable 
 term). The reason I think it's meaningful is because it really is a matrix 
 of sorts, but a specialized one that handles only affine transformations. 
 We could call it AffineTransform, but then why not call our 4x4 matrix 
 HomogeneousTransform? I'd just like to be consistent.
 
 HomogenousTransform is fine. I would also be fond of PerspectiveProjection.
 
 PerspectiveProjection is not a good name for a 4x4 matrix class. Such
 a matrix might be used to represent an orthographic projection.
 
 I think TransformMatrix is not a good name. It immediately raises the 
 question, what kind of transform. I also think Matrix does not need to be 
 in the name. That is to some extent an implementation detail, from the 
 mathematical perspective. It's more important to identify the type of 
 transformation.
 
 I'm concerned about the route of adding a class for each kind of
 transformation. It will lead to a proliferation of confusingly named
 types and excess type conversion, or re-identification of the type of
 transformation, when composing transformations. At least in the 3D
 realm, all that is desired is one simple 4x4 matrix class. Additional
 classes to represent e.g. 4x3 matrices add unnecessary complexity.

I don't think we need a huge number, but the 2D affine transform case is 
clearly special - it's too expensive to use a 4x4 matrix for this.

 
 I agree. So, in order to appease Maciej :-) what if we keep AffineTransform 
 as is, and change TransformationMatrix to Matrix (or Matrix4 if Matrix is too 
 generic)?

Is HomogenousTransform an inaccurate representation of what it does?

The class has methods such as mapPoint, projectPoint, scale, rotate3d, 
applyPerspective, etc. It is clearly oriented around being some sort of 
transform, not a generic 4x4 matrix. Is it ever used to represent something 
that is not a transform at all? Would you use this class for something totally 
unrelated to transforms, for example if you wanted to solve a system of linear 
equations via gaussian elimination? My expectation is that you would not.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Misplaced files

2010-08-30 Thread Maciej Stachowiak


On Aug 30, 2010, at 8:36 AM, Darin Fisher wrote:

 On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth aba...@webkit.org wrote:
 On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote:
  Yes. The file-related stuff should all be in one directory, I think.
 
 Ok.  I moved the files from WebCore/html to WebCore/fileapi.
 
 On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote:
  We have bunch of FileSystem (which is a part of File API) related files in
  WebCore/storage/.
  Maybe we should move them to the new directory too?
 
 Are these the files you're talking about?
 
 WebCore/storage/DOMFilePath.cpp
 WebCore/storage/DOMFilePath.h
 WebCore/storage/DOMFileSystem.cpp
 WebCore/storage/DOMFileSystem.h
 WebCore/storage/DOMFileSystem.idl
 WebCore/storage/FileEntry.cpp
 WebCore/storage/FileEntry.h
 WebCore/storage/FileEntry.idl
 WebCore/storage/FileSystemCallback.h
 WebCore/storage/FileSystemCallback.idl
 WebCore/storage/FileSystemCallbacks.cpp
 WebCore/storage/FileSystemCallbacks.h
 WebCore/storage/LocalFileSystem.cpp
 WebCore/storage/LocalFileSystem.h
 
 I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do 
 it.
 
 Thanks,
 Adam
 
 
 
 How about just moving everything into WebCore/storage?  This is all 
 storage-related stuff.

I think the File API is large enough to deserve its own directory. In fact, it 
might be worth splitting up the remaining contents of the storage directory 
too. It is confusing to have large but almost entirely separate APIs all piled 
into one directory. It is true they are all storage-related, but that is a 
pretty broad theme, and LocalStorage, SQL Storage, Indexed DB and File API have 
little or no interaction with each other.

Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] We need OwnPtrHashMap

2010-08-30 Thread Maciej Stachowiak


On Aug 29, 2010, at 9:34 PM, Maciej Stachowiak wrote:

 
 On Aug 29, 2010, at 9:14 PM, Maciej Stachowiak wrote:
 
 Yet another possibility is to use a hash to do the de-duping instead of 
 sorting; I can't tell from context if the sorting is needed for any purpose 
 other than subsequent de-duping.
 
 Turns out this doesn't work - the CSS Media Queries spec specifically 
 requires serializing in sorted order and we have a test to that effect:
 http://dev.w3.org/csswg/cssom/#serializing-media-queries
 https://bugs.webkit.org/show_bug.cgi?id=39220
 
 So it's down to violating the type system or writing my own sort.

OK, you silently guilted me into writing a non-copying sort function.

https://bugs.webkit.org/show_bug.cgi?id=44874

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to line-by-line code reviews

2010-08-29 Thread Maciej Stachowiak


On Aug 29, 2010, at 4:39 PM, Adam Barth wrote:

 On Sun, Aug 29, 2010 at 4:16 PM, Maciej Stachowiak m...@apple.com wrote:
 I'm not sure who objects to new features being added to Review Patch, but I 
 don't like this change:
 
 There's a tention between folks who like line-by-line comments and
 (mostly) Darin, who likes the old Review Patch tool.  Darin likes the
 giant textbox with the whole diff.  I don't really understand, but I
 certainly have no wish to impede his use of the tools.
 
 1) I'm used to having the click to add a comment feature in Review Patch, 
 and would miss it if it was gone.
 2) I think overloading Formatted Diff is wrong - it should remain a 
 read-only view.
 
 I think the main remaining problems with the Review Patch page are the 
 inability to give comments with multiple lines of context, and the excessive 
 amount of space dedicated to things that are not the patch.
 
 The other problem is that reviews get hard to follow really fast when
 folks reply to review comments and the existing line-by-line editing
 requires about twice as many clicks as it needs.  I don't have mockups
 to show, but what I had in mind was the following:
 
 1) Use the whole page for the diff (basically remove the bottom half
 of the Review Patch screen).
 2) When you're done writing line-by-line comments, show a lightbox
 that has the content that used to be at the bottom of the screen.
 That gives you a chance to enter high-level comments, read over your
 comments, and adjust the various flags.
 3) The tools will then store the review in a comment, as before, which
 generates an email to the author of the patch.
 4) The patch author can either read your review as a bugzilla comment,
 or they can look at the patch and the tool will show your comments
 inline in the diff where you wrote them.  The author can respond by
 adding more comments inline, which again are stored as bugzilla
 comments, etc.
 
 In this approach, you can also imagine integration with the style
 checker and the EWS bots.  The tools can show the style errors inline
 in the diff, as well as the compiler failures.  The view is more that
 the diff is a living document with a bunch of layers (some of which
 are editable).

That sounds like a good design to me. But it doesn't sound like a replacement 
for a read-only view of just the diff.

If you add the ability to show and hide the lightbox at any time, it might even 
be a reasonable replacement even for people who like to type their review 
comments by hand.

 
 If changing the Review Patch page as needed would be too disruptive for some 
 reason, I suggest using a new page instead of overloading Formatted Diff.
 
 We can certain add these features under a new name, if you think that
 would be the least disruptive.  Sam already emailed me privately
 explaining how I broke one of his uses of the Formatted Diff, but I
 think I can fix that fairly easily by learning slightly more jQuery.
 
 I'm happy to build this off in a silo and then convince everyone how
 awesome it is once it actually is more awesome than the current tools.

I suggest you start by making it a new page, and then we can decide whether to 
remove any of the existing pages in favor of the new one.

Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] We need OwnPtrHashMap

2010-08-29 Thread Maciej Stachowiak


On Aug 28, 2010, at 10:57 PM, Darin Adler wrote:

 We need VectorOwnPtr too. It has similar issues to HashMap with OwnPtr 
 values, including the ones mentioned by Maciej.
 
 For one example, look at CSSParser::m_floatingMediaQueryExpList.

VectorOwnPtr actually works[1], and I have an almost complete patch to fully 
OwnPtr-ize MediaQueryExp. The one problem is sorting - MediaQuery wants to sort 
the VectorMediaQuery* it gets with std::sort, followed by eliminating 
duplicates. A sort that solely uses swaps would work, but std::sort wants to 
make copies of the elements at times. I also tried to think of ways to cheat by 
copying to a vector of raw pointers and back, and it could be made to work with 
sufficiently aggressive use of leakPtr and adoptPtr, but at the cost of two 
extra copies. Yet another possibility is to use a hash to do the de-duping 
instead of sorting; I can't tell from context if the sorting is needed for any 
purpose other than subsequent de-duping.

If you can help me think of a good solution for this I'll post my patch.

Regards,
Maciej


[1] It works because:
(a) VectorTraits already takes care of all internal copies that are actually 
moves, by cheating and doing them with memcpy.
(b) Reads, and writes of an existing slot, all operate via a reference to the 
element type, so you can use - or .get() on a returned element just fine, and 
you can assign in a PassOwnPtrT to an OwnPtrT.
(c) append() and similar methods that add an element to a not-yet-existing slot 
all are templatized on the type of the element being added, so appending a 
PassOwnPtr works.

The Hash templates are more complicated, so they probably won't just work 
automatically.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] We need OwnPtrHashMap

2010-08-29 Thread Maciej Stachowiak


On Aug 29, 2010, at 9:14 PM, Maciej Stachowiak wrote:

  Yet another possibility is to use a hash to do the de-duping instead of 
 sorting; I can't tell from context if the sorting is needed for any purpose 
 other than subsequent de-duping.

Turns out this doesn't work - the CSS Media Queries spec specifically requires 
serializing in sorted order and we have a test to that effect:
http://dev.w3.org/csswg/cssom/#serializing-media-queries
https://bugs.webkit.org/show_bug.cgi?id=39220

So it's down to violating the type system or writing my own sort.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Misplaced files

2010-08-27 Thread Maciej Stachowiak


On Aug 27, 2010, at 3:55 PM, Adam Barth wrote:

 Looking through WebCore/html I noticed the files below.  I'm not sure
 they belong in WebCore/html because they don't appear to be
 HTML-specific.  Rather, they seem like generic web platform APIs
 (e.g., they could be exposed to SVG or whatever other markup languages
 we choose to support in the future).  Should we move these to
 WebCore/page, WebCore/dom, or should we make a new location for these
 sorts of things?

I think the File API (which all of these are related to) deserves its own 
directory right under WebCore.

 - Maciej


 Adam
 
 
 == Blob-related ==
 Blob.cpp
 Blob.h
 Blob.idl
 BlobBuilder.cpp
 BlobBuilder.h
 BlobBuilder.idl
 BlobURL.cpp
 BlobURL.h
 ThreadableBlobRegistry.cpp
 ThreadableBlobRegistry.h
 
 == File-related ==
 File.cpp
 File.h
 File.idl
 FileError.h
 FileError.idl
 FileList.cpp
 FileList.h
 FileList.idl
 FileReader.cpp
 FileReader.h
 FileReader.idl
 FileStreamProxy.cpp
 FileStreamProxy.h
 FileThread.cpp
 FileThread.h
 FileThreadTask.h
 FileWriter.cpp
 FileWriter.h
 FileWriter.idl
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Misplaced files

2010-08-27 Thread Maciej Stachowiak


On Aug 27, 2010, at 5:15 PM, Adam Barth wrote:

 On Fri, Aug 27, 2010 at 4:08 PM, Maciej Stachowiak m...@apple.com wrote:
 On Aug 27, 2010, at 3:55 PM, Adam Barth wrote:
 Looking through WebCore/html I noticed the files below.  I'm not sure
 they belong in WebCore/html because they don't appear to be
 HTML-specific.  Rather, they seem like generic web platform APIs
 (e.g., they could be exposed to SVG or whatever other markup languages
 we choose to support in the future).  Should we move these to
 WebCore/page, WebCore/dom, or should we make a new location for these
 sorts of things?
 
 I think the File API (which all of these are related to) deserves its own 
 directory right under WebCore.
 
 Ok.  I can take care of that.  Thoughts on names?  WebCore/file ?

I would say file-api or fileapi or something, since it seems more likely than 
other cases to get confused with the general concept of files.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Misplaced files

2010-08-27 Thread Maciej Stachowiak


On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote:

 We have bunch of FileSystem (which is a part of File API) related files in 
 WebCore/storage/.
 Maybe we should move them to the new directory too?

Yes. The file-related stuff should all be in one directory, I think.

Regards,
Maciej

 
 On Fri, Aug 27, 2010 at 6:01 PM, Maciej Stachowiak m...@apple.com wrote:
 
 On Aug 27, 2010, at 5:15 PM, Adam Barth wrote:
 
  On Fri, Aug 27, 2010 at 4:08 PM, Maciej Stachowiak m...@apple.com wrote:
  On Aug 27, 2010, at 3:55 PM, Adam Barth wrote:
  Looking through WebCore/html I noticed the files below.  I'm not sure
  they belong in WebCore/html because they don't appear to be
  HTML-specific.  Rather, they seem like generic web platform APIs
  (e.g., they could be exposed to SVG or whatever other markup languages
  we choose to support in the future).  Should we move these to
  WebCore/page, WebCore/dom, or should we make a new location for these
  sorts of things?
 
  I think the File API (which all of these are related to) deserves its own 
  directory right under WebCore.
 
  Ok.  I can take care of that.  Thoughts on names?  WebCore/file ?
 
 I would say file-api or fileapi or something, since it seems more likely than 
 other cases to get confused with the general concept of files.
 
 Regards,
 Maciej
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] We need OwnPtrHashMap

2010-08-25 Thread Maciej Stachowiak


On Aug 25, 2010, at 1:46 PM, Geoffrey Garen wrote:

 Sorry for the late-night webkit-dev spam, but in deploying adoptPtr,
 I've noticed a number of places where have a HashMap that owns its
 values as OwnPtrs.  Unfortunately, this very clumsy currently.  Each
 instance of this pattern has its own way of hacking around the
 problem, which might or might not result in memory errors.  We really
 should have an OwnPtrHashMap (to complement RefPtrHashMap) that
 understands how to handle this case correctly.
 
 To clarify:
 
 Optimization aside, HashMapRefPtrT, U and HashMapT, RefPtrU  work 
 just fine. RefPtrHashMap was an optimization. The feature it needed, which 
 HashMap did not provide, was the ability to look up a value by a non-key type 
 (raw pointer), without first converting to key type (RefPtr), since 
 converting to RefPtr would cause refcount churn. We couldn't find a way to do 
 this using HashTraits without using casts that violated strict aliasing rules.
 
 In contrast, HashMapOwnPtrT, U and HashMapT, OwnPtrU  don't work at 
 all. They don't compile, since OwnPtr is not copyable. If you made OwnPtr 
 copyable, they would accidentally delete items during get() and resize() 
 operations.

I think it is possible to make a specialization of HashMap that secretly uses a 
HashMap of raw pointers under the covers. That would fix the copies internal to 
HashTable. However, you'd have to decide on the correct semantics for get/set 
operations and possibly tweak their return types. In particular, for an OwnPtr 
value (likely the common case), you'd want get() to return a raw pointer, set() 
to take a PassOwnPtr, and take() to return a PassOwnPtr. You probably would not 
want to use OwnPtr anywhere in the API.

This doesn't quite entirely match the HashMap contract, but it's close enough 
to be useful.

(Note: I'm probably one of the people with enough template-fu to code this, but 
I probably won't have time in the very near future.)

 
 A HashMap that owns its values wants to do something special when an item is 
 overwritten, removed, or implicitly removed by HashMap destruction, but it 
 doesn't want to do anything special when an item is copied or extracted.
 
 I think the best way to achieve this with HashMap might be a hash trait, 
 rather than literally putting an OwnPtr in the map. Specifically, the trait 
 would be one willRemove callback, which took an iterator to an item, and one 
 willRemoveAll callback, which took a begin iterator. These callbacks would 
 default to empty inline functions.
 
 But maybe there's a way to use special hash traits and translators to 
 eliminate all or nearly all the C++ copying operations.

I don't think HashTraits is the right solution. It doesn't give as good type 
safety as a HashMap variant that takes PassOwnPtr for all set/add/whatever type 
functions. Also, HashTraits are about a type, but whether the HashMap takes 
single ownership is not intrinsic to the type, it is a question for the 
individual HashMap. You could validly have one HashMap that owns all its values 
(of type Foo*) and another HashMap with the same value space that does not. The 
only error would be multiple HashMaps trying to own the same object. Using 
PassOwnPtr as the way to transfer ownership to the HashMap would prevent this.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Place For new Core Module

2010-08-24 Thread Maciej Stachowiak


Given your description, I'm not sure this functionality is appropriate for 
WebKit. We are generally reluctant to take feature patches for features that 
are experimental or of niche interest - we prefer to focus on technologies that 
are part of the standards-based Web technology stack, that are likely to become 
Web standards, or that are valuable general-purpose complements to Web 
standards.

It sounds like the feature you are talking about does not fit this template 
very well currently, though it may in the future if it does get on track to 
become a Web standard.

Regards,
Maciej

On Aug 24, 2010, at 2:26 PM, Chinmaya Sn wrote:

 Let me put it this way, I am working on a new standard, which
 leverages some of HTML5 standards but tries to extend them
 (not enhance) to answer some of the Cable industry challenges.
 
 I started by analysing WebKit layer, it has very strong assumption of
 layering browser-engine, and mostly has APIs which helps you
 build a html browser, why not, WebKit is a browser-engine.
 
 In my first case, of rendering a special kind of app on top of HTML5 video;
 these apps don't speak html/javascript, they speak primitives such as
 drawRectangle, drawLine etc. and has own events and processing
 functions (its a language in itself) which needs to be translated into
 either C++ or HTML/JavaScript.
 
 My primary requirements is to add new modules which represent new
 standards which work in conjunction with HTML5 (very closely) without
 any changes inside WebCore.
 
 
 
 Today WebKit would not gain anything, this is new standard work in
 progress. Tomorrow things might change, and if someone says I
 want this Cable specific feature, one could easily tell 'hey build
 WebKit with this flag and you will get that feature for free',
 that is my motto.
 
 I am driving this as as future proof solution.
 Currently I'll be performing these changes only in my own branch.
 
 Makes sense?
 
 
 
 On Tue, Aug 24, 2010 at 2:09 PM, Ariya Hidayat ariya.hida...@gmail.com 
 wrote:
 I guess you also need to supply the justification: what would WebKit
 gain from such modules? Are the modules part of HTML5 and other web
 standards?
 
 
 Regards,
 
 
 
 
 
 On Tue, Aug 24, 2010 at 2:17 PM, Simon Fraser simon.fra...@apple.com wrote:
 I'll be the first to ask this question: what do you need to do that you can 
 do
 with existing WebKit APIs, and existing web technology?
 
 With video, you could use http streaming to deliver custom content,
 and make sure of accelerated compositing to ensure that you can
 efficiently layer HTML content on top of video.
 
 If your platform does not have support for these, then the right
 way to address this is to add support for these missing pieces,
 rather than hacking at WebCore internals.
 
 Simon
 
 On Aug 24, 2010, at 12:31 PM, Chinmaya Sn wrote:
 
 The current module I have implemented works closely with
 RenderingEngine/GraphicsContext and HTML5 video player, which
 tries to deliver some special interactive Apps (In Cable World) as an
 overlay over HTML5 Video,
 the apps themselves are delivered as one of the private streams in the
 Video, so some work has gone inside implementation
 of video player itself.
 
 In near future, I will be poking around a lot  with HTML5 player. I
 will be implementing lot more modules like above,
 which will be linked to WebCore. Each of the new enhancements I
 provide needs to be use WebCore and should be
 accessible to HTML page author. So I will be drilling some holes to
 expose these modules as a finite set of JavaScript objects.
 
 --
 Chinmaya
 
 
 
 On Tue, Aug 24, 2010 at 1:23 PM, Peter Kasting pkast...@google.com wrote:
 On Tue, Aug 24, 2010 at 12:21 PM, Chinmaya Sn chinm...@gmail.com wrote:
 
 I have special case in my hand; currently I maintain a custom branch
 of WebKit, I already have
 implemented a module which sits closely with WebCore and it works just
 fine. One of my
 goals is to deliver these changes back to community and even may be
 back to WebKit repository. In near
 future I will be implementing at least 2-3 such modules, which work
 closely with WebCore and
 JavaScriptCore but they may not have to anything to do HTML browser
 engine as such.
 
 Why don't you say more about what you're trying to do.  It's hard to answer
 in the abstract.
 PK
 
 
 
 
 
 
 --
 Chinmaya
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Web Audio API

2010-08-24 Thread Maciej Stachowiak


This sounds like a reasonable plan. I have no strong feelings about any of the 
naming options, but I like the overall idea of getting this code into trunk 
now, using a feature define, and separating the Web-facing parts from the 
platform implementation parts.

 - Maciej

On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote:

 Over the past months I've been refining the web audio API implementation that 
 I've been developing in the 'audio' branch of WebKit (per Maciej's 
 recommendation).  The API has been through a good amount of review by WebKit 
 developers at Apple, Google, and in the W3C Audio Incubator  group.  For 
 those who are interested, the draft specification is here:
 http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html
 
 I have working demos here:
 http://chromium.googlecode.com/svn/trunk/samples/audio/index.html
 
 I'll be posting a series of patches to migrate the working code from the 
 audio branch to WebKit trunk.  Most of the files are new, with only a few 
 places which will touch existing WebKit files (such as EventTarget, Event).  
 The files will be conditionally compiled.  I'm considering using the 
 following enable:
 
 #if ENABLE(AUDIOCONTEXT)
 
 After discussing the directory layout in some detail with Eric Carlson, Chris 
 Marrin, Simon Fraser, and Jer Noble, we've decided that the files will 
 primarily live in two places:
 
 WebCore/audio
 WebCore/platform/audio
 
 I know that some had expressed concern that a directory called 'audio' in 
 WebCore would be confused with the audio element.  The reason I think 'audio' 
 would be a good name is because the API does have a direct relationship to 
 the audio element and, over time, when the API becomes more broadly used will 
 be associated with the audio capabilities of the web platform.  That said, if 
 anybody has grave concerns over this name, then we can discuss alternatives.
 
 Anyway, I just wanted to bring these coming changes to everyone's attention.
 
 Regards,
 Chris Rogers
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] AXObjectCache memory management?

2010-08-23 Thread Maciej Stachowiak


On Aug 23, 2010, at 12:47 AM, Eric Seidel wrote:

 Does anyone know why AXObjectCache is not ref counted?  It has some
 manual scheme which seems likely to have bugs in it.
 
 http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp#L1742
 
 There just seems to be a lot of code in Document to manage this simple cache.

I don't know the history of this code, but I suspect refcounting would work.

Note: a bunch of the complexity there is to ensure there is only one 
AXObjectCache per frame/document tree, but still keep it in a member of 
Document. Using refcounting would get rid of the explicit new/delete calls, but 
would not greatly simplify the overall logic.

If there is only supposed to be one per top-level document rather than one per 
document, perhaps it should live off of Page. Then it could follow single 
ownership and be held by an OwnPtr. It would add more indicrection to accessing 
it, but would save multiple function calls and branches, so probably not a 
performance issue. I believe there is no need to ever get AXObjects for a 
Document that is not currently held by a Frame that belongs to a Page. 

Of course, refcounting would still be fine in this case, these objects are not 
so common that a refcount field is an extravagant expense. My point is mainly 
this: I believe the key design problem is that the AXObject cache is held by 
Document instead of Page even though our goal is to have one per Page.

I expect we have enough regression tests for accessibility to try this change.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Can someone explain tx/ty?

2010-08-23 Thread Maciej Stachowiak


On Aug 23, 2010, at 12:51 AM, Eric Seidel wrote:

 I believe int tx, int ty -- which we see sprinkled around the
 rendering tree -- are the offset from the top left corner of the
 current renderer's parent to the containing block.  Is that correct?
 
 In SVG we use IntSize containingBlockOffset in the rare places we have
 to deal with this RenderBoxModelObject-only concept.
 
 I've long considered fixing renders to use IntPoint and IntSize
 instead of x, y, tx, ty, but to do that, I need to make sure I
 understand what tx, ty are, and what name they should have as an
 IntSize.

I think it would be good to use IntPoint and IntSize in more places in the 
render tree.

My understanding of tx/ty is imperfect so you may want to have a rendering guru 
weigh in, but I believe it works like this:

- x(), y() are a renderer's position in the coordinate system of its parent

- tx, ty are the origin of the parent's coordinate system relative to the 
origin for its layer. When a layer paints, it establishes a CTM such that its 
own origin is 0, 0 (I think).

When a renderer paints, the first thing it does is add its own x() and y() to 
tx and ty, and it passes the new values of tx and ty to its children.

There's two ways to express this in size/point terms. First, some rules for 
Point / Size math:

- You can add a Size to a Point to get a new Point.
- You can add a Size to a Size to get a new Size.
- It doesn't make logical sense to add two Points, so the operation doesn't 
exist. Points are absolute and Sizes are relative; you can't add two absolutes.

The more obvious way, given the variable names, would be to make x(), y() an 
IntPoint, with a name like originInParentCoordinates() (hopefully less verbose, 
but you get the idea). tx, ty could be named parentOffsetFromLayerCoordinates 
or something. This seems to be the intent of the names - that x,y is a point 
and tx, ty is a translation. But this doesn't work in point/size logic. You 
repeatedly add x(), y() to tx, ty to get a new tx, ty. But that means you're 
adding a point to a size and expecting to get a new size - but that's not how 
it works.

The way that works is to reverse the logic. tx, ty becomes IntPoint 
parentOrigin. x(), y() becomes IntSize offsetFromParent(). You add your 
offsetFromParent() to your parentOrigin to get the parentOrigin you pass from 
your children. This reverses the idea of which is the point and which is the 
offset, but it fits the axioms of point/size arithmetic and I believe it is 
ultimately more logical. You can see this in part from the shorter names. The 
first line in a ::paint() method would be IntPoint origin = parentOrigin + 
offsetFromParent(). How sweet is that?

(Note: I omitted many details here, such as accounting for scroll offsets. 
Renderers that are scrolled account for the scroll offset in the tx, ty they 
pass their children even though this is not strictly their *own* origin.)

BTW I have rewritten parts of render tree logic before to use IntPoint, 
IntSize, and point/size operations instead of dealing with individual 
coordinates, and I always found the code far more readable. This is 
particularly so when I stopped to figure out what should be a size and what 
should be a point based on the axioms of point/size arithmetic.

Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Not enough space message when linking webkit (lots of free disk space)

2010-08-23 Thread Maciej Stachowiak


On Aug 23, 2010, at 2:38 AM, Eric Seidel wrote:

 SVG gets such a bad wrap. :)  Wouldn't breaking WebCore into smaller
 libraries fix these linker problems longer-term?  For example,
 breaking out platform into a .a, or the JS bindings?  I guess we'd
 have to make them .dylib instead of .a if we wanted to actually make
 the linker happier.

Making multiple .a files wouldn't really do anything - they are just archives 
of .o files and linking them into a shared library would still be just as 
expensive. Splitting into multiple .dylib/.so/.dll's would impose a runtime 
cost, which I think is not a good tradeoff for faster linking (and easier 
linking with less memory).

A long time ago in the mysterious pre-history of WebKit, I had the WebCore 
build set up to build a separate relocatable object file per directory, and 
then link them all into a final dynamic library. This does partial linking, 
making the final linker step less expensive, though I don't know how much less 
memory it would use.

The command-line tools know how to do this, but Xcode does not, so we lost this 
feature once we adopted Xcode. It made linking significantly faster with no 
runtime cost. I am not sure if it would still work today or if there is a 
similar approach on Windows. To be more specific, what I used is 'ld -r', which 
works with both the Mac OS X linker and GNU ld. I believe Visual Studio also 
has an incremental linking feature, but I don't know how it works or whether we 
are using it currently.

Regards,
Maciej


 
 On Mon, Aug 23, 2010 at 2:26 AM, Jeremy Orlow jor...@chromium.org wrote:
 The Kernel usually reserves 1/4 (but up to 3/4 on some OSes) of the address
 space for itself + you can get fragmentation.  So the linker only can use
 part of the 4gb of ram in your machine.  So switching to a 64 bit linker
 would probably fix the problem for now.  Another option is to disable some
 parts of WebKit you don't need (like SVG).
 J
 
 On Mon, Aug 23, 2010 at 3:26 AM, Chris Hatko cha...@gmail.com wrote:
 
 Hi Nico,
 
 Yes, I've got 32 bit MSVS2005. I found that turning off  /LTCG and /GL
 optimization allowed me to get past this error. Do we now need more
 than 4Gigs of RAM to compile webkit with release optimizations?
 
 Chris
 
 On Sun, Aug 22, 2010 at 4:09 PM, Nico Weber tha...@chromium.org wrote:
 Are you using a 32 bit linker? Maybe it's running out of address space.
 
 Nico
 
 On Sun, Aug 22, 2010 at 12:32 PM, Chris Hatko cha...@gmail.com wrote:
 I'm running revision 65648  and building cairo-win32 release I'm
 getting Not
 enough space when linking WebKit project. I have 40Gig free space on
 this drive and 4Gigs of ram.
 
 Linking...
 11fatal error C1083: Cannot open compiler intermediate file:
 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not
 enough space
 11LINK : fatal error LNK1257: code generation failed
 11Build log was saved at
 
 file://C:\cygwin\home\HATKO\WebKit\WebKitBuild\obj\WebKit\Release_Cairo\BuildLog.htm
 11WebKit - 1 error(s), 1 warning(s).
 
 Any idea what I can try?
 
 Thanks,
 
 Chris
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Six new layout tests missing expected results

2010-08-18 Thread Maciej Stachowiak


Who knows what is up with these? I'm guessing they came from the same patch. 
Please fix if you know what these are about.

fast/table/simple_paint.html - new
tables/hittesting/filltable-emptycells.html - new
tables/hittesting/filltable-levels.html - new
tables/hittesting/filltable-outline.html - new
tables/hittesting/filltable-rtl.html - new
tables/hittesting/filltable-stress.html - new


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page


On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:

 Where-ever it goes, please don't put it on Document directly. :)
 (Feel free to tie it to Document's lifetime, just don't add to
 Document's 300+ methods.)
 
 The madness must stop...  Document is long overdue for some weightloss...

I assume Dean is suggesting that Document would gain a new data member 
(DeviceMotionController?) which strikes me as a reasonable approach.

 
 -eric
 
 On Mon, Aug 16, 2010 at 11:43 PM, Dean Jackson d...@apple.com wrote:
 Hi,
 
 I've been looking into implementing the clients for DeviceOrientation/Motion 
 Events. Currently, the controllers for these events are members of Page. I 
 think they are better suited on Document.
 
 Here are a few reasons:
 
 - Page isn't tied to any actual web page or document. Would we want to share 
 the same controller and client across multiple web pages? I don't think so.
 - Document is already the place that is listening for these events
 - It's easy to suspend and resume the client from the Document-level when 
 the user navigates to another page, or the document enters the cache, or a 
 platform needs to temporarily suspend events for some reason.
 - When the API is on Page, it is hidden in the WebView, from where it is 
 difficult to access.
 - it would allow the client to live in WebCore. This avoids tweaking the 
 WebView implementations for all platforms to pass messages back and forth
 https://bugs.webkit.org/show_bug.cgi?id=41616
 
 I assume one of the advantages of having them on Page is that it allows a 
 Mock Controller to be easily created for testing from Dump Render Tree. Am I 
 right? Is this that important?
 
 FWIW, Geolocation seems to take both approaches. One implementation is down 
 in Navigator/Document/DOMWindow, but the mock controller is on Page. I've 
 found the low-level approach much easier to implement.
 
 Thoughts?

For this sort of thing, it seems reasonable to me that there is a layer of the 
implementation that is a per-document controller, and then below that a 
singleton object in case we don't need things to happen multiple times per 
document. It doesn't seem especially helpful to have something happen at the 
Page level, in normal operation.

The reason it seems a singleton would be useful is that you only want to 
register with the OS service once, and then multicast the relevant 
notifications to all clients that are listening.

For purposes of substituting a mock controller:

(1) If there is a singleton beneath the per-document controllers, perhaps the 
mock object can insert itself at that level.
(2) Even if the mock controller is at the per-document level, it is likely 
still sufficient for most tests; it might mean a little extra work if we need 
to specifically test geolocation or device motion/orientation from a subframe.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does isLocationChange() return false for redirection?


On Aug 16, 2010, at 10:58 PM, Eric Zhou wrote:

 Hi all, 
 
 following is the related code. My question is why it returns false when 
 ScheduledRedirection.type is redirection.
 From the name of the function, I think if the url changes, it should return 
 true. Thus, for most of redirection, it should return true.

For these functions, I wouldn't assume that the name is necessarily logical. In 
any case it looks like you are looking at old-ish code - this code has been 
refactored on current trunk.

Regards,
Maciej

 
 //FrameLoader.cpp
 bool FrameLoader::isLocationChange(const ScheduledRedirection redirection)
 {
 switch (redirection.type) {
 case ScheduledRedirection::redirection:
 return false;
 case ScheduledRedirection::historyNavigation:
 case ScheduledRedirection::locationChange:
 case ScheduledRedirection::formSubmission:
 return true;
 }
 ASSERT_NOT_REACHED();
 return false;
 }
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page


On Aug 17, 2010, at 6:50 AM, Dean Jackson wrote:

 
 On 17/08/2010, at 12:22 AM, Maciej Stachowiak wrote:
 
 
 On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:
 
 Where-ever it goes, please don't put it on Document directly. :)
 (Feel free to tie it to Document's lifetime, just don't add to
 Document's 300+ methods.)
 
 The madness must stop...  Document is long overdue for some weightloss...
 
 I assume Dean is suggesting that Document would gain a new data member 
 (DeviceMotionController?) which strikes me as a reasonable approach.
 
 Right - either one or two (+DeviceOrientationController). I do think the 
 controllers of both events could be a single object - but that is another 
 discussion.
 
 If it wasn't on Document, what do you suggest otherwise? DOMWindow? Putting 
 it on Frame but tying it to Document seems less than perfect.

My specific advice was in the rest of my reply - trimming quotes so you can see 
it:

 For this sort of thing, it seems reasonable to me that there is a layer of 
 the implementation that is a per-document controller, and then below that a 
 singleton object in case we don't need things to happen multiple times per 
 document. It doesn't seem especially helpful to have something happen at the 
 Page level, in normal operation.
 
 The reason it seems a singleton would be useful is that you only want to 
 register with the OS service once, and then multicast the relevant 
 notifications to all clients that are listening.
 
 For purposes of substituting a mock controller:
 
 (1) If there is a singleton beneath the per-document controllers, perhaps 
 the mock object can insert itself at that level.
 (2) Even if the mock controller is at the per-document level, it is likely 
 still sufficient for most tests; it might mean a little extra work if we 
 need to specifically test geolocation or device motion/orientation from a 
 subframe.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cleaning up Document.* (was DeviceOrientation/Motion on Document rather than Page)


On Aug 17, 2010, at 9:35 AM, Eric Seidel wrote:

 My theory on re-organizing document is we do the same thing we've been
 doing to FrameLoader.  Just start lopping off chunks.
 
 My understanding is Adam was attacking FrameLoader by just grabbing a
 set of seemingly related member variables, throwing them in a separate
 class (in the same file) and hitting compile. :)  And then letting the
 compiler explain to you what functions you should be moving off of the
 big class and onto your new smaller class.
 
 Possible classes which could split of from Document:
 
 - A DOM API object (to handle all the actual api)

This one should just *be* Document. Our DOM objects are the DOM API. Some of 
the other pieces you mention might be reasonable chunks to break off.

Regards,
Maciej

 - An event handling object (see all the
 DEFINE_ATTRIBUTE_EVENT_LISTENER?  Maybe this is part of the DOM API
 object)
 - All the style computation junk uses*Rules, as well as the ownership
 of the styleselector, etc.
 - Form element tracking
 - Management of the Rendering Tree?  (RenderArena, RenderView should
 be owned by some renderingTree() object instead it seems)
 - Style and color management
 - Marker management (wow, that's a huge section of needlessly Document code!)
 - The JSC Wrapper cache
 - Dashboard support
 - URL management (base, cookies, etc.)
 - Stylesheet management (maybe part of style/color management above)
 
 That list was just from scanning Document.h
 
 There is clearly a huge amount of low-hanging fruit.  When Adam was
 cleaning up FrameLoader, and when we more recently re-wrote the
 DocumentParser infrastructure, we found and fixed *tons* of bugs when
 the code was split down into bite-sized chunks.  I suspect we'd find a
 bunch of dead code and bugs if we started ripping Document.cpp apart.
 
 -eric
 
 On Tue, Aug 17, 2010 at 11:20 AM, Dean Jackson d...@apple.com wrote:
 
 On 17/08/2010, at 7:21 AM, Eric Seidel wrote:
 
 My apologies for derailing your earlier discussion.  I just was in
 Document.cpp again yesterday and my mind was blown by the madness that
 is that god-class.  Then you posted about adding to Document (which
 sounds like the right corse of action here!) and I took advantage of
 your post for my stop-pooping-on-Document PSA.
 
 I too have 100% confidence in Dean here. :)  As Maciej says, it's just
 a controller on Document.
 
 Congratulations on being the first person to ever have confidence in me :)
 
 I too would like to know how to reorganise Document better. It is HUGE. 
 Seeing as you are discussing similar topics on IRC with EricC, maybe now is 
 the time to bring it up.
 
 Dean
 
 
 Carry on.
 
 -eric
 
 On Tue, Aug 17, 2010 at 8:50 AM, Dean Jackson d...@apple.com wrote:
 
 On 17/08/2010, at 12:22 AM, Maciej Stachowiak wrote:
 
 
 On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:
 
 Where-ever it goes, please don't put it on Document directly. :)
 (Feel free to tie it to Document's lifetime, just don't add to
 Document's 300+ methods.)
 
 The madness must stop...  Document is long overdue for some weightloss...
 
 I assume Dean is suggesting that Document would gain a new data member 
 (DeviceMotionController?) which strikes me as a reasonable approach.
 
 Right - either one or two (+DeviceOrientationController). I do think the 
 controllers of both events could be a single object - but that is another 
 discussion.
 
 If it wasn't on Document, what do you suggest otherwise? DOMWindow? 
 Putting it on Frame but tying it to Document seems less than perfect.
 
 Dean
 
 
 
 -eric
 
 On Mon, Aug 16, 2010 at 11:43 PM, Dean Jackson d...@apple.com wrote:
 Hi,
 
 I've been looking into implementing the clients for 
 DeviceOrientation/Motion Events. Currently, the controllers for these 
 events are members of Page. I think they are better suited on Document.
 
 Here are a few reasons:
 
 - Page isn't tied to any actual web page or document. Would we want to 
 share the same controller and client across multiple web pages? I don't 
 think so.
 - Document is already the place that is listening for these events
 - It's easy to suspend and resume the client from the Document-level 
 when the user navigates to another page, or the document enters the 
 cache, or a platform needs to temporarily suspend events for some 
 reason.
 - When the API is on Page, it is hidden in the WebView, from where it 
 is difficult to access.
 - it would allow the client to live in WebCore. This avoids tweaking 
 the WebView implementations for all platforms to pass messages back and 
 forth
 https://bugs.webkit.org/show_bug.cgi?id=41616
 
 I assume one of the advantages of having them on Page is that it allows 
 a Mock Controller to be easily created for testing from Dump Render 
 Tree. Am I right? Is this that important?
 
 FWIW, Geolocation seems to take both approaches. One implementation is 
 down in Navigator/Document/DOMWindow, but the mock controller is on 
 Page. I've found the low-level approach much easier

Re: [webkit-dev] Tests that separate JS and HTML

2010-08-16 Thread Maciej Stachowiak


On Aug 16, 2010, at 12:44 PM, Ojan Vafai wrote:

 I agree that dealing with the script to generate tests and having the actual 
 test content be in a different file is a significant maintenance overhead. 
 But I also think that having standard testing code across many tests reduces 
 the amount of effort it takes to understand a test.
 
 We discussed this at 
 https://lists.webkit.org/pipermail/webkit-dev/2010-July/013673.html. I think 
 Maciej's solution sounds ideal, although I'm not convinced it's worth 
 including doctype for news tests.

I think it is. Tests should be in strict mode by default, unless you 
specifically have a goal of testing quirks mode behavior. Quirks more is more 
likely to have weird pitfalls or to change in unexpected ways over time. No 
doctype == quirksmode, for HTML anyway. XML-based tests (including XHTML, 
MathML and SVG) don't need a doctype. And really, !DOCTYPE html is hardly a 
burden on either the reader or the writer. The short, memorable doctype is one 
of my favorite things about HTML5.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system complexity


On Aug 12, 2010, at 2:53 AM, Jeremy Orlow wrote:

 Are there currently any plans for simplifying the situation regarding build 
 systems?  I haven't seen any threads for a while, which I assume means no.
 
 Is there any low hanging fruit out there?  Since many of the build systems 
 are little more than lists of files, it really seems like we should be able 
 to do some sort of consolidation.  Or reduce the process down to updating one 
 file and then running a script that updates/generates the rest.  Currently, I 
 cringe every time I find out I need to add a new file.
 
 In addition, has anyone ever looked at simplifying the mac port's xcode 
 project?  It's _by far_ the heaviest burden on the project given that you 
 pretty much need to use xcode (which is mac only...no other port requires 
 this), exported linker symbols are in a separate file, extra effort to expose 
 a new file in WTF to WebCore, extra effort to expose a new file in WebCore to 
 WebKit, etc.  Has anyone recently looked at how the mac build could be 
 simplified--especially from the perspective of contributors whose main 
 development platform isn't a mac?

I think we should switch over to export control specified in the headers and 
not use .exp files any more. WebKit2.framework builds on all its target 
platforms with no external export control file. The hardest case for this is 
probably WebCore, though, and I'm not sure how practical it is to do 
incrementally.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses


On Aug 12, 2010, at 8:08 PM, Mihai Parparita wrote:

 I was wondering if it would be a reasonable change to make accessing 
 location.href (and other location properties) throw SECURITY_ERR when 
 accessed across origins (https://webkit.org/b/43504). This initially was 
 reported on the Chrome side (giv), but it looks like neither the JSC nor V8 
 bindings do this, so fixing it across the board seemed reasonable.
 
 From my investigations, it looks like IE and Gecko both throw an exception in 
 this case, and the HTML5 spec mentions it too 
 (http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location).
 
 I realize that we're cautious around the access checks for security reasons 
 (based on changes like https://trac.webkit.org/changeset/48619), but this 
 seems safe since 1) we were returning control to the script at that point 
 anyway 2) we already throw exceptions in some cases in that code: 
 https://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L219

I think what we do is better than what HTML5 specifies for this:

1) It means the access control goes in fewer places - we don't have to have 
access control on every document property, only window properties.

2) If access is denied for security reasons, it seems like it gives the 
attacker less information and less potential attack surface to just give them 
an undefined value instead of raising a security exception. Security errors 
make it easier to probe.

So in general I'm not in a rush to change this. However, if the original bug 
involved a compatibility problem on a real site (it doesn't really say), then 
maybe that would be a stronger reason to change.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] js binding: function argument type checking


I think doing type checks in the bindings makes sense as a long-term strategy. 
Only the bindings level can tell actually detect wrong type errors; the C++ 
layer can't distinguish wrong type from a validly passed null. WebGL interfaces 
are not the only ones that have this problem. Here is a DOM Core example of the 
bug:

document.body.insertBefore(document.createElement(div), foo)

This will append a div to the body, when it should throw.

As far as tactics go:

1) I think it's much better to deploy this gradually than to all bindings at 
once; if a pervasive change causes a regression, then the regression becomes 
much harder to track down.

2) In many cases, this *will* change behavior. When deploying the new approach 
to methods where it changes behavior, we should create regression tests showing 
the behavior change.

Regards,
Maciej


On Aug 12, 2010, at 7:11 PM, Sam Weinig wrote:

 As I mentioned, I am not necessarily against ever changing the behavior, but 
 if we do, we should make sure to remove all the existing checks, as they 
 become an unnecessary branch.  It just seems to me like that should be a 
 separate change than a bug due to ambiguity.
 
 -Sam
 
 On Thu, Aug 12, 2010 at 4:21 PM, Kenneth Russell k...@google.com wrote:
 For what it's worth, I think this change should be made for all of the
 DOM bindings, not just those for WebGL. The IDL code generators'
 support for overloaded methods already generates TypeError when an
 incoming argument doesn't implement any of the interfaces required by
 the overloaded variants. The new behavior will be closer to the rules
 specified by Web IDL in
 http://dev.w3.org/2006/webapi/WebIDL/#es-interface and also, as I
 understand it, closer to what Firefox implements.
 
 It would be possible to add support for another extended attribute to
 the code generators and annotate all of the methods in
 WebGLRenderingContext.idl, but I really think the default behavior
 should be changed.
 
 -Ken
 
 On Thu, Aug 12, 2010 at 1:15 PM, Mo, Zhenyao zhen...@gmail.com wrote:
  Hardly.  Right now we already do the type checking in the generated
  toType(argument) functions.  Instead of casting to null, we throw a
  TypeError, which adds no extra cost if the type is correct.
 
  Besides, where I looked, after toType(argument) call, exception is
  checked.  Only that currently toType(argument) is not generating
  exceptions.
 
  Mo
 
  On Thu, Aug 12, 2010 at 9:20 AM, Sam Weinig sam.wei...@gmail.com wrote:
 
 
  On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher da...@chromium.org wrote:
 
  On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig sam.wei...@gmail.com wrote:
 
  On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier cedr...@neonux.com
  wrote:
 
  On Thu, Aug 12, 2010 at 13:26, Sam Weinig sam.wei...@gmail.com wrote:
 
  For this specific case, it seems like you could easily check for a null
  WebGLProgram* in WebGLRenderingContext::useProgram and set the
  ExceptionCode.
 
  Nope, null is a valid argument, it bounds to the initial program, which
  means nothing will be drawn with WebGL.
  Certainly not the expected behavior when one pass the wrong type to the
  argument like Zhenyao pointed out, therefore throwing TypeError really 
  makes
  sense here (and elsewhere with WebGL API).
 
  Ok, in that case, it seems like you need to do it in the bindings for
  this. I would prefer not making a sweeping change at this time, and 
  instead
  keeping the changes just to places where the extra checking is necessary 
  due
  to ambiguity (as in this useProgram case).
  -Sam
 
  Out of curiosity, if we have the ability for code to be auto generated
  from the IDL, why not use it universally?  I'm trying to guess to 
  understand
  your preference :)
  -Darin
 
  My concern with doing it universally is the performance cost of doing the
  check twice in many places (once in the bindings and once in the
  implementation with a null check). We could certainly re-evaluate the way 
  we
  do these type checks, potentially even converting the existing null checks
  in the implementation to asserts, but I think that discussion shouldn't be
  conflated with this bug fix.
  -Sam
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses


On Aug 13, 2010, at 2:12 AM, Jeremy Orlow wrote:

 On Fri, Aug 13, 2010 at 8:42 AM, Maciej Stachowiak m...@apple.com wrote:
 
 On Aug 12, 2010, at 8:08 PM, Mihai Parparita wrote:
 
 I was wondering if it would be a reasonable change to make accessing 
 location.href (and other location properties) throw SECURITY_ERR when 
 accessed across origins (https://webkit.org/b/43504). This initially was 
 reported on the Chrome side (giv), but it looks like neither the JSC nor V8 
 bindings do this, so fixing it across the board seemed reasonable.
 
 From my investigations, it looks like IE and Gecko both throw an exception 
 in this case, and the HTML5 spec mentions it too 
 (http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location).
 
 I realize that we're cautious around the access checks for security reasons 
 (based on changes like https://trac.webkit.org/changeset/48619), but this 
 seems safe since 1) we were returning control to the script at that point 
 anyway 2) we already throw exceptions in some cases in that code: 
 https://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L219
 
 I think what we do is better than what HTML5 specifies for this:
 
 1) It means the access control goes in fewer places - we don't have to have 
 access control on every document property, only window properties.
 
 2) If access is denied for security reasons, it seems like it gives the 
 attacker less information and less potential attack surface to just give them 
 an undefined value instead of raising a security exception. Security errors 
 make it easier to probe.
 
 So in general I'm not in a rush to change this. However, if the original bug 
 involved a compatibility problem on a real site (it doesn't really say), then 
 maybe that would be a stronger reason to change.
 
 Regards,
 Maciej
 
 If we're willfully going against the spec because we think our solution is 
 better, should this be brought up on WhatWG or in the HTML WG?  (Or has it 
 already?)

It might be, but before taking that step, I'm really curious if the bug that 
sparked this discussion was based on a real compat issue that the author ran 
into.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-11 Thread Maciej Stachowiak


On Aug 9, 2010, at 8:21 PM, Timothy Hatcher wrote:

 On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote:
 
 I am very, very tempted to just get rid of them. As Ojan indicated,
 the use cases for DOM Mutation events are extremely limited and to me,
 most of them feel like we should be solving them differently anyway.
 
 However, with the introduction of extensions into Chromium and Safari,
 DOM Mutation events experience a sort of renaissance, being used to
 sense the DOM changes to re-apply modifications (rewrite URLs, text,
 etc.).
 
 So I think we will upset a bunch of extensions developers if we just
 go cold turkey, which is probably not the right thing -- regardless of
 whether techniques they employ are sound or not.
 
 With this in mind, I think we should do #1 and #3, then #2 after some
 time and loud over-communication (like Inspector warnings, blog posts,
 billboards on Hwy 101 etc.).
 
 
 Adding input/beforeinput events (#3) wont solve the need of most extension 
 developers that use mutation events today (the examples you cite). So that 
 makes it hard to remove them, especially over time, no matter how much 
 warning you give.

Would it satisfy extension use cases if DOM mutation events got batched and 
dispatched asynchronously as the generic DOMSubtreeModified?[1] Do extensions 
need detailed change notification, or is a general something changed 
notification good enough?

I think reducing mutation event support down to just DOMSubtreeModified, and 
firing it only at the very end of operations that should be atomic, would 
greatly reduce the risk of mutation-event-induced crashing, but would probably 
still serve the key use cases.

For performance reasons, it would be even better to have a type of notification 
that doesn't have to allocate an event object, as that is a large part of the 
performance hit from mutation events. I gather that is what the fancier new 
mutation events proposal does.

Regards,
Maciej

[1] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMSubtreeModified
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why are we running Sputnik?

2010-08-11 Thread Maciej Stachowiak


On Aug 10, 2010, at 2:26 PM, Alexey Proskuryakov wrote:

 
 10.08.2010, в 14:00, Adam Barth написал(а):
 
 A better long-term fix might be to finish new-run-webkit-tests so we
 can run the tests in parallel.
 
 
 One reason to move the tests to run-javascriptcore-tests is that people 
 working on JS run these more often (sometimes not even building WebCore until 
 ready to submit a patch).

If these tests can catch regressions from non-JS-engine changes (and according 
to Adam's message, they have done so at least once), then we need to run them 
in the full browser engine context, even if we also have a version that runs in 
a JS-only command-line tool.

As another data point, some of the Sputnik tests are currently failing in 
WebKit2 on Mac, so they are detecting a problem that they wouldn't be able to 
if they ran JS-only.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Fwd: webkit editing rewrite?

2010-08-05 Thread Maciej Stachowiak


On Aug 4, 2010, at 6:12 PM, Ojan Vafai wrote:

 
 On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen gga...@apple.com wrote:
 -Ensures that the APIs we expose to the web are at least good enough for 
 our own editing code
 
 I don't think this necessarily follows. Not everything exposed to the 
 internal editing implementation would necessarily be exposed to the web. If 
 we required that everything exposed to the internal editing implementation 
 be exposed to the web, that would substantially slow development, since 
 every new API would need to be vetted and possibly standardized. So this is 
 either not true or a substantial con.
 
 This would have been a fine point without the last sentence here. I'm
 not sure how to read that sentence without the implication that I'm
 either being stupid or manipulative. FWIW, I do think that everything
 exposed to the internal editing implementation should eventually be
 exposed to the web. I'll expand on that below.

I think Geoff is not saying that you are stupid or manipulative, just that he 
disagrees with your conclusion. There are many reasons someone could be wrong, 
for example that they are honestly mistaken. When I think someone is wrong, I 
usually assume they are honestly mistaken  and can probably be persuaded 
through logic. Or else, perhaps I am mistaken and will learn that through 
discussion. When someone else disagrees with me and says I am wrong, I try to 
assume they thought I made an honest mistake. Sometimes people actually do 
think I am stupid or are stupid themselves, but I find it makes technical 
discussions go better if I don't focus on those possibilities.

Short version: let's all try to assume good faith on the part of our fellow 
webkit-dev posters.

(That being said, I think a few parts of Geoff's message were a little too 
snarky, but I think the point you cited here is a reasonable one and not stated 
in an overly combative way.)

 On Tue, Aug 3, 2010 at 4:38 PM, Darin Adler da...@apple.com wrote:
 Inventing a new layer to rebuild editing on top could well be good. Exposing 
 that layer itself to webpages seems like it makes the job even harder rather 
 than easier! Hidden implementation details can be changed more easily than 
 exposed APIs.
 
 I agree that these can be separated out. 1 and 2 are the ones I really
 care about. 3 and 4 were just an idea of one way to get there. I'm not
 attached to them.
 
 I was picturing that we would first implement all or most of our
 editing code on top of the editing API and then, once we were
 confident with it, expose it as a webkit prefixed set of APIs that we
 propose to the appropriate standards body. I'd like to see an approach
 to this where we move (incrementally) in the direction of a clearly
 defined editing API that the editing code uses that we can eventually
 expose to the web.
 
 I'll try and make some concrete proposals in the coming days.

I think this carries an assumption that the right internal abstractions are 
necessarily also a sensible public API. I don't know if that is a good 
assumption. 

First: It is tempting to argue along the lines of the pieces needed to 
implement API X must be powerful primitives which should be exposed as API in 
their own right. But at some level, there has to be a next layer of 
implementation down that is not exposed, so clearly this line of argument has 
limits. It can't be API turtles all the way down.

Second, often the right internal implementation strategy bears very little 
relation to the proper public API. For example, CSS is a reasonable 
constraint-based system to express layout and style rules. Web designers seem 
to get along ok with it. But internally it's implemented via the render tree, 
which is a very different abstraction, though it relates to CSS concepts. 
Exposing the render tree in every detail would greatly constrain our ability to 
change implementation strategy in the future. So this is one clear-cut case 
where the implementation abstractions do not necessarily make sense as API. To 
give a simpler and more pervasive example, we use refcounting throughout many 
pieces of WebCore, but it would not be appropriate to expose to Web content 
because it's too low-level. I could cite endless examples where the public API 
exposed to Web content ends up very different from internal abstractions. The 
DOM is probably the one major subsystem where there is a lot of similarity, and 
even then, many critical implementation interfaces are not exposed, nor should 
they be.

Third, in the case of editing specifically, much of the existing behavior, in 
response to user actions and things like the execCommand API, has *really* 
weird quirks. And some of its behavior is probably wrong in light of what other 
browsers do. It may be that the pieces needed to build all those quirky 
behaviors are not really sane as a public API.

Overall, I think the API design process should work in the opposite direction. 
You don't start by building

Re: [webkit-dev] webkit editing rewrite?

2010-08-04 Thread Maciej Stachowiak


On Aug 3, 2010, at 4:38 PM, Darin Adler wrote:

 Inventing a new layer to rebuild editing on top could well be good. Exposing 
 that layer itself to webpages seems like it makes the job even harder rather 
 than easier! Hidden implementation details can be changed more easily than 
 exposed APIs.
 
 I personally don’t think a complete rewrite is a great idea, nor do I think 
 that using JavaScript is how I’d do it.

I strongly agree with these points.

In addition I'd add, there seem to be multiple large changes proposed under the 
complete rewrite heading:

(1) A new editing API exposed to Web content.
(2) A new set of fundamental abstractions to build editing on top of (which 
maybe has to be the same as #1?)
(3) A change in implementation language for much of the editing code from C++ 
to JavaScript.
(4) A from-scratch rewrite of the whole editing subsystem, rather than an 
incremental refactoring.

Each of these seems like a very high-risk project. Doing all four at once seems 
to put the risk into the red zone. My idea of how to make these kinds of 
changes would be to do one at a time, and probably not do #3 or #4 at all. 
Rewriting is almost never a better option than refactoring.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Some new coding style rules

2010-08-04 Thread Maciej Stachowiak


On Aug 4, 2010, at 10:43 AM, Darin Adler wrote:

 On Aug 4, 2010, at 1:29 AM, Nikolas Zimmermann wrote:
 
 1. namespace closing brace
 It was discussed in 
 http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10563, but with no 
 real result.
 
 When writing headers, do we need the // namespace Foo comment after the 
 namespace closing brace? I think it's visual noise and would like to see a 
 style rule that forbids it.
 (A rule that says we need this would also be fine with me, as long as we 
 write it down. But I'd vote for removing those comments, I don't trust them 
 anyways, if I'm unsure.)
 
 namespace WebCore {
 ...
 } // namespace WebCore
 
 My personal preference: We should omit it.
 
 2. ENABLE(FOO) #endif comments
 
 #if ENABLE(FOO)
 ..
 #endif // ENABLE(FOO)
 
 Shall we remove the comment, or require it explicitely in the style rules?
 
 My personal preference: We should omit it.

Comments at the end of an #if block can help code readability if the #ifs are 
nested. 

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Updating the tradition for new reviewer blog posts

2010-08-02 Thread Maciej Stachowiak


On Aug 2, 2010, at 1:56 PM, Adam Barth wrote:

 I'd be happy to write more posts for Surfin' Safari, but I don't know
 if I need approval, etc.

You don't need approval.

 - Maciej

 
 Adam
 
 
 On Mon, Aug 2, 2010 at 1:31 PM, Eric Seidel e...@webkit.org wrote:
 Woh.  I think that's an awesome idea. :)
 
 Would also make sure that all reviewers are blog-enabled.
 
 Might be a bit to ask of new reviewers though.
 
 -eric
 
 On Mon, Aug 2, 2010 at 11:56 AM, Tony Gentilcore to...@chromium.org wrote:
 The Surfin' Safari blog seems to have fairly wide readership in the web dev
 community. Google Reader reports 35k Reader subscribers. For comparison:
 blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last
 post with descriptive content was back on April 18th. Since that post, we've
 written 8 X is a now a WebKit reviewer posts. One recent commenter said:
 I don’t suppose there’s anything more interesting going on in WebKit land
 worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t
 nearly as interesting as whatever new hotness is coming down the pipe. And I
 know I’m not the only one who thinks so… Feel like blogging about WebKit
 awesomeness?
 
 I propose we increase the amount of blogging about WebKit awesomeness by
 changing the tradition for new reviewer posts.
 
 Instead of defaulting to:
 
   So-and-so is now a WebKit reviewer
   Posted by Someone-else
   So-and-so has worked on awesome-feature or awesome-infrastructure...
 
 We encourage (or just allow?) a format more like:
 
   How awesome-infrastructure works
   Posted by So-and-so, the latest WebKit reviewer
   Here's my description of how awesome-infrastructure works in WebKit...
   -OR-
 
   Awesome-feature is the new hotness
   Posted by So-and-so, the latest WebKit reviewer
   Web developers can now use awesome-feature. Here's how it works...
 
 Thoughts?
 -Tony
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Updating the tradition for new reviewer blog posts

2010-08-02 Thread Maciej Stachowiak


I agree that it would be good to have more useful and interesting content. I 
don't think it's good to do this by forcing the task on new reviewers. Not 
everyone enjoys a writing exercise and it shouldn't be required to become a 
reviewer. However, I encourage people to post about cool WebKitty stuff!

 - Maciej

On Aug 2, 2010, at 11:56 AM, Tony Gentilcore wrote:

 The Surfin' Safari blog seems to have fairly wide readership in the web dev 
 community. Google Reader reports 35k Reader subscribers. For comparison: 
 blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last 
 post with descriptive content was back on April 18th. Since that post, we've 
 written 8 X is a now a WebKit reviewer posts. One recent commenter said:
 
 I don’t suppose there’s anything more interesting going on in WebKit land 
 worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t 
 nearly as interesting as whatever new hotness is coming down the pipe. And I 
 know I’m not the only one who thinks so… Feel like blogging about WebKit 
 awesomeness?
 
 I propose we increase the amount of blogging about WebKit awesomeness by 
 changing the tradition for new reviewer posts.
 
 Instead of defaulting to:
 
   So-and-so is now a WebKit reviewer
   Posted by Someone-else
   So-and-so has worked on awesome-feature or awesome-infrastructure...
 
 We encourage (or just allow?) a format more like:
 
   How awesome-infrastructure works
   Posted by So-and-so, the latest WebKit reviewer
   Here's my description of how awesome-infrastructure works in WebKit...
 
   -OR-
 
   Awesome-feature is the new hotness
   Posted by So-and-so, the latest WebKit reviewer
   Web developers can now use awesome-feature. Here's how it works...
 
 Thoughts?
 
 -Tony
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Enabling the HTML5 tree builder soon

2010-07-29 Thread Maciej Stachowiak


For future reference, iBench can be found here:

ftp://ftp.pcmag.com/Benchmarks/i-bench/ib50.exe

However, it requires a Windows system with IIS to set up the server, and is 
generally a hassle to set up as Stephanie said.

Cheers,
Maciej


On Jul 28, 2010, at 10:09 PM, Adam Barth wrote:

 slewis++
 
 On Thu, Jul 29, 2010 at 3:15 AM, Stephanie Lewis sle...@apple.com wrote:
 I believe it is somewhere, but the setup is a hassle, so I'll run it 
 tomorrow for you.
 
 -- Stephanie
 
 On Jul 28, 2010, at 8:13 PM, Adam Barth wrote:
 
 On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak m...@apple.com wrote:
 On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:
 I measure it as a 1% win on the PLT.
 
 Might be a good idea to test HTML iBench as well.
 
 Sure.  I'd be happy to.  Is that benchmark available publicly?
 
 Adam
 
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Enabling the HTML5 tree builder soon

2010-07-27 Thread Maciej Stachowiak

On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:

I measure it as a 1% win on the PLT.

Might be a good idea to test HTML iBench as well.

- Maciej

-- Stephanie

On Jul 26, 2010, at 12:36 PM, Stephanie Lewis wrote:

I can do this.

-- Stephanie Lewis

On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:

Would someone from Apple be willing to run the patch below though the
PLT? We're doing well on our parsing benchmark (4% speedup), but the
PLT might have a different mix of HTML.

Thanks,
Adam

diff --git a/WebCore/html/HTMLTreeBuilder.cpp
b/WebCore/html/HTMLTreeBuilder.cpp
index 7a9c295..5b89c37 100644
--- a/WebCore/html/HTMLTreeBuilder.cpp
+++ b/WebCore/html/HTMLTreeBuilder.cpp
@@ -327,7 +327,7 @@ HTMLTreeBuilder::HTMLTreeBuilder(HTMLTokenizer*
tokenizer, HTMLDocument* documen
, m_originalInsertionMode(InitialMode)
, m_secondaryInsertionMode(InitialMode)
, m_tokenizer(tokenizer)
-, m_legacyTreeBuilder(shouldUseLegacyTreeBuilder(document) ? new
LegacyHTMLTreeBuilder(document, reportErrors) : 0)
+, m_legacyTreeBuilder(0)
, m_lastScriptElementStartLine(uninitializedLineNumberValue)
, m_scriptToProcessStartLine(uninitializedLineNumberValue)
, m_fragmentScriptingPermission(FragmentScriptingAllowed)

On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth aba...@webkit.org wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once
we do that, we'll have the core of the HTML5 parsing algorithm turned
on, including SVG-in-HTML. There are still a bunch of details left to
finish (such as fragment parsing, MathML entities, and better error
reporting), but this marks a significant milestone for this work.

The tree builder is markedly more complicated than the tokenizer, and
I'm sure we're going to have some bad regressions. I'd like to ask
your patience and your help to spot and triage these regressions.
We've gotten about as much mileage as we can out of the HTML5lib test
suite and the LayoutTests. The next step for is to see how the
algorithm works in the real world.

There are about 84 tests that will require new expectations, mostly
due to invisible differences in render tree dumps (e.g., one more or
fewer 0x0 render text). In about half the cases, we've manually
verified that our new results agree with the Firefox nightly builds,
which is great from a compliance and interoperability point of view.
The other half involve things like the exact text for the isindex,
which we've chosen to match the spec exactly, or the keygen element,
which needs some shadow DOM love to hide its implementation details
from web content.

As for performance, last time we ran our parser benchmark, the new
tree builder was 1% faster than the old tree builder. There's still a
bunch of low-hanging performance work we can do, such as atomizing
strings and inlining functions. If you're interested in performance,
let me or Eric know and we can point you in the right direction.

I don't have an exact timeline for when we're going to throw the
switch, but sometime in the next few days. If you'd like us to hold
off for any reason, please let Eric or me know.

Adam

P.S., you can follow along by CCing yourself on the master bug,
https://bugs.webkit.org/show_bug.cgi?id=41123, or by looking at our
LayoutTest failure triage spreadsheet,
https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEEhl=en.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.


On Jul 26, 2010, at 11:46 AM, Ryosuke Niwa wrote:

 Thanks a lot for the feedback!
 
 On Sun, Jul 25, 2010 at 5:07 PM, Maciej Stachowiak m...@apple.com wrote:
 I think the key question here is what counts as as formatting. That needs 
 to be determined empirically by testing other browsers, not just by reading 
 their docs.
 
 I agree, it's crucial that we carefully decide on what to preserve and what 
 to not.
 
 But MSDN explicitly say character formatting and bugs such as 
 Bug 13125 - removeformat execCommand loses input elements
 Bug 20216 - execCommand RemoveFormat removes links
 indicates that there is a demand to correct WebKit's behavior.

If our goal is to match other browsers, we need to test them, not read the 
docs. MSDN often bears little relation to IE's actual behavior.

 
 I agree.  We should test and see what other browsers do in various cases.
 
 But since it's impossible for us to enumerate every possible formatting, I 
 propose to just remove text-decoration, font-weight, etc... and the 
 corresponding presentational elements probably using ApplyStyleCommand as a 
 starting point.  We can then file a separate bug or so to uncover edge cases 
 and polish the behavior.

Sure it's possible. We can test every CSS property and every HTML element. It 
should be easy to write a test case that checks every case exhaustively. I 
don't think it makes sense to change our behavior based on a guess of what 
other browsers do.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Introducing dumpAsMarkup


On Jul 26, 2010, at 3:06 PM, Ryosuke Niwa wrote:

 If tests you write only require comparing DOMs, you want to read this.
 
 We've recently added dump-as-markup. It allows your tests to be platform 
 independent and gives output that is easier to read than render tree dumps. 
 For example, if I have:
 script src=../../resources/dump-as-markup.js/script
 div id=fooThis is a dumpAsMarkup test./div
 scriptwindow.getSelection().selectAllChildren(foo);/script
 
 Then I get:
 
 HTML
 HEAD
 SCRIPT src=../../resources/dump-as-markup.js/SCRIPT
 #text
 /#text
 /HEAD
 BODY
 DIV id=foo
 #textselection-anchorThis is a dumpAsMarkup test.selection-focus/#text
 /DIV
 #text
 /#text
 SCRIPT window.getSelection().selectAllChildren(foo); /SCRIPT
 #text
 /#text
 /BODY
 /HTML
 
 See Writing DumpAsMarkup Tests for more ways you can use dump-as-markup.js

Very cool! I suggest adding # signs to the selection pseudo-elements, just to 
avoid the tiny risk of conflicting with an actual element in a test. Also, 
perhaps it would be better to show tag names in lowercase - that can be 
achieved by using localName instead of nodeName or tagName.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.


On Jul 26, 2010, at 4:27 PM, Ryosuke Niwa wrote:

 
 On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak m...@apple.com wrote:
 I agree.  We should test and see what other browsers do in various cases.
 
 But since it's impossible for us to enumerate every possible formatting, I 
 propose to just remove text-decoration, font-weight, etc... and the 
 corresponding presentational elements probably using ApplyStyleCommand as a 
 starting point.  We can then file a separate bug or so to uncover edge cases 
 and polish the behavior.
 
 Sure it's possible. We can test every CSS property and every HTML element. It 
 should be easy to write a test case that checks every case exhaustively. I 
 don't think it makes sense to change our behavior based on a guess of what 
 other browsers do.
 
 I don't think that captures all possible formatting because CSS in particular 
 has interesting effects when combined with other styles. What I meant is that 
 we can't test every combination of all CSS properties  HTML elements (i.e. 
 enumerating every possible DOM with every possible combinations of CSS 
 properties applied every possible way on each DOM) simply because there are 
 infinitely many of them. Although I'd guess that some of them are reputations 
 so we might be able to find a finite subset that suffice the purpose. anyhow, 
 I agree that testing every CSS property and every HTML element will be a good 
 idea.  That'll at least give us a starting point.

I doubt any other browser behaves differently for a combination of CSS 
properties than for individual CSS properties. I guess it's possible but it 
seems unlikely.

I would note though that there is a finite set of possible combinations of CSS 
properties, if you pick a finite set of possible values to try for each, but it 
might be too large a set for the test to complete in a reasonable time frame.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Introducing dumpAsMarkup


On Jul 26, 2010, at 4:25 PM, Eric Seidel wrote:

 You can see many more examples of dom2string in the non-html5 results
 (where there are a zillion failure cases):
 http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected.txt
 
 dom2string.js came from http://code.google.com/p/html5lib I thought,
 but I couldn't find the source for it there.
 
 I'm not wedded in any way to dom2string.  But I do like the output it
 produces slightly more than the current dumpAsMarkup.  I agree,
 standardization might be nice.
 
 dom2string uses  for #text and /#text.  newlines return you to
 the start of the line as you would expect.  (see the
 runner-expected.txt above).
 
 -eric
 
 p.s. Would be nice if we could just inject certain javascript into
 every page.  Sorta like how v8 allows you to define engine-level
 functions in javascript.  Would be nice to just make dumpAsMarkup()
 part of DRT, but write it in javascript. :)

That's easy to do, DRT could just force loading of the JS file that implements 
dumpAsMarkup() (or whatever we end up calling it). But I'm not sure that is 
better than including a JS file in the test explicitly. For one thing, most of 
the logic to dumpAsMarkup() (other than forcing a text dump) should work in any 
other browser, so it would make it easier to try our tests in other browsers if 
the JS code implementing it is included explicitly instead of magically. It 
would also make the tests more useful to try in a WebKit-based browser like 
Safari or Chrome, for that matter - you wouldn't need DRT to see the output.

Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)


On Jul 26, 2010, at 5:46 PM, Ojan Vafai wrote:

 Then again it should be possible to re-write our script-test support
 so that this is all you need to write:
 
 script src=script-tests.js/script
 script
 description(foo);
 shouldBe(foo, bar);
 /script
 script src=end-script-test.js/script
 
 Instead of the current (cumbersome) templating system.  Should be
 possible to even get rid of the final end-script-test.js tag if
 we're smart.
 
 Yes! The templating system is just too much overhead, not to mention that it 
 creates too many files. There's a few minor issues with the above though:
 1. What if you want to include multiple js files? For example, then 
 editing/selection tests include two JS files. Maybe we should just move all 
 our JS code into one file?
 2. The src will need to be relative, so you'll need some ../.. action. But 
 that seems OK to me. Unless we had a script that put the JS files in every 
 directory (or maybe in the resources subdirectory of every directory).

The template in fast/js is currently this:

!DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN
html
head
link rel=stylesheet href=resources/js-test-style.css
script src=resources/js-test-pre.js/script
/head
body
p id=description/p
div id=console/div
script src=YOUR_JS_FILE_HERE/script
script src=resources/js-test-post.js/script
/body
/html

We could reduce it to this by having the test script document.write the 
skeleton content and the stylesheet (as an inline style to avoid having to 
guess a path), and by using the load event for the post-test script:

!DOCTYPE html
script src=resources/js-test-pre.js/script
script src=YOUR_JS_FILE_HERE/script

You don't want to drop the doctype because that would put the test in quirks 
mode (probably not desired for most tests).

This is simple enough to hand-author, and you could use an inline script for 
the script, and also add other custom content to the DOM if desired.

The main problem would be getting the right path to the script file. Unless we 
duplicate it in every directory with script tests, it kinda has to be a 
relative path that depends on the directory.

For pure JS tests (mostly ones in fast/js), I think it's a good idea to keep 
the script file separate so we can keep open the possibility of running these 
tests in a command-line JS shell and not just in a full web engine.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.

2010-07-25 Thread Maciej Stachowiak


On Jul 25, 2010, at 1:03 AM, Ryosuke Niwa wrote:

 Are there Apple or third-party products that heavily rely on the current 
 implementation of RemoveFormatCommand?
 If not, I want to completely re-implement RemoveFormat to match the behavior 
 of other browsers.
 
 In MSDN, RemoveFormat is described as:
 Removes the font and character formatting from the current selection.
 The following code removes all formatting from the selected text.
 
 ActiveDocument.execCommand removeformat
 
 In MDC, it's described as:
 Removes all formatting from the current selection.
 
 However, our current implementation deletes all selected contents and type 
 them back in,
 losing all sorts of elements such as input, img, hyper links, tables, lists, 
 and etc...
 
 There are two options to resolve this problem:
 Store all elements deleted and their positions and insert (restore) them back.
 Remove format more gracefully by walking through the DOM and removing 
 stylesheets and presentational elements.
 I want to re-implement RemoveFormat because I don't think option 1 really is 
 an option.

I think the key question here is what counts as as formatting. That needs to 
be determined empirically by testing other browsers, not just by reading their 
docs.

Here are some tricky questions:

- Does font-weight: bold count as formatting?
- Does the b element's default bold style count as formatting?
- Does the b element itself count as formatting?
- Does display: block count as formatting?
- Does the p element's display: block style count as formatting?
- Does the p element itself count as formatting?

You could make a rule that only non-default styles count as formatting, but 
it would seem weird if RemoveFormat allowed the selection to retain bold or 
italic text, so I wonder if other browsers actually do that.

You could ask similar questions about tables and lists. In particular, do we 
preserve table and list elements with their default styles, but CSS table or 
list layout properties are not allowed?

I think with information based on testing other browsers, and test cases 
demonstrating this behavior, we could make a more informed decision.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

2010-07-24 Thread Maciej Stachowiak


On Jul 23, 2010, at 1:10 PM, Dirk Pranke wrote:

 I have been thinking along these lines as well. I'm not sure how
 relevant touching existing lines of code is versus just other people
 who have hacked on the file at all or who have hacked on other files
 in the same directory (i.e., you'd need to address new code and new
 files, too). I think some empirical testing and tweaking would be the
 way to evaluate this, though.

To find a reviewer, what you want to find is people who understand the relevant 
subsystems well, and perhaps also people who are good reviewers in general 
(have a high likelihood of spotting avoidable problems). Making lots of commits 
to (or touching lots of lines in) the same file or the same directory are at 
best proxies for that kind of information. They may be better proxies for that 
kind of information than self-identification, but that has yet to be 
demonstrated. While an algorithm is a good starting point, I think 
self-identification and/or peer identification can capture nuances that an 
algorithm will not.

I think the main problems with http://trac.webkit.org/wiki/WebKit%20Team are 
that (a) people don't know to look there; and (b) people don't know or don't 
bother to update it. I don't think the accuracy of the information is a problem 
(other than possibly being out of date). I don't see how it is helpful to refer 
to this information as bragging.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

2010-07-22 Thread Maciej Stachowiak


On Jul 21, 2010, at 3:41 PM, Eric Seidel wrote:

 Wow.  I really like this idea of helping contributors better
 understand what's going wrong.
 
 But, I think that even better would be to build a better front-end for
 reviews.  Or a bot which knew how to suggest reviewers (based on
 annotate information from lines changed).


I think a better UI for reviews, plus some better attempts at active 
notification of potential reviewers, could go a long way. I'm a strong believer 
in trying nudges and positive incentives before implementing harsher policies.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

2010-07-21 Thread Maciej Stachowiak


On Jul 21, 2010, at 2:40 PM, Ojan Vafai wrote:

 There are currently 38 (of 171 total) patches in the review queue where the 
 bugs have not been modified in over 1 month old. I propose we have a bot that 
 educates people about writing easy to review patches and auto-rejects any 
 patches in bugs that haven't been touched in over a month. For people new-ish 
 to the WebKit project, it is often confusing both degree of responsibility 
 that lies with the contributor to make the patch easy to review and the need 
 to get reviewers' attention for a given patch.
 
 This is just an initial proposal. I'm not wed to any of the details of how 
 this would work. I do think that auto-rejecting old patches is valuable to 
 the project as a whole. Having the review queue be so large makes it daunting 
 for any reviewer to try and tackle it. On the other hand, knowing that 
 patches will magically fall off the end of the queue might encourage 
 reviewers to just ignore some patches.
 
 An alternative to auto-rejecting patches would be to send a nag email once a 
 week to webkit-reviewers@ with the list of patches that are over a month old.

I think we should try the nag email first. I like the idea of advice on how to 
get a review. I think automatic rejection is kind of unfriendly, so I'd like to 
try other steps first.

 - Maciej

 
 Here are my initial thoughts on what a review bot would do.
 
 After a patch turns a week old, send the following email:
 Patch 12345 of bug 6789 is a week old. It may just be because no reviewer has 
 found time to review it. But there may be steps you can take to help get your 
 patch reviewed. See http://trac.webkit.org/wiki/CodeReview for a few 
 suggestions.
 
 -WebKit review bot
 
 After the patch is three weeks old:
 Patch 12345 of bug 6789 is three weeks old. If it is still unreviewed in a 
 week, it will automatically be rejected. It may just be because no reviewer 
 has found time to review it. But there may be steps you can take to help get 
 your patch reviewed. See http://trac.webkit.org/wiki/CodeReview for a few 
 suggestions.
 
 -WebKit review bot
 
 After the patch is a month old:
 Patch 12345 of bug 6789 has been rejected because it is too old. This is 
 likely because no webkit reviewer has been able to review it. If you would 
 still like the patch reviewed, then please do the following:
 Make sure your patch still applies to tip of tree.
 Do as many of the suggestions at http://trac.webkit.org/wiki/CodeReview as 
 possible.
 Upload your patch for review again.
 -Webkit Review Bot
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SIL Open Font License and WebKit

2010-07-19 Thread Maciej Stachowiak


Apple's legal department would strongly prefer for WebKit's license terms to 
remain simple. We prefer everything to be licensed under LGPL or BSD terms, or 
at the very least a license which is clearly compatible with LGPL and BSD. Is 
this license LGPL-compatible for cases where the fonts are embedded as data in 
software?

For support material that has unusual license terms, another possibility is to 
have WebKit's support scripts automatically download it, rather than checking 
it directly into the repository.

Regards,
Maciej

On Jul 16, 2010, at 8:05 AM, Eric Seidel wrote:

 A little web searching produced:
 
 It's OSI approved:
 http://www.opensource.org/licenses/openfont.html
 
 GNU thinks it's OK, albeit having an unusual requirement:
 http://www.gnu.org/licenses/license-list.html#Fonts
 
 Fedora recommended:
 https://fedoraproject.org/wiki/Licensing#Font_Licenses
 
 It would appear to be the font license.
 
 -eric
 
 On Fri, Jul 16, 2010 at 5:05 AM, Alex Milowski a...@milowski.org wrote:
 We have a licensing issue we need to address for MathML.  We need the STIX
 fonts as they will provide consistent rendering for Mathematics.  I highly
 suspect these fonts will find themselves on our desktops somewhere down
 the road.  Meanwhile, we need them for our testing infrastructure to
 actually work across all the platforms.
 
 The STIX Fonts are available under the SIL Open Font License:
 
   http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=OFL_web
 
 You can see the patch that adds these fonts here:
 
   https://bugs.webkit.org/show_bug.cgi?id=41961
 
 I think we need to adjust our licensing policy to include font licenses
 like the above.  It is unlikely that the STIX consortium will change their
 font licensing.  In reality, they don't need to do so.  The font license is
 intended to support open source fonts.
 
 --
 --Alex Milowski
 The excellence of grammar as a guide is proportional to the paucity of the
 inflexions, i.e. to the degree of analysis effected by the language
 considered.
 
 Bertrand Russell in a footnote of Principles of Mathematics
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SIL Open Font License and WebKit

2010-07-19 Thread Maciej Stachowiak


On Jul 19, 2010, at 11:45 AM, Sausset François wrote:

 
 Le 19 juil. 2010 à 21:04, Maciej Stachowiak a écrit :
 
 
 Apple's legal department would strongly prefer for WebKit's license terms to 
 remain simple. We prefer everything to be licensed under LGPL or BSD terms, 
 or at the very least a license which is clearly compatible with LGPL and 
 BSD. Is this license LGPL-compatible for cases where the fonts are embedded 
 as data in software?
 
 See answers 1.4 to 1.7 in the following official FAQ of the license:
 http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=OFL-FAQ_web
 It is compatible.

I don't see a claim that the font is LGPL-compatible when embedded in a 
program. The FSF discussion of this license doesn't say, unfortunately.

 And as the font is only used by DumpRenderTree for tests, the WebKit API by 
 itself does not need it at all.
 So, Safari, Chrome/Chromium, etc need to include neither the font, nor the 
 license.

Good point. However, at least some versions of DumpRenderTree build with test 
fonts embedded directly into the binary. 

 
 
 For support material that has unusual license terms, another possibility is 
 to have WebKit's support scripts automatically download it, rather than 
 checking it directly into the repository.
 
 CSS font-face could be a workaround but a persistent location should be found 
 (and I suppose WebKit website has the same licensing issues?). And with that 
 solution MathML layout tests could not be run without a network connection.

I'm not suggesting WebFonts. Rather, the fonts could be downloaded on demand 
when running the tests if not present, the way we do with some Python modules.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding window.layoutTestInspector

2010-07-19 Thread Maciej Stachowiak


Darin and I discussed this proposal, and we had a few thoughts to share:

(1) It seems a little odd that we'll end up with two different objects that 
have similar names and a very similar purpose, but just differ in how they are 
implemented. Maybe there's a way to define layoutTestController in WebCore and 
have DumpRenderTree extend it.

(2) It does seem like for some test-specific methods, implementing then in 
WebCore would be simpler and would save the work of plumbing them through the 
WebKit layers.

(3) On the other hand, LayoutTestController seems like it has too much stuff in 
it. Originally DumpRenderTree exposed a very modest set of functionality, 
mostly to control output (dumpAsText) or to emulate things that you could do by 
hand when running the test in the browser (waitUntilDone, eventSender). 
Nowadays, there are dozens of methods. A lot of them are used in only one or 
two tests. And in many cases, the methods have no interactive equivalent, so a 
lot of our tests are not runnable in the browser at all. Those seem like bad 
trends. Maybe instead of making it easier to add to LayoutTestController, we 
should look at whether we can consolidate functionality, factor it into more 
objects, and find ways to test things that don't require quite so much custom 
functionality.

I'll add on my own behalf that layoutTestInspector doesn't seem like a great 
name and doesn't express the relationship to layoutTestController. It's not 
used to examine layout tests.

Regards,
Maciej

On Jul 14, 2010, at 10:16 PM, Hajime Morita wrote:

 Hi WebKit folks,
 
 I'm planning to add window.layoutTestInspector or something like that to 
 DRT.
 And I'd like to hear your opinions.
 
 Background:
 
 Adding new method to LayoutTestController is hard. It
 - requires to add new WebKit API to each ports, when the method is to
 access WebCore.
 - requires to export extra WebCore symbols to access it from WebKit
 API implementation.
 - cannot use WebIDL so we need to write binding code manually.
 
 In some case, these steps are unavoidable.
 But in some other case, especially when we just want to access WebCore
 from the test, we might be able to skip these steps.
 
 A concrete example (my first motivation) is to test DocumentMarker
 for http://webkit.org/b/41423.
 DocumentMarker is WebCore's internal state and cannot access neither
 from DOM nor LayoutTestController.
 
 To test it,
 - the first idea is to use a pixel test.
  But it has some shortcomings as you know well.
 - The second idea is to extend render tree's dump format to
  include markers. But it is also platform-specific,
  and hard to interpret for humans.
 - The third idea is to add an API to LayoutTestController.
  But it is hard as I mentioned above.
 
 Is there another way? DocumentMarker is
 - WebCore's internal state,
 - so we don't need to inspect it except for testing purpose,
 - so it's better to avoid an extra WebKit API for that.
 
 I think there are similar demands other than for DocumentMarker,
 and it might be worth to invest a common way to handle them.
 
 Plans:
 
 To deal with such cases, we can add a test-specific object named
 LayoutTestInspector to window object. (The name is tentative.)
 With this object, We'll be able to write a LayoutTest like:
 
 if (window.layoutTestInspector) {
   var target = document.getElementById(target)
   var markerStr = layoutTestInspector.nodeMarkerString(target);
   if (markerStr == Spelling:0:6)
  log(PASS);
   else
  log(FAIL);
 }
 
 Here is a plan to do this:
 
 - LayoutTestInspector will be defined in WebCore,
  and implemented as a usual DOM object using WebIDL.
  (placed under, for example, WebCore/page/LayoutTestInspector.{idl,h,cpp})
 - window object will expose a non-enumerable
 windows.layoutTestInspector property
  for that.
 - Settings::m_enableLayoutTestInspector will control 
 windows.layoutTestInspector
  availability. This flag should be true only on DRT.
 
 Tests with LayoutTestInspector would have several advantages:
 
 - Compared to LayoutTestController,
  we don't need to add new APIs to WebKit layer for test purpose.
 - Compared to LayoutTestController,
  we don't need to export extra WebCore APIs to WebKit layer.
 - Compared to Render-tree dump,
  the test can be more portable, focused and understandable.
 
 But there are some concerns:
 
 - WebCore need to have a test-specific code, that might be a waste of space.
  Test-specific WebKit APIs would have a same problem, though.
 - LayoutTestInspector may introduce some potential security risks.
  I have no idea about this area.
 
 Do you have any other use-cases or better approaches?
 Are there concerns I've missed? Do we have similar discussions in the past?
 Any ideas/suggestions are welcome.
 If there are no strong objections, I'll start to work on this.
 
 Regards.
 
 --
 morita
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org

Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

The reason for these is historical. Originally, we didn't use a separate vendor
prefix for WebKit, just -khtml. Later we changed to -apple. Eventually we
realized WebKit would not be an Apple-specific project forever, so we switched
to -webkit. The main risk to removing the old prefixes is that some older
WebKit-specific content authored against them will break. I'm not sure the code
cleanup benefits outweigh the risk of breaking content.

If we want to phase out support for these older prefixes, what I'd propose as a
first step is supporting the legacy prefixes for old properties but not for any
new ones.

Regards,
Maciej

On Jul 12, 2010, at 1:53 AM, Peter Beverloo wrote:

Good day,

While going through WebCore for some CSS research I'm currently doing,
I came across a piece of code[1] which translates all -khtml- and
-apple- vendor-prefixes to -webkit-. This effectively means
-apple-transform and -khtml-transform can both be used instead of
-webkit-transform. I am unaware of the rationales behind the apple
vendor-prefix, but I'd like to propose removing support for the
KHTML-prefix.

My main argument for this is that WebKit and KHTML are, in my opinion,
two separate engines by two separate vendors. The port occurred eight
years ago, and code in both projects has changed significantly ever
since. When Microsoft announced support for -webkit-text-size-adjust
in IE Mobile it was argued that browsers should not implement
properties with prefixes belonging to other vendors, which seems to
be exactly what WebKit is doing with the KHTML prefix.

I understand the history of supporting -khtml-, and have heard from
the KHTML project that they implement the -webkit- prefix as well.
However, considering that WebKit has grown significantly in the past
few years and that all code changes basically made KHTML and WebKit
two individual rendering engines, with individual CSS support, I
believe it would be appropriate for support to be dropped.

Regards,
Peter Beverloo
http://peter.sh/

[1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
[2]
http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes


On Jul 12, 2010, at 10:44 AM, Peter Beverloo wrote:

 Right now WebKit has by far the most prefixed elements[1], a
 significant part of which have not been standardized/drafted yet.
 Keeping the translation for all properties active practically triples
 the amount of supported vendor-specific CSS extensions, which cannot
 be desirable.
 
 I'm not opposed to the idea of limiting the supported properties for
 these prefixes to a certain subset, but my preference would be to only
 support behavioral properties as -webkit-binding,
 -webkit-font-smoothing, -webkit-highlight and
 -webkit-user-(drag|modify|select). In the same piece of code,
 prefixed versions of border-radixes and opacity are still supported as
 well. Although I think the latter of which could be removed as well,
 considering Safari 1.1 got released in 2003.

WebKit really uses vendor-prefixed properties for a few different purposes:

1) Properties that are only intended to be used internal to the engine, to 
implement particular effects.
2) Properties that are future CSS standards but not yet mature enough to remove 
the prefix.
3) Experimental properties that may be proposed as standards in the future.
4) Proprietary properties that we don't intend to standardize, but which can be 
used by content.
5) Properties that were once prefixed for one of the above reasons, and we keep 
the prefixed version in addition to the unprefixed one.

One beneficial exercise would be to classify prefixed properties into the above 
buckets. For categories (3) and (4), we should consider whether the properties 
in question can actually be proposed as standards, and therefore move to 
category (2). For category (5), we should assess the compatibility impact of 
removing the prefixed version.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?


On Jul 12, 2010, at 11:01 AM, Beth Dakin wrote:

 
 On Jul 10, 2010, at 1:17 AM, Alex Milowski wrote:
 
 I would think we'd close it when we've actually completely implemented
 MathML.  
 
 If this is what you want the bug to represent, then it does make sense to 
 keep all feature-implementation bugs related to this master bug, but none of 
 the bug bugs…if that makes any sense.The bug bugs should be in the MathML 
 component, but they shouldn't block the feature-complete bug.
 
 Just
 enabling it seems like something we could do now but our implementation is
 quite impoverished with respect to MathML 3.0.
 
 I think we should consider enabling MathML. Just because we don't have MathML 
 3.0 implemented yet doesn't mean we need to keep it off; there was a time 
 when we didn't have any CSS 3 implemented, but that didn't mean our CSS 
 implementation had to be turned off! I have been playing around with a 
 MathML-enabled build, and I feel like we do a pretty good job getting a lot 
 of MathML on the web right, and I haven't experienced any crashes in the 
 MathML code either. And if we turn it on, more people will test it, and that 
 is just plain helpful. Just my opinion!

I think it's fine to enable MathML soon, as long as we make sure of the 
following:

1) Using a MathML-enabled build shouldn't cause stability problems or 
functional or performance regressions when browsing ordinary non-MathML content.
2) We should try to do some fuzz testing to verify that MathML doesn't create 
security risks.

#2 can happen after we enable MathML, but should probably happen before anyone 
ships it.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?


On Jul 12, 2010, at 4:06 PM, Alex Milowski wrote:

 On Mon, Jul 12, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
 I think it's fine to enable MathML soon, as long as we make sure of the 
 following:
 
 1) Using a MathML-enabled build shouldn't cause stability problems or 
 functional or performance regressions when browsing ordinary non-MathML 
 content.
 
 Some of tis is testable by passing all our test cases, right?  Or did you have
 something else in mind?

That plus browsing around some, or using the Safari stress test feature, wuld 
be enough to show basic stability.

 
 Do we have anything that measures performance for regressions?

The Safari team has some internal tests we could run, once you have a patch 
ready.

 
 I suspect that the performance on MathML with complicated row structures
 isn't going to be good at the moment.  There are two many multiple
 rendering passes for operator and content stretching and that can probably
 be optimized.  On the other hand, it seems to do quite well on reasonable
 MathML.

At this point, what I'm concerned about is that turning MathML on doesn't 
regress performance of other things (such as page load speed of normal HTML 
pages, or memory use when not using MathML). I would not expect it to, but 
there's always the possibility of unexpected interactions.

Optimizing MathML rendering itself is something that can be done after it gets 
turned on/

 
 2) We should try to do some fuzz testing to verify that MathML doesn't 
 create security risks.
 
 #2 can happen after we enable MathML, but should probably happen before 
 anyone ships it.
 
 What is involved in (2) ?
 
 I'm happy to try to beat on the code to make sure it works well
 enough for people to feel comfortable turning it on.

I'm not an expert on making fuzzers, so maybe some of the security people here 
can chime in or perhaps even help out.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 MathML3 entities

2010-07-10 Thread Maciej Stachowiak


On Jul 10, 2010, at 3:47 AM, Sausset François wrote:

 I'm currently working on the MathML3 implementation and I noticed that new 
 XML entities have been defined by the W3C:
 http://www.w3.org/TR/xml-entity-names/
 
 They are supposed to be used by both HTML 5  MathML 3.
 
 I would like to include them in WebCore/html/HTMLEntityNames.gperf.
 However there is one conflict with the existing XHTML 1.0 entities: \rangle 
 (and \langle) doesn't point to the same Unicode character in XHTML 1.0 and 
 HTML 5 entity definitions.
 For instance, U+27E9 (⟩) instead of U+3009 (〉).
 
 There are two possibilities:
 - either update WebCore/html/HTMLEntityNames.gperf and overwrite the two 
 conflicting cases with the new standard, but it won't respect the XHTML 1.0 
 specification anymore.
 - or use two sets of HTML entities depending on the DTD of the document. It 
 would be the cleanest way, but I don't know how to make WebCore handle two 
 such sets.
 
 I think the best solution is the second one, but I'll need help to make 
 WebCore handle two entity sets and switch depending on the DTD. It is outside 
 of my present skills.

Go with the HTML5 / MathML 3 definitions for everything. Our XHTML 
implementation targets XHTML5, not XHTML 1.0.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 MathML3 entities

2010-07-10 Thread Maciej Stachowiak


On Jul 10, 2010, at 9:36 AM, Alexey Proskuryakov wrote:

 
 10.07.2010, в 04:49, Maciej Stachowiak написал(а):
 
 Go with the HTML5 / MathML 3 definitions for everything. Our XHTML 
 implementation targets XHTML5, not XHTML 1.0.
 
 
 I think that xml-entity-names and HTML5 made a poor choice changing the 
 semantics of rang; and lang; (they used to be CJK punctuation, and now they 
 are suddenly math). These are rendered differently. We should probably take a 
 pragmatic approach, and avoid rushing to be the first to implement this 
 aspect of the specs.

I agree we shouldn't rush on potential compatibility-breaking changes, if we 
can get someone else to do some testing for us first. However I believe Firefox 
dev builds have the new meanings of rang; and lang;. They haven't discovered 
a problem yet, as far as I know.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 MathML3 entities

2010-07-10 Thread Maciej Stachowiak


On Jul 10, 2010, at 11:10 AM, Sausset François wrote:

 I just saw that when looking at the code by myself.
 What do you exactly mean by a prefix tree?

The data structure commonly called a Trie is a prefix tree:
http://en.wikipedia.org/wiki/Trie

This data structure not only lets you tell if a particular key is present, but 
it also lets you check if a string you have could possibly be the prefix of any 
valid key.

I think it is challenging, though, to make a trie structure that can be a 
compile-time constant, and building one dynamically will cost runtime memory 
per-process (whereas constant data would be in the data segment and shared).

Another possibility is to make an array of all the entity names in sorted 
order. Then lookup can use a binary search, and on a failed lookup, looking to 
either side of the last key checked should determine whether it is a valid 
prefix.

I expect binary search would be slower than Trie lookup, though I don't know by 
how much.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior


Thank you for fixing the problem.

Did you try talking to Alexey directly about this? Or to someone else who may 
be familiar with the situation? It's usually better to try steps like that 
before calling someone out on the mailing list. And if you do need to bring 
something to wider attention, perhaps you could consider a less strident tone. 
In the WebKit project, we prefer to resolve disputes calmly and respectfully, 
especially among longtime valued contributors such as Alexey and yourself. I 
realize that at times, contributors can feel frustrated, but let's try to keep 
the project mailing list a happy place.

Sincerely,
Maciej

On Jul 7, 2010, at 12:47 AM, Adam Barth wrote:

 If you're tired of my complaining about the tree being red, you can
 skip this message.
 
 Today Alexey checked in http://trac.webkit.org/changeset/62576,
 which broke two tests on every port.  12 hours later, these failures
 remained in the tree until I cleaned them up.  This mess could have
 been avoided in a number of ways:
 
 1) He could have run-webkit-tests before committing his change.
 2) If he didn't have time to run the tests locally, he could have used
 the commit-queue to run-webkit-tests before it landed his patch.
 3) He could have looked at the tree when sheriff-bot informed him that
 he might have broken Leopard Intel Debug by pinging him in #webkit and
 commenting on his bug:
 https://bugs.webkit.org/show_bug.cgi?id=41156#c8.
 
 Is this acceptable behavior?
 
 http://webkit.org/coding/contributing.html clearly says to run the
 layout tests using the run-webkit-tests script and make sure they all
 pass.  That page also says:
 
 [[
 In either case, your responsibility for the patch does not end with
 the patch landing in the tree. There may be regressions from your
 change or additional feedback from reviewers after the patch has
 landed. You can watch the tree at build.webkit.org to make sure your
 patch builds and passes tests on all platforms. It is your
 responsibility to be available should regressions arise and to respond
 to additional feedback that happens after a check-in.
 ]]
 
 Are there consequences for breaking these rules?
 
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior


On Jul 7, 2010, at 9:45 AM, Alexey Proskuryakov wrote:

 
 I think we can improve this by having sheriff-bot say which tests
 broke.  I bet if you saw these tests listed, you'd have realized what
 was going one.
 
 
 That would be very useful indeed! It currently takes some effort to find out 
 what exactly the bot complains about.

Another possibility is for it to link to the test results page when it reports 
a failure - not as obvious as reporting the failing tests inline, but this 
would make it very convenient to look into the details of the failure.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit2 process model


On Jul 7, 2010, at 4:41 AM, ARaj wrote:

 Hi,
 The latest WebKit2 Windows port creates a single process for any
 number of tabs that are opened.
 Will this be changed to something like a one-process-per-tab mode?

Our short-term plans are to make the threaded and single-web-process modes of 
WebKit2 work really well - there's still significant work to make the port 
feature-complete. Once that is done, we plan to work on multiple-web-process 
mode. That mode will have some unique additional challenges.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior


On Jul 7, 2010, at 7:22 PM, James Robinson wrote:

 
 
 On Wed, Jul 7, 2010 at 7:19 PM, Oliver Hunt oli...@apple.com wrote:
 
 On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:
 
 
 
 On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao zhen...@gmail.com wrote:
 Maybe I should complain this in a different threads, but recently the commit 
 bot waiting time is way too long.  Several times a patch of mine got the r+ 
 and cq+ and it landed two days later.  This is really frustrating.
 
 I am very tempted to use svn directly to commit patches, but that means the 
 patch only gets tested in my local environments. Like one time my patch 
 breaks the leopard bot, turns out the failed test is skipped on leopard, 
 which is exactly my OS.  If I land it through the commit bots, I could 
 identify the issue earlier.
 
 I agree they are closely related. A greener tree means a faster commit queue 
 and a faster commit queue means less people subvert it and break the tree. 
 The hard problem is figuring out how to fix the incentives so subverting the 
 queue isn't so desirable.
 
 What do you mean by subvert the queue?  The commit queue is a tool to 
 streamline commits from contributors who do not have commit access to the 
 repository.  If you have the ability to commit you should not be using the 
 commit queue to land your patches.
 
  
 That's not my understanding of the commit queue.  I use the commit queue to 
 land my patches when possible so that the patch receives further testing 
 before it hits the tree and potentially affects a large number of 
 contributors.  Why do you think this is a bad idea?  Is this preference 
 codified somewhere (formally or informally)?

Previously the commit queue had a problem whereby it would show incorrect 
committer information (every patch committed by Eric). Now that is fixed - 
every patch submitted by a committer will show the proper committer, and those 
submitted by a non-committer will show up as committed by commit-queue. I think 
it's a choice of which approach to use.

In addition to the obvious benefit of testing your patch for you, I think one 
positive externality of the commit queue is that people who use it are more 
motivated to keep the tree green. One negative externality is that it sometimes 
makes people excessively upset about tree redness, and sometimes makes them 
want to fix redness in a way that papers over problems (e.g. by adding to the 
skipped list).

On the whole, I suspect the benefits of automated testing before landing 
probably outweigh these concerns.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior