[webkit-dev] Mac build issue (appearing only locally)

2012-10-24 Thread Balazs Kelemen

  Hi!

I did build the Apple Mac port two times in the past few days to try 
something and both times I faced with a strange build issue that does 
not appear on the bots. I had to apply this patch, which just move some 
functions before their use in WKView.mm to be able to finish my build: 
https://gist.github.com/3913811 https://gist.github.com/3913811 I am 
using Lion with clang 3.0 (tags/Apple/clang-211.10.1) and I passed 
--makeargs=-j12 to build-webkit. Do you have an idea what can be the 
problem?


Thanks!
kbalazs

P.S.: here is the build error:

Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1875:5:{1875:5-1875:80}: 
error: instance method '-_wk_windowDidBecomeKey:' not found (return type 
defaults to 'id') [-Werror,3]
 ADD_OBSERVER(_wk_windowDidBecomeKey, 
NSWindowDidBecomeKeyNotification, nil);

^~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57: 
note: instantiated from:
 usingBlock:^(NSNotification *notification){ [self 
selectorName:notification]; }] \

^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1876:5:{1876:5-1876:109}: 
error: instance method '-_wk_windowDidChangeBackingProperties:' not 
found (return type defaults to 'id') [-Werror,3]
 ADD_OBSERVER(_wk_windowDidChangeBackingProperties, 
windowDidChangeBackingPropertiesNotification, window);

^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57: 
note: instantiated from:
 usingBlock:^(NSNotification *notification){ [self 
selectorName:notification]; }] \

^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1877:5:{1877:5-1877:89}: 
error: instance method '-_wk_windowDidChangeScreen:' not found (return 
type defaults to 'id') [-Werror,3]
 ADD_OBSERVER(_wk_windowDidChangeScreen, 
NSWindowDidChangeScreenNotification, window);

^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57: 
note: instantiated from:
 usingBlock:^(NSNotification *notification){ [self 
selectorName:notification]; }] \

^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1878:5:{1878:5-1878:91}: 
error: instance method '-_wk_windowDidDeminiaturize:' not found (return 
type defaults to 'id') [-Werror,3]
 ADD_OBSERVER(_wk_windowDidDeminiaturize, 
NSWindowDidDeminiaturizeNotification, window);

^~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57: 
note: instantiated from:
 usingBlock:^(NSNotification *notification){ [self 
selectorName:notification]; }] \

^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1879:5:{1879:5-1879:87}: 
error: instance method '-_wk_windowDidMiniaturize:' not found (return 
type defaults to 'id') [-Werror,3]
 ADD_OBSERVER(_wk_windowDidMiniaturize, 
NSWindowDidMiniaturizeNotification, window);

^~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57: 
note: instantiated from:
 usingBlock:^(NSNotification *notification){ [self 
selectorName:notification]; }] \

^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1880:5:{1880:5-1880:73}: 
error: instance method '-_wk_windowDidMove:' not found (return type 
defaults to 'id') [-Werror,3]

 ADD_OBSERVER(_wk_windowDidMove, NSWindowDidMoveNotification, window);
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57: 
note: instantiated from:
 usingBlock:^(NSNotification *notification){ [self 
selectorName:notification]; }] \

^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1881:5:{1881:5-1881:91}: 
error: instance method '-_wk_windowDidOrderOffScreen:' not found (return 
type defaults to 'id') [-Werror,3]
 ADD_OBSERVER(_wk_windowDidOrderOffScreen, 
windowDidOrderOffScreenNotification, window);

^~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57: 
note: instantiated from:
 usingBlock:^(NSNotification *notification){ [self 
selectorName:notification]; }] \

^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1882:5:{1882:5-1882:89}: 
error: instance method '-_wk_windowDidOrderOnScreen:' not found (return 

Re: [webkit-dev] A new test in a patch passes locally fails on ews

2012-10-24 Thread Pravin D
Wanted to know if the we are going to go with the plan to attach a mailing
service to the bot for the failing test cases anything soon ?
As only Mac and cr-linux EWS bots run test cases its a becoming little
difficult to figure out whats the failure and whether its platform specific
or not (i'm using Qt-linux and Windows).


On Fri, Oct 5, 2012 at 11:20 PM, Eric Seidel e...@webkit.org wrote:

 I think that's an interesting idea.  The bots don't have a mail
 server. :)  But we could presumably wire up some sort of service for
 them.

 On Thu, Oct 4, 2012 at 6:41 PM, Emil A Eklund e...@chromium.org wrote:
  What if we mail the zip files to the person that uploaded the patch?
  That way the responsibility of managing the storage is shifted to the
  author and the author still benefits from the results from all
  platforms.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] A new test in a patch passes locally fails on ews

