Re: [webkit-dev] mouseenter and mouseleave events
On Apr 22, 2013, at 3:32 PM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Wednesday 17 April 2013, Maciej Stachowiak wrote: Seems like a reasonable feature to add. Would you mind also reviewing the patch in question then or help me find a reviewer with the right knowledge? Most of the patch is boiler plate work. The central part is how and when the events are dispatched and confined to additional responsibility of updateHoverActiveState. I took a quick look at it and concluded that it would require some study of existing code to be confident of its correctness. I encourage reviewers with knowledge of DOM or events to take a look, as I will likely not have a chance for at least a few days. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On Safari 5.1.8 for Snow Leopard...
This isn't really a proper forum for this question. This list is for development of WebKit, not discussing the contents of specific vendor releases. For more information on this specific question, you can look at Apple's release notes for 5.1.8, or contact Apple Developer Relations. - Maciej On Apr 21, 2013, at 11:57 PM, Yuhong Bao yuhongbao_...@hotmail.com wrote: To the Apple people on this list: What exactly does Safari 5.1.8 for Snow Leopard contain? Does it contain security updates? Yuhong Bao ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On Safari 5.1.8 for Snow Leopard...
As Maciej notes, this is not the right mailing list to ask these sorts of things. But since the answer appears simple, here it is: http://en.wikipedia.org/wiki/Safari_version_history claims that Safari 5.1.8 means WebKit 534.58.2 which theoretically comes from: http://trac.webkit.org/browser/branches/safari-534.58-branch http://opensource.apple.com/release/mac-os-x-1068/ also contains all the open-source code from the latest Snow Leopard (10.6.8). I don't work for Apple, and Wikipedia may be wrong. But at least now you have the source. On Tue, Apr 23, 2013 at 12:02 AM, Maciej Stachowiak m...@apple.com wrote: This isn't really a proper forum for this question. This list is for development of WebKit, not discussing the contents of specific vendor releases. For more information on this specific question, you can look at Apple's release notes for 5.1.8, or contact Apple Developer Relations. - Maciej On Apr 21, 2013, at 11:57 PM, Yuhong Bao yuhongbao_...@hotmail.com wrote: To the Apple people on this list: What exactly does Safari 5.1.8 for Snow Leopard contain? Does it contain security updates? Yuhong Bao ___ 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] Test frame size for reftests
Hey there, I was debugging a test which was passing in the testrunner, but failing in the testbrowser. It was because the reftests compare only in a 800*600px frame, although we have many tests which are taller than this frame. If there was a mismatch to the expected result outside that frame and the difference doesn't affect the scrollbar then the test just passes silently. Do we have any guidelines for these cases? We could either: 1. Split up the tests concerned. 2. Increase the test frame size to a bigger fixed value. (I'm thinking only in reftests.) 3. Generate the images for the actual view. (?) 4. ? Any thoughts? Thanks, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Test frame size for reftests
Yes, that be would the cleanest solution. If there is no concerns against it, I'm going to file a bug. Zoltan On Tue, Apr 23, 2013 at 11:36 AM, Benjamin Poulain benja...@webkit.orgwrote: Hi, On Tue, Apr 23, 2013 at 11:26 AM, Zoltan Horvath zol...@webkit.orgwrote: I was debugging a test which was passing in the testrunner, but failing in the testbrowser. It was because the reftests compare only in a 800*600px frame, although we have many tests which are taller than this frame. If there was a mismatch to the expected result outside that frame and the difference doesn't affect the scrollbar then the test just passes silently. Do we have any guidelines for these cases? We could either: 1. Split up the tests concerned. 2. Increase the test frame size to a bigger fixed value. (I'm thinking only in reftests.) 3. Generate the images for the actual view. (?) 4. ? Any thoughts? I am happy you are looking into this issue! This has been bothering me for a while :) The current mode works fine for some ref-tests but is really annoying for others. I would love to have a way to compare the entire page instead of the viewport. Maybe it could just be an API on testrunner? Like: testRunner.dumpEntirePagePixels()? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling Experimental Features
Thanks for your feedback everyone. I have filed a bug to track this issue https://bugs.webkit.org/show_bug.cgi?id=115059 And will do some further investigation into how best to make it happen. -Bear On 4/22/13 12:33 PM, Eric Seidel e...@webkit.org wrote: FWIW, Blink is going through this right now too. We're attempting to move completely away from prefixed development: http://www.chromium.org/blink#vendor-prefixes To do that, that requires making it possible enable/disable CSS properties at runtime: https://code.google.com/p/chromium/issues/detail?id=232181 https://code.google.com/p/chromium/issues/detail?id=234270 Perhaps this is another opportunity for the two code bases to learn from one another as we both implement solutions to this. On Mon, Apr 22, 2013 at 9:32 AM, Simon Fraser simon.fra...@apple.com wrote: On Apr 20, 2013, at 10:03 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2013, at 3:50 PM, Timothy Hatcher timo...@apple.com wrote: On Apr 19, 2013, at 6:15 PM, Bear Travis betra...@adobe.com wrote: What do folks think about adding a mechanism for users to toggle features like this on in WebKit nightlies? I don't have a definite approach yet, but wanted to float the idea for feedback. I like the idea. Having things off for everyone but the engineers is a bad approach and misses out on testing. We could have WebKit modify Safari's Develop menu to provide additional items to toggle. Safari provides an Enable WebGL item, we could inject more items next to it. On Mac, we could at the very last use 'defaults write' to toggle experimental runtime-enabled features. One problem is that most CSS-exposed experimental features are not runtime-switchable. We'd have to do a bunch of work in the parser and style resolver to make this possible. Simon ___ 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
