[webkit-dev] Bots temporarily red

2010-06-18 Thread Nikolas Zimmermann

Hey WebKit crowd,

I've just landed a large SVG changeset, that requires a rebaseline of  
virtually all SVG tests on all platforms.
I'm waiting for the bots and will rebaseline them, soon. Please be  
patient, I will fix all breakage.


Cheers,
Niko

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


Re: [webkit-dev] Bots temporarily red

2010-06-18 Thread Nikolas Zimmermann


Am 18.06.2010 um 13:31 schrieb Nikolas Zimmermann:


Hey WebKit crowd,

I've just landed a large SVG changeset, that requires a rebaseline  
of virtually all SVG tests on all platforms.
I'm waiting for the bots and will rebaseline them, soon. Please be  
patient, I will fix all breakage.


Thanks for the patience, bots are all green again!
Side note: the win bots have some unrelated problems, that someone  
might look into.


Cheers,
Niko

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


Re: [webkit-dev] A proposal for Platform Mechanisms

2010-06-18 Thread Anders Carlsson

On Jun 17, 2010, at 2:04 PM, Jeremy Orlow wrote:

 Overall, looks great!!
 
 
 On Wed, Jun 16, 2010 at 6:05 PM, Anders Carlsson ander...@apple.com wrote:
  Also, PlatformMechanism is a Factory, and should be named accordingly. Or 
  maybe it's a Source of clients/mechanisms.
 
 
 Good point, it is a factory.
 
 Is it a factory?  If so, I'd expect it to return PassOwnPtrs rather than *'s. 
  With *'s I'd expect the class to retain ownership (and destroy them when 
 it's destroyed).
 

Currently I just called the class PlatformPolicies. It is kind of a factory but 
it will only create singletons that are never intended to be destroyed.

 
 On Wed, Jun 16, 2010 at 8:34 PM, Darin Fisher da...@chromium.org wrote:
 2- This looks a lot like WebKitClient in the Chromium WebKit API, except that 
 WebKitClient is defined at the API layer and not at the WebCore/platform 
 layer.  Related point:  WebCore::ChromiumBridge is just a bunch of static 
 functions because it seems wasteful to define intermediate virtual functions 
 at the WebCore level.  Note:  There is a plan to rename ChromiumBridge to 
 PlatformBridge because the Android port wishes to share some of the same 
 infrastructure.  There is already a typedef in place.
 
 I'm pretty sure the solution proposed in this thread would work fine for 
 Android as well.
 

Cool!

 
 On Thu, Jun 17, 2010 at 10:31 AM, Darin Fisher da...@chromium.org wrote:
 Makes sense.  By the way, there are more modules other than WebCore/platform 
 that will require this kind of separation.  WebCore/storage has several 
 examples of this.  Jorlow already modified the LocalStorage implementation to 
 support this kind of separation.  It'd be nice if whatever model is adopted 
 for WebCore/platform can also be applied to these other modules.  (Doesn't 
 sound like it will be an issue.)
 
 Note that you only need this if you have multiple renderer/web processes.  If 
 you only have one and aren't doing sandboxing, you don't need anything 
 special.  If you're doing sandboxing you could either use LocalStorage the 
 way chromium does or you could proxy the raw FS/SQL VFS.  (The former would 
 probably be easier and cleaner.)
 
 Note that the same should be true of IndexedDB.
 

In the future we definitely want to be able to use multiple render processes, 
so designing for that is a good idea.

 It's not so much about performance.  There's a cognitive cost to having so 
 many layers.  But, given (c) above, I understand that you really don't have a 
 choice.
 
 FWIW: I can confirm that the cognitive cost of even the existing number of 
 layers in Chromium is high and surprisingly taxing.  It's definitely 
 something to keep in mind and work to avoid when possible when designing 
 stuff for WebKit2.
 

That's a good point and something that we should definitely try to avoid.


 On Thu, Jun 17, 2010 at 12:50 PM, Maciej Stachowiak m...@apple.com wrote:
 ClipboardStrategy -- abstract class
 ClipboardProxyStrategy (or ProxyClipboardStrategy) -- class that provides 
 the details of clipboard functionality by proxying to a privileged process
 ClipboardDirectStrategy -- class that implements clipboard functionality 
 directly.
 
 For what it's worth, DOM Storage and IndexedDB uses the following naming 
 scheme:
 
 StorageArea - abstract class
 StorageAreaImpl - actual implementation
 StorageAreaProxy - proxy implementation
 
 I'm not entirely sure the Strategy suffix would make these more usable, but 
 otherwise it seems to match up with what I've been doing already.
 

I'm only using the Strategy name for the abstract base classes right now. 

 
 On Thu, Jun 17, 2010 at 12:53 PM, Geoffrey Garen gga...@apple.com wrote:
  Cracking my Design Patterns book (or at least my memory of it), another 
  idea that comes up is Strategy.
 
 On IRC, Anders mentioned Manager as an alternative to Strategy.
 
 I disagree.  Manager is such an overloaded/overused word in CS that it has 
 pretty much no meaning.  Strategy is at least unique.  (Though I'm not 
 completely convinced such a suffix is required...especially for the 
 non-platform code like LocalStorage and IndexedDB.) 
 

Good point.

- Anders

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


Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)

2010-06-18 Thread Andreas Delmelle

On 17 Jun 2010, at 20:37, Alexey Proskuryakov wrote:

 
 17.06.2010, в 9:53, Andreas Delmelle написал(а):
 
 If WebKit chooses, for example, to ignore character events from the parser 
 in nodes where logically it doesn't make sense to have stray characters
 
 
 That would break e.g. Web sites where JS accesses DOM in ways such as 
 node.firstChild.nextSibling, or node.childNodes[3]. We've previously seen 
 similar breakage happen after changing WebCore parsing code.

Wow, good point! Suddenly I feel foolish, not having thought of that 
hyper-trivial scenario. Obviously a very good reason to keep those nodes in. 

Still, one wonders from time to time how much bandwidth is actually wasted by 
sending over all these extraneous bytes that ultimately compel JS developers to 
write code like the above. I don't think I have ever seen a website that does 
/not/ serve its HTML pretty-printed... That seems like an awful lot of spaces, 
tabs and linefeeds!

On the other hand, node.firstChild.nextSibling just seems like asking for 
trouble. One could argue that people who do use that to get to the first 
element node do not need to be accommodated. It would suffice for one of the 
page's authors to insert a small comment node to break that code.

One could just as easily extend Node with a firstElement() method that would 
work under all circumstances --but, oh yes, IE didn't support that back then... 
;-)


Regards,

Andreas Delmelle
---

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


Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)

2010-06-18 Thread Eric Seidel
firstElementChild already exists in modern browsers:
http://www.w3.org/TR/ElementTraversal/#interface-elementTraversal

Anyway, this thread is done.

On Fri, Jun 18, 2010 at 10:27 AM, Andreas Delmelle
andreas.delme...@telenet.be wrote:

 On 17 Jun 2010, at 20:37, Alexey Proskuryakov wrote:


 17.06.2010, в 9:53, Andreas Delmelle написал(а):

 If WebKit chooses, for example, to ignore character events from the parser 
 in nodes where logically it doesn't make sense to have stray characters


 That would break e.g. Web sites where JS accesses DOM in ways such as 
 node.firstChild.nextSibling, or node.childNodes[3]. We've previously seen 
 similar breakage happen after changing WebCore parsing code.

 Wow, good point! Suddenly I feel foolish, not having thought of that 
 hyper-trivial scenario. Obviously a very good reason to keep those nodes in.

 Still, one wonders from time to time how much bandwidth is actually wasted by 
 sending over all these extraneous bytes that ultimately compel JS developers 
 to write code like the above. I don't think I have ever seen a website that 
 does /not/ serve its HTML pretty-printed... That seems like an awful lot of 
 spaces, tabs and linefeeds!

 On the other hand, node.firstChild.nextSibling just seems like asking for 
 trouble. One could argue that people who do use that to get to the first 
 element node do not need to be accommodated. It would suffice for one of the 
 page's authors to insert a small comment node to break that code.

 One could just as easily extend Node with a firstElement() method that would 
 work under all circumstances --but, oh yes, IE didn't support that back 
 then... ;-)


 Regards,

 Andreas Delmelle
 ---

 ___
 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] Bots temporarily red

2010-06-18 Thread Adam Roben

On Jun 18, 2010, at 10:54 AM, Nikolas Zimmermann wrote:

the win bots have some unrelated problems, that someone might look  
into.


I've been looking into these. I got the Windows bots down from 11  
failures to 3 failures on Wednesday.


-Adam

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


[webkit-dev] Faster bot cycle times on Windows (Re: Bots temporarily red)

2010-06-18 Thread Adam Barth
On Fri, Jun 18, 2010 at 1:22 PM, Adam Roben aro...@apple.com wrote:
 I've been looking into these. I got the Windows bots down from 11 failures
 to 3 failures on Wednesday.

The main difficulty I have with the windows bots is that they get
really behind.  Is there something stopping us from getting more
Windows hardware?  Our good friends who run EC2 might have a machine
or two available for rent...

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


[webkit-dev] @ layers Understanding

2010-06-18 Thread zabar khorogus
Hi,
In the youtube video by Eric on WebKit rendering some spec is pointed for
layers understanding. I tried searching the layer spec but could not
succeed. Can any body please point me to the same , I wanted to understand
the render layer concept and it's operations and effects on paint.

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


Re: [webkit-dev] @ layers Understanding

2010-06-18 Thread Simon Fraser
What kind of layers are you interested in, and why?

Simon

On Jun 18, 2010, at 1:31 PM, zabar khorogus wrote:

 Hi,
 In the youtube video by Eric on WebKit rendering some spec is pointed for 
 layers understanding. I tried searching the layer spec but could not succeed. 
 Can any body please point me to the same , I wanted to understand the render 
 layer concept and it's operations and effects on paint.

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


Re: [webkit-dev] Faster bot cycle times on Windows (Re: Bots temporarily red)

2010-06-18 Thread Darin Adler
On Jun 18, 2010, at 1:28 PM, Adam Barth wrote:

 On Fri, Jun 18, 2010 at 1:22 PM, Adam Roben aro...@apple.com wrote:
 I've been looking into these. I got the Windows bots down from 11 failures 
 to 3 failures on Wednesday.
 
 The main difficulty I have with the windows bots is that they get really 
 behind. Is there something stopping us from getting more Windows hardware?

My team at Apple just ordered two new machines to use as Windows bots. on 
Wednesday We’re going to set them up as soon as they arrive.

-- Darin

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


[webkit-dev] Initialization of Attribute Map

2010-06-18 Thread Fady Samuel
Hi all,

I'm looking at a bug listed on chromium.org (
http://code.google.com/p/chromium/issues/detail?id=46025) but it's actually
a WebKit bug...I've verified that the crash is in WebKit and Safari also
crashes on Mac. It seems that the javascript line:

ellipse.className.baseVal = cls1;

results in a call to StyledElement::classNames which then requests the
classNames from the attiribute map.

At the time, the attribute map does not exist. An assert fails because
it has not yet been created.

It seems a simple fix is to create it if it hasn't been created.

Looking at other code, it appears that the attribute map is created
lazily when needed.

Is this the solution or is there a fundamental assumption being
violated here that I should dig deeper into?

Thanks,

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


Re: [webkit-dev] Faster bot cycle times on Windows (Re: Bots temporarily red)

2010-06-18 Thread Adam Barth
On Fri, Jun 18, 2010 at 1:33 PM, Darin Adler da...@apple.com wrote:
 On Jun 18, 2010, at 1:28 PM, Adam Barth wrote:
 On Fri, Jun 18, 2010 at 1:22 PM, Adam Roben aro...@apple.com wrote:
 I've been looking into these. I got the Windows bots down from 11 failures 
 to 3 failures on Wednesday.

 The main difficulty I have with the windows bots is that they get really 
 behind. Is there something stopping us from getting more Windows hardware?

 My team at Apple just ordered two new machines to use as Windows bots. on 
 Wednesday We’re going to set them up as soon as they arrive.

Awesome.  Thanks.

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


Re: [webkit-dev] Initialization of Attribute Map

2010-06-18 Thread Darin Adler
This is the kind of discussion we usually have in bug reports. First step would 
be to put the bug report into bugs.webkit.org.

To answer your question, it’s not legal to call StyledElement::classNames 
without first checking hasClass. And if hasClass is true, then there will 
already be an attribute map. Calling mappedAttributes() or attributeMap() 
instead of calling attributes(false) is done for speed.

The bug is possibly in a call site that calls classNames without first checking 
hasClass. Or it could be something else. Please file the bug report and you can 
include things like the test case there and we can discuss the fix.

-- Darin

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


Re: [webkit-dev] @ layers Understanding

2010-06-18 Thread zabar khorogus
Hi,
I am a collage debugging webkit since couple of months on windows out of
curiosity.In the youtube video i got that there are 3-4 kind of trees in
Webkit. Out of which DOM-Rendering is wahat, I could make out something. But
Style and Layer tree concept I could not get.

...ZKho

On Sat, Jun 19, 2010 at 2:02 AM, Simon Fraser simon.fra...@apple.comwrote:

 What kind of layers are you interested in, and why?

 Simon

 On Jun 18, 2010, at 1:31 PM, zabar khorogus wrote:

  Hi,
  In the youtube video by Eric on WebKit rendering some spec is pointed for
 layers understanding. I tried searching the layer spec but could not
 succeed. Can any body please point me to the same , I wanted to understand
 the render layer concept and it's operations and effects on paint.


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