2012-10-24 Thread Adam Barth
I don't have any current plans to implement that service.  If someone
else would like to administer the machines and add these features, I'm
happy to review patches.

Adam


On Wed, Oct 24, 2012 at 6:38 AM, Pravin D pravind@gmail.com wrote:
 Wanted to know if the we are going to go with the plan to attach a mailing
 service to the bot for the failing test cases anything soon ?
 As only Mac and cr-linux EWS bots run test cases its a becoming little
 difficult to figure out whats the failure and whether its platform specific
 or not (i'm using Qt-linux and Windows).


 On Fri, Oct 5, 2012 at 11:20 PM, Eric Seidel e...@webkit.org wrote:

 I think that's an interesting idea.  The bots don't have a mail
 server. :)  But we could presumably wire up some sort of service for
 them.

 On Thu, Oct 4, 2012 at 6:41 PM, Emil A Eklund e...@chromium.org wrote:
  What if we mail the zip files to the person that uploaded the patch?
  That way the responsibility of managing the storage is shifted to the
  author and the author still benefits from the results from all
  platforms.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



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

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


[webkit-dev] FYI: change to fake mouse events and hover updating during scroll

2012-10-24 Thread Ojan Vafai
When you do a scroll, we fire fake mouse events and update hover state. We
currently try to throttle those events, but do very little throttling in
practice.

The patch below makes it so that we only fire a single set of fake mouse
events and only update the hover state once during a scroll. This behavior
matches Firefox and generally feels like a better user-experience to me.

In addition, this patch makes it so that we dynamically modify the
throttling rate (instead of hard-coded values) to workaround slow mouse
event handlers that make scrolling slow. In my local tests, this was a
clear win and the new code is only marginally more complicated than the old
code.

https://bugs.webkit.org/show_bug.cgi?id=99940
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] A new test in a patch passes locally fails on ews

2012-10-24 Thread Dirk Pranke
I think there is some general interest in a feature like this.

I need to sync up w/ Adam and Eric and figure out what all might be
required here, so we might do this but I can't say for sure yet ...

-- Dirk

On Wed, Oct 24, 2012 at 8:40 AM, Adam Barth aba...@webkit.org wrote:
 I don't have any current plans to implement that service.  If someone
 else would like to administer the machines and add these features, I'm
 happy to review patches.

 Adam


 On Wed, Oct 24, 2012 at 6:38 AM, Pravin D pravind@gmail.com wrote:
 Wanted to know if the we are going to go with the plan to attach a mailing
 service to the bot for the failing test cases anything soon ?
 As only Mac and cr-linux EWS bots run test cases its a becoming little
 difficult to figure out whats the failure and whether its platform specific
 or not (i'm using Qt-linux and Windows).


 On Fri, Oct 5, 2012 at 11:20 PM, Eric Seidel e...@webkit.org wrote:

 I think that's an interesting idea.  The bots don't have a mail
 server. :)  But we could presumably wire up some sort of service for
 them.

 On Thu, Oct 4, 2012 at 6:41 PM, Emil A Eklund e...@chromium.org wrote:
  What if we mail the zip files to the person that uploaded the patch?
  That way the responsibility of managing the storage is shifted to the
  author and the author still benefits from the results from all
  platforms.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



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

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


Re: [webkit-dev] A new test in a patch passes locally fails on ews

2012-10-24 Thread Dirk Pranke
I think I did a bunch of pruning at some point and the zip files on
the EWS bots are way smaller than they used to be; there's probably
even more we could do, but certainly for some class of patches there
will be too many failures and we'd be looking at many megabytes of zip
files that we don't necessarily want to stick bugzilla with.

-- Dirk

On Wed, Oct 24, 2012 at 12:51 PM, Eric Seidel e...@webkit.org wrote:
 Now with feeling.

 On Wed, Oct 24, 2012 at 12:51 PM, Eric Seidel esei...@google.com wrote:
 We used to upload zips to bugs.  But there is a built-in cutoff on
 that feature.  I suspect that the zip size from the bots has just
 ballooned above that cut-off and fixing LayoutTestResults to only
 include the relevant files would probably make the EWSes start
 uploading results.zip files again. :)

 On Wed, Oct 24, 2012 at 12:33 PM, Dirk Pranke dpra...@chromium.org wrote:
 I think there is some general interest in a feature like this.

 I need to sync up w/ Adam and Eric and figure out what all might be
 required here, so we might do this but I can't say for sure yet ...

 -- Dirk

 On Wed, Oct 24, 2012 at 8:40 AM, Adam Barth aba...@webkit.org wrote:
 I don't have any current plans to implement that service.  If someone
 else would like to administer the machines and add these features, I'm
 happy to review patches.

 Adam


 On Wed, Oct 24, 2012 at 6:38 AM, Pravin D pravind@gmail.com wrote:
 Wanted to know if the we are going to go with the plan to attach a mailing
 service to the bot for the failing test cases anything soon ?
 As only Mac and cr-linux EWS bots run test cases its a becoming little
 difficult to figure out whats the failure and whether its platform 
 specific
 or not (i'm using Qt-linux and Windows).


 On Fri, Oct 5, 2012 at 11:20 PM, Eric Seidel e...@webkit.org wrote:

 I think that's an interesting idea.  The bots don't have a mail
 server. :)  But we could presumably wire up some sort of service for
 them.

 On Thu, Oct 4, 2012 at 6:41 PM, Emil A Eklund e...@chromium.org wrote:
  What if we mail the zip files to the person that uploaded the patch?
  That way the responsibility of managing the storage is shifted to the
  author and the author still benefits from the results from all
  platforms.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



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

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


Re: [webkit-dev] Mac build issue (appearing only locally)

2012-10-24 Thread Darin Adler
Seems like this must be a difference between clang versions; I suggest updating 
to a newer version of Xcode.

If we need to support the older clang, then the fix of reordering the methods 
seems OK. There are other fixes we could consider too.

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


[webkit-dev] Adding high resolution platform timestamp to DOM events

2012-10-24 Thread Robert Flack
Hi webkit-dev,

I would like to add platform timestamps to DOM events as the systemTime
property. I have a patch implementing the feature:
https://bugs.webkit.org/show_bug.cgi?id=94987. This will let us know the
time at which the system received an event to be able to accurately handle
it, whereas the timestamp property gives the time the DOM event was created
in an inaccurate milliseconds since 1970 form. This has been discussed on
www-dom (http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0028.html)
and www-perf (
http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0046.html) and
use cases for this have been discussed (
http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0092.html).

The platform timestamp comes in as a monotonic timestamp. Since the DOM
Event spec requires that timeStamp() be a 1970-epoch based timestamp it is
not sufficient for a high resolution precise time delta on event delivery.
Instead, we add a systemTime property which uses the Performance API spec (
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html)
for high res timestamps (time since document load timestamp to avoid user
fingerprinting) and provide the platform's high resolution timestamp to
ECMAScript.

Let me know if you have any suggestions. I look forward to everyone's
feedback, cheers!
- Rob
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Adding high resolution platform timestamp to DOM events

2012-10-24 Thread Elliott Sprehn
This doesn't appear to be in any standard yet. You should probably send
something to public-webapps or the whatwg list and make sure others are
onboard for the idea before exposing it to the web.

On Wed, Oct 24, 2012 at 6:17 PM, Robert Flack fla...@chromium.org wrote:

 Hi webkit-dev,

 I would like to add platform timestamps to DOM events as the systemTime
 property. I have a patch implementing the feature:
 https://bugs.webkit.org/show_bug.cgi?id=94987. This will let us know the
 time at which the system received an event to be able to accurately handle
 it, whereas the timestamp property gives the time the DOM event was created
 in an inaccurate milliseconds since 1970 form. This has been discussed on
 www-dom (http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0028.html)
 and www-perf (
 http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0046.html)
 and use cases for this have been discussed (
 http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0092.html).

 The platform timestamp comes in as a monotonic timestamp. Since the DOM
 Event spec requires that timeStamp() be a 1970-epoch based timestamp it is
 not sufficient for a high resolution precise time delta on event delivery.
 Instead, we add a systemTime property which uses the Performance API spec (
 http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html)
 for high res timestamps (time since document load timestamp to avoid user
 fingerprinting) and provide the platform's high resolution timestamp to
 ECMAScript.

 Let me know if you have any suggestions. I look forward to everyone's
 feedback, cheers!
 - Rob

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


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