Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

[Andy Estes]

Hi Sam,

> On Oct 18, 2020, at 11:01, Sam Weinig  wrote:
> 
> One direct benefit of moving away from DerivedSources.make would likely be (I 
> say likely, as the details of how it works out are far from certain in my 
> mind) removing at least one place that a IDL file needs to be listed as we 
> would not need to explicitly the list the IDL file in DerivedSources.make, 
> and would only need to ensure it was in some *input.xcfilelist.

The way I imagine this working is that the existing .idl file references in the 
(e.g., WebCore) project would become members in a target with a custom build 
rule for “*.idl”. Target membership is itself another list inside the 
.xcodeproj file, just one you manage through checkboxes in Xcode (and can be 
done reasonably quickly as part of adding a new file reference).

Whether or not this actually creates one fewer “place a IDL file needs to be 
listed” (which I think is a worthwhile goal), I think you should still remove 
the Makefile build phases from Xcode for the reasons you originally cited.

Andy___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] -Wpessimizing-move and -Wredundant-move

[Andy Estes]

Hi Michael,

> On Mar 18, 2019, at 2:35 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> GCC 9 has new -Wpessimizing-move ("warning: moving a local object in a return 
> statement prevents copy elision") and -Wredundant-move ("warning: redundant 
> move in return statement") warnings. These are enabled by -Wextra (which we 
> use) and will be triggered by code like:
> 
> return WTFMove(foo);
> 
> when foo is a copyable type. This idiom is only appropriate if foo is a 
> noncopyable (move-only) type. We have many, many instances of such code. I'm 
> trying to fix them. Please don't add more! (It's easy enough to disable the 
> warnings, but they're there for a reason.)

It might not even be appropriate for move-only types because of NRVO.

FWIW, Apple’s ports use the equivalent clang warning for pessimizing and 
redundant moves, and we cleaned up a bunch of these mistakes in our ports a few 
years ago. Hopefully you aren’t finding any of these mistakes in shared code.

(WTFMove was written to accommodate these warnings, in fact.)

Really glad you’re turning these warnings on!

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

Re: [webkit-dev] WebKit Commit Queue blocked by build errors in ToT

[Andy Estes]

> On Dec 6, 2018, at 4:37 PM, Chris Fleizach  wrote:
> 
> 
> 
>> On Dec 6, 2018, at 4:37 PM, Ryan Haddad > > wrote:
>> 
>> Chris,
>> 
>> I'm assuming that this is in reference to the patch in 
>> https://bugs.webkit.org/show_bug.cgi?id=192373 
>> . My guess is that something 
>> about the changes to Source/WebKit/WebKit.xcodeproj/project.pbxproj is 
>> causing an issue with unified sources.
>> 
>> The commit-queue itself has been landing other patches without issue and the 
>> build isn't broken on trunk bots. CC'ing Tim in case he can help point out 
>> the issue.
>> 
> 
> Yea must be. Any ideas why this wouldn’t build? I moved this .h/.mm to 
> another folder (from Mac -> Cocoa) 

Looks like we need to forward-declare class WebKit::SafeBrowsingWarning in 
WebViewImpl.h. Can you try that in your patch and see if that fixes it?

Andy___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Andy Estes]

> On Aug 30, 2017, at 11:54 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 30.08.2017, 21:05, "Alex Christensen" :
>>>  On Aug 29, 2017, at 5:54 PM, Sam Weinig  wrote:
>>>  In a completely other direction, what does this mean for use of Xcode? Can 
>>> we still build from Xcode? Debug?
>> 
>> CMake can generate Xcode files, so you can still develop and debug in Xcode.
> 
> This annihilates speed up possibility, as xcodebuild will be used instead of 
> ninja

I don’t think so. I believe the generated Xcode project uses CMake when 
building.

Andy

> 
>> 
>>>  On Aug 29, 2017, at 5:37 PM, Carlos Alberto Lopez Perez 
>>>  wrote:
>>>  Does this means that Apple ports are going to switch to CMake?
>> 
>> We have not decided anything officially yet, and if we were to decide to do 
>> this then it would take quite a while to make the official switch.
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] "webkit-patch upload --no-review" submits to EWS by default

[Andy Estes]

> On Aug 22, 2017, at 8:10 PM, Keith Miller  wrote:
> 
> Does it make sense to have a --wip option that’s basically --no-review / 
> don’t run EWS? There are times I upload clearly broken patches for early 
> analysis that don’t need to be run on EWS.

`webkit-patch --no-review --no-ews` should do what you want.

Andy

> 
> Cheers,
> Keith
> 
>> On Aug 14, 2017, at 2:16 PM, Daniel Bates > > wrote:
>> 
>> Hi all,
>> 
>> Just a heads up. Following r220715 
>> , "webkit-patch upload 
>> --no-review" and "webkit-patch post-commits --no-review" now submits a 
>> patch(es) for EWS analysis by default. You no longer need to open the 
>> Bugzilla bug and click the Submit for EWS button to do this on your 
>> --no-review patch(es). Pass --no-ews if you want to opt into the old 
>> behavior of posting a patch(es) without review and without submitting them 
>> to EWS.
>> 
>> Dan
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Python

[Andy Estes]

> On Aug 7, 2017, at 8:41 AM, Andy Estes <aes...@apple.com> wrote:
> 
> 
> 
>> On Aug 7, 2017, at 6:47 AM, Michael Catanzaro <mcatanz...@igalia.com 
>> <mailto:mcatanz...@igalia.com>> wrote:
>> 
>> last I checked, macOS did not provide a python2 binary either. I am hoping 
>> that has changed in the past few years. Has it?
> 
> Nope.

macOS does have /usr/bin/python2.7, though.

> 
> Andy
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Python

[Andy Estes]

> On Aug 7, 2017, at 6:47 AM, Michael Catanzaro  wrote:
> 
> last I checked, macOS did not provide a python2 binary either. I am hoping 
> that has changed in the past few years. Has it?

Nope.

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

Re: [webkit-dev] Idiom for functions with all return values in a switch case

[Andy Estes]

> On May 10, 2017, at 3:17 PM, Michael Catanzaro  wrote:
> 
> On Tue, May 9, 2017 at 2:57 PM, Ryosuke Niwa  wrote:
>> One annoying thing is that I've seen clang complaining about that
>> return statement being an unreachable statement while gcc doesn't :(.
>> So we probably shouldn't have return statement, not to mention that 0
>> may not be a valid enum value.
> 
> In that case, I think I'll go with RELEASE_ASSERT_NOT_REACHED() for now... 
> since otherwise GCC is going to complain in release builds if there is no 
> return statement. (Won't clang complain about that too?)

Clang won’t complain if the switch is exhaustive and all cases return.

Andy

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

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

Re: [webkit-dev] Idiom for functions with all return values in a switch case

[Andy Estes]

> On May 9, 2017, at 11:35 AM, Michael Catanzaro  wrote:
> 
> Andy suggests returning one of the enumeration values directly, then we can 
> use ASSERT_NOT_REACHED() instead of RELEASE_ASSERT_NOT_REACHED(). That would 
> work too, though it forces me to think about which one to pick.

You had to think about that for static_cast(0) as well, though. 0 might 
not be one of the enumerated values, for instance.

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

Re: [webkit-dev] Idiom for functions with all return values in a switch case

[Andy Estes]

> On May 9, 2017, at 11:06 AM, Michael Catanzaro  wrote:
> 
> https://bugs.webkit.org/show_bug.cgi?id=171851 
>  suggests this approach:
> 
>   static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent event)
>   {
>   switch (event) {
>   // ...
>   }
> 
>   ASSERT_NOT_REACHED();
>   return 0;
>   }
> 
> That works for the cases in that bug, but it won't work in this case, because 
> the return value here is an enum, so a cast would be needed.

You wouldn’t need a cast if you returned one of the enumeration values (say, 
the first one) instead of 0.

I prefer this option for the reason Maciej gave.

Andy___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Andy Estes]

I was just going to suggest something similar! 

Andy

> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  wrote:
> 
> I guess we could put it in Websites/webkit.org/b3 .  
> Then patches could edit both B3 and the documentation in one go, and the 
> documentation would go live when it’s committed.
> 
> Does anyone object to this?
> 
> -Filip
> 
> 
>> On Jan 28, 2016, at 4:39 PM, Saam barati > > wrote:
>> 
>> Yeah. That’d be the easiest way to keep it up IMO.
>> 
>> Saam
>> 
>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło >> > wrote:
>>> 
>>> +1
>>> 
>>> Do you think we should move the documentation to a file in svn so that it 
>>> can be reviewed as part of patch review?
>>> 
>>> -Filip
>>> 
>>> On Jan 28, 2016, at 4:32 PM, Saam barati >> > wrote:
>>> 
 This is great. Thanks Fil.
 
 I propose that we do all that we can to keep this updated.
 I suggest that all patches that change to the IR should also include with 
 it 
 a change to the documentation, and that reviewers should require this.
 
 It’d also be great if other significant changes that seem like the deserve
 a mention in the documentation also get added as part of patches.
 
 Saam
 
> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  > wrote:
> 
> Hi everyone,
> 
> We’ve been working on a new compiler backend for the FTL JIT, which we 
> call B3.  It stands for “Bare Bones Backend”.  We recently enabled it on 
> X86/Mac, and we’re working hard to enable it on other platforms.
> 
> If you’re interested in how it works, I’ve started writing documentation. 
>  I’ll be adding more to it soon!
> https://trac.webkit.org/wiki/BareBonesBackend 
> 
> https://trac.webkit.org/wiki/B3IntermediateRepresentation 
> 
> 
> -Filip
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
 
>> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] PSA: WTF::move has been renamed to WTFMove

[Andy Estes]

Hi folks,

As of , WTF::move has been removed and 
replaced with a macro named WTFMove. This allows us to take advantage of some 
new warnings in clang while still retaining the checks provided by WTF::move. 
More details can be found in .

Happy new year!
Andy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] virtual and override

[Andy Estes]

Good idea.

Andy

 On Feb 20, 2015, at 4:11 AM, Antti Koivisto koivi...@iki.fi wrote:
 
 We have traditionally marked virtual overrides with the 'virtual' keyword for 
 documentation purposes. Nowadays we also have the compiler checked 
 'override'. Using both at the same time seems redundant.
 
 Should we change the coding style so that exactly one of the 'virtual' and 
 'override' must be present for all virtual functions?
 
 
antti
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] webkitbot unable to roll out patches

[Andy Estes]

I tried using webkitbot tonight to roll out a patch, but it’s encountering an 
error running `update-webkit`.

[23:42:16]  estes webkitbot: rollout r172697 made two webarchive layout 
tests start flaking
[23:42:18]  webkitbot estes: Preparing rollout for 
http://trac.webkit.org/changeset/172697 
http://trac.webkit.org/changeset/172697 ...
[23:42:39]  webkitbot Exception executing command: Failed to run 
['Tools/Scripts/update-webkit'] exit_code: 1

Ossy rebooted the bot but the error persists. Perhaps something's gone wrong 
with the bot’s working copy?

Andy___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkitbot unable to roll out patches

[Andy Estes]

 On Aug 18, 2014, at 12:17 AM, Ryosuke Niwa rn...@webkit.org wrote:
 
 How could Ossy reboot the bot!?  As far as I know, he doesn't have the access 
 to the machine on which webkitbot is running.

webkitbot has a restart option.

 
 Having said that, are you sure there are no conflicts?  That error usually 
 occurs when there is some other change such that we can't simply reverse 
 apply the specified revision.

I’m not sure, but since the error was with update-webkit rather than with 
svn-apply I didn’t suspect a failure to revert the patch.

Andy___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] How to download the patch and apply it to git

[Andy Estes]

It looks like everything but the ChangeLog was patched cleanly, so you should 
be fine. You can do a sanity check by typing 'git diff' and comparing the 
output to the original patch.

-Andy

On Aug 5, 2012, at 10:57 PM, talking1...@gmail.com wrote:

 I use  patch -p1  patch file and it show me as follow inforamtion, so if I 
 need to manual modify the patch file?
 
 $ patch -p1  D:\study\jit.patch
 patching file `ChangeLog'
 Hunk #1 FAILED at 1.
 1 out of 1 hunk FAILED -- saving rejects to ChangeLog.rej
 patching file `configure.ac'
 Hunk #1 succeeded at 633 (offset -87 lines).
 patch unexpectedly ends in middle of line
 Hunk #2 succeeded at 779 with fuzz 1 (offset -27 lines).
 
 --
 BGs/Felix Shi
 jit.patch

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

Re: [webkit-dev] How to download the patch and apply it to git

[Andy Estes]

On Aug 5, 2012, at 10:25 PM, talking1...@gmail.com wrote:

 I use follow command patch -p0 D:\work\bsquare-code\jit.patch in the git 
 -bash, but it no response.

patch reads from standard input. Your command should look like:

patch -p0  path-to-file

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

Re: [webkit-dev] How to download the patch and apply it to git

[Andy Estes]

On Aug 5, 2012, at 10:25 PM, talking1...@gmail.com wrote:

 I use follow command patch -p0 D:\work\bsquare-code\jit.patch in the git 
 -bash, but it no response.

Also, you probably want -p1 instead of -p0. I'm sure someone would be happy to 
help you with this on #webkit if you're still having issues.

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

Re: [webkit-dev] Changes to window.focus/window.blur controlled by a setting?

[Andy Estes]

On May 21, 2012, at 12:25 PM, Andrew Wilson atwil...@google.com wrote:

 No, because the setTimeout() callback would be executed outside the context 
 of a user gesture.

This isn't always true. User gesture state is forwarded to the timeout's 
callback if the timeout was scheduled in the context of a user gesture and the 
interval is one second or less.

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

Re: [webkit-dev] Is it possible to programmatically set the Safari Extension Whitelist?

[Andy Estes]

Hi Sam,

Apple's developer forums would be a more appropriate place to ask this 
question. You might try 
https://devforums.apple.com/community/safari/extensions. This list is for 
discussing the development of WebKit itself.

-Andy

On May 14, 2012, at 2:39 PM, Sam Halliday sam.halli...@gmail.com wrote:

 
 Hi all,
 
 (I hope this is the right list to be asking on - I couldn't find a specific
 mailing list for Safari Extensions development).
 
 I have successfully written my first Safari Extension. It loops through all
 input elements and removes autocomplete attributes from type=text
 elements. This overrides idiotic websites which turn off autocompletion
 (e.g. remembering usernames and passwords).
 
 I define the Whitelist of my extensions (in the Extension Builder developer
 tool) to be the websites I want this to work on. A major disadvantage -
 which is stopping me from publicly releasing this extension - is that every
 time I want it to apply to a new website, I have to add it to the Whitelist
 in the Extension Builder and reload the extension.
 
 Is there a way to programmatically edit the Whitelist or expose it to users
 (and not just the developers)?
 
 Regards, Sam
 -- 
 View this message in context: 
 http://old.nabble.com/Is-it-possible-to-programmatically-set-the-Safari-Extension-Whitelist--tp33835785p33835785.html
 Sent from the Webkit mailing list archive at Nabble.com.
 
 ___
 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] git.webkit.org is offline

[Andy Estes]

I'm seeing this when I try to update my tree:

[estes@bestes OpenSource (master)]$ git fetch
git.webkit.org[0: 17.254.20.231]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)

-Andy

On Feb 15, 2012, at 11:29 AM, William Siegrist wrote:

 All services are back.
 
 -Bill
 
 
 On Feb 15, 2012, at 8:55 AM, William Siegrist wrote:
 
 That server (which includes git, build, nightly, and lists) is having 
 trouble keeping up with load, probably due to a disk array problem. I will 
 be rebooting it one more time in an hour or two to try to clear up the 
 problem. 
 
 -Bill
 
 
 On Feb 15, 2012, at 6:38 AM, Osztrogonac Csaba wrote:
 
 Hi,
 
 It seems git.webkit.org is offline.
 Could you check what happened?
 
 br,
 Ossy
 ___
 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] Platform LayoutTests are out of control

[Andy Estes]

Sent from my iPhone

On Apr 20, 2011, at 21:33, Brent Fulgham bfulg...@gmail.com wrote:

 As I sat tonight, waiting for my local repository to update (~1 hour and 
 counting at this point), I had a bit of free time to contemplate the 
 ever-growing size of the platform results of the layout test archive.  Over 
 the last couple of years, the amount of time spent waiting for my local 
 archive to sync with the main repository has grown considerably.  And no 
 wonder, we have a great number of new ports and variants using WebKit, all 
 with their own quirks and unique results.  It's wonderful diversity, and a 
 great metric of how vibrant and enthusiastic a community we have.
 
 But to be honest, I'm TIRED of the huge update times!
 
 My initial knee-jerk reaction was to blame this on the multitude of Chromium 
 layout archives (16 at last count).  Clearly this is needless bloat -- after 
 all, what could possibly be the difference between chromium-linux-x86_64 
 and google-chrome-linux64.  Why are these even distinct entities? ;-)
 
 But my initial bias was not fact-based.  While there are a great number of 
 directories, they only weight in at 784 MB of data.
 
 The bulk of the results is due to Apple's various ports (although limited to 
 a relatively parsimonious 8 directories); they total a bit over 1 GB of data.

In the case of updating, isn't it more interesting to look at which ports 
update expectations more often? Presumably you paid the cost of the initial 
checkout some time ago.

-Andy

 
 Gtk at Qt are downright tiny, at 366 MB and 229 MB (respectively).
 
 All told we have over 2 GB of data that has to be downloaded to each 
 developer's machine before they get the first line of compilable code.  Very 
 few of us ever use more than a handful of these different platform results.
 
 I have a crappy DSL connection, so it's slow.  Since I don't have metered 
 bandwidth, the amount of data doesn't matter that much from a price 
 standpoint, but it's quite annoying from a wasted time standpoint.  I also 
 feel very bad for anyone trying to work on WebKit from behind a metered 
 network connection.
 
 Is there any way we can tame this explosive growth?  Could platform results 
 be located in a separate archive, so that they don't have to be constantly 
 synced across all platforms?
 
 Help!
 
 Thanks,
 
 -Brent
 
 
 === As of 4-20-2011 ==
 android: 56 KB (12 files)
 android-v8: 56 KB (20 files)
 chromium: 7.25 MB (400 files)
 chromium-gpu: 504 KB (78 files)
 chromium-gpu-linux: 5.36 MB (313 files)
 chromium-gpu-mac: 5.68 MB (251 files)
 chromium-gpu-win: 6.98 MB (469 files)
 chromium-linux: 274 MB (12,139 files)
 chromium-linux-x86_64: 2.99 MB (155 files)
 chromium-mac: 83.2 MB (2,582 files)
 chromium-mac-leopard: 87.9 MB (2,391 files)
 chromium-win: 293 MB (17,739 files)
 chromium-win-vista: 1.19 MB (163 files)
 chromium-win-xp: 2.12 MB (265 files)
 google-chrome-linux32: 12.9 MB (523 files) 
 google-chrome-linux64: 972 KB (56 files)
 
 TOTAL:  784 MB (37,556 files)
 
 gtk: 366 MB (17,396 files)
 
 mac: 604 MB (20,686 files)
 mac-leopard: 389 MB (10,169 files)
 mac-snowleopard: 592 KB (103 files)
 mac-tiger: 9.61 MB (311 files)
 mac-wk2: 480 KB (86 files)
 win: 15.9 MB (972 files)
 win-wk2: 432 KB (89 files)
 win-xp: 1.26 MB (111 files)
 
 TOTAL: 1.02 GB (32,527 files)
 
 qt: 229 MB (11,876 files)
 qt-linux: 24.0 KB (8 files)
 qt-mac: 16.0 KB (3 files)
 qt-win: 16.0 KB (3 flles)
 qt-wk2: 305 KB (3 files)
 
 TOTAL: 229 MB (11,893 files)
 
 
 
 
 ___
 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] map.d.co.il broken - back out r66156?

[Andy Estes]

Hi Jeremy,

I'm working on this. Thanks for bringing it to my attention!

-Andy

On Sep 19, 2010, at 2:17 AM, Jeremy Moskovich wrote:

 Thanks Maciej,
 
 The original bug had no information on the sites that were fixed, very good 
 to hear that this improves compatibility!
 
 Can you comment on whether this is being actively worked on?  Or is this 
 waiting for someone to pick it up?  Just want to make sure we can fix this 
 regression ASAP.
 
 Thanks,
 Jeremy
 
 On Thu, Sep 16, 2010 at 6:42 PM, Maciej Stachowiak m...@apple.com wrote:
 
 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] Mouse wheel event precision

[Andy Estes]

On Jun 8, 2010, at 8:34 PM, Nathan Vander Wilt wrote:

 What Safari 4 seemed to do was simply provide much greater precision, where 
 scrolling half a line simply yielded about 20 units instead of being ignored. 
 So the above code would yield integral deltas in browsers that only fired 
 events in 3-line increments, but nice fractional deltas in WebKit.

Some sites choose to completely ignore wheel deltas less than 120.  On devices 
like trackpads where a slow but continuous scrolling gesture tends to result in 
a series of small, non-cumulative mousewheel events, the old behavior caused 
these gestures to be completely ignored.  Yahoo! Mail was one such site where 
the small fractional values caused compatibility issues.

 What Safari 5's WebKit does is turn one line into 4800 (!) units instead of 
 40.

This could be plausible on a trackpad that scales the wheelDelta based on 
gesture velocity, although I'd expect a value of 120 for each tick of a 
conventional wheel mouse.  As Peter said, if you have a test case where Safari 
disagrees with IE on Windows or Chrome on either platform, please file a bug 
and we'll investigate.

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

Re: [webkit-dev] Mouse wheel event precision

[Andy Estes]

Hi Nathan,

It is true that Safari now emits mousewheel events in increments of 120 for 
compatibility reasons.  However, there is no loss of granularity in the sense 
that events are generated on fractional wheel ticks and are accelerated on 
platforms that support it.  The only difference is that you will see increments 
of 120 rather than increments of 1.  It's been a few months since I've checked 
(and I can't look at the URL you attached on my phone), but I believe you'll 
see the same behavior in Chrome and IE.

I would also point out that in DOM Level 3 Events, mousewheel events are 
considered deprecated and the unit of wheelDelta is left up to the implementor. 
 IE set this increment to 120 some time ago, and we chose to match this 
behavior to be compatible with sites that expect it.  As you can imagine, the 
opposite problem occurs on those sites (extremely slow scrolling).  
Unfortunately any decision we made here was bound to break some sites.

-Andy

Sent from my iPhone

On Jun 8, 2010, at 19:09, Nathan Vander Wilt nate-li...@calftrail.com wrote:

 In Safari 4, the following event handler would log nice smooth values when 
 scrolling:
 // logs: -3, -9, -6, -48, ...
 document.addEventListener(mousewheel, function(e) { 
 console.log(e.wheelDeltaY); });
 
 In Safari 5, the mousewheel events have lost all precision, and are now big 
 ugly integral multiples of 120:
 // logs: -120, -240, -120, -480, ... (no correspondence with above values, of 
 course)
 document.addEventListener(mousewheel, function(e) { 
 console.log(e.wheelDeltaY); });
 
 This is a serious loss of precision, and brings us back to the primitive days 
 when a mouse a had 1-axis clicky scroll wheel if it had one at all, and 
 Firefox was the top browser. Compare the smooth, precise scroll zooming of 
 http://calftrail.com/Share/multitouch/ in Safari 4 to the jerky, way-too-fast 
 zooming in Safari 5.
 
 Is this a regression introduced directly in recent WebKit builds, or is it 
 Safari-specific? If the former, was it really necessary and can it please be 
 rolled back?
 
 thanks,
 -natevw
 ___
 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] Mouse wheel event precision

[Andy Estes]

On Jun 8, 2010, at 19:50, Andy Estes aes...@apple.com wrote:

 The only difference is that you will see increments of 120 rather than 
 increments of 1

Perhaps a better way to say this is that the old wheelDelta values are now 
simply being multiplied by 120.  The precision hasn't changed, just the atomic 
unit of a tick.

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