[webkit-dev] Webkit nightly auto-updates (MacOS)
Hi everyone, I like to use the Webkit nightly builds for general development/testing and have them installed on two machines that share the same operating system (MacOS Mountain Lion). On one of them I get a nice prompt dialog notifying me of a new update and allowing to select 'install' to proceed with downloading the update. Upon completion I get a 'restart to install' button that install the update and restarts the browser. On the other machine I need to manually download the update, open the image and copy the Webkit.app file to /Applications. Anyone know why I get these two different behaviours and what can be done about it? Thanks Filipe Moreira -- Freelance Web Developer (Ruby Javascript) filipemoreira.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Feature: Implementing XHR2 timeouts
Hi, I'd like to inform you about about my plan to implement the timeout behavior specified in http://www.w3.org/TR/XMLHttpRequest/#the-timeout-attribute (and other sections with regards to that attribute). I opened meta bug: https://bugs.webkit.org/show_bug.cgi?id=94461 Please let me know if there are any concerns or objections. Regards, Dominik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] New feature: CSS3 GCPM
You're going to see some patches in the coming weeks (first one coming soon) to begin work on implementing: http://www.w3.org/TR/css3-gcpm/ In some cases, there are going to be syntactic deviations from the spec as we experiment (based off discussions that are ongoing in the CSS WG), but in general we'll be implementing the features in the working draft. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
On Aug 9, 2012, at 3:41 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 03:14, Peter Beverloo pe...@chromium.org wrote: On Thu, Aug 9, 2012 at 11:09 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 02:41, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, bugs.webkit.org and trac.webkit.org is unavailable again. :( Could you check it, please? This is caused by a problem on a host that I don't have sufficient privileges on to be able to address the issue myself. I've pinged people that should be able to resolve the issue, but given that it's currently 3am in California it may be a few hours before they're awake and fixing it. Thank you. Is there any way an on-call or monitoring system could be set up? While it fortunately occurs much less frequently nowadays than it did earlier in the year, it --please excuse my directness-- is unacceptable for a project the size of WebKit to have critical infrastructure unavailable like this for several hours. Even though it's 3am in California, there are many contributors in Asia and Europe who are severely impacted by this. We have people online virtually 24x7 that are capable of investigating and addressing issues with the webkit.org infrastructure. I'm one such person. This particular case is an unfortunate combination of events: a configuration error on a subset of the new hardware that webkit.org was recently migrated to has unintentionally limited the number of people that can access the host that is currently experiencing problems, and the person that such issues are escalated to is currently on vacation. It's an unfortunate combination, but also one that is unlikely to repeat. One thing we should look in to is improving the process for reporting issues with webkit.org infrastructure. webkit-dev isn't an ideal way to report issues that our monitoring system hasn't noticed as there's no separation between the regular discussion and more urgent issues, so the emails can be overlooked. I am back from vacation and just wanted to let everyone know that I am sorry that so many things went wrong and combined to create significant downtime. Like Mark said, we do have systems in place for monitoring, and we usually catch and fix things quickly, even at 3am. The new hardware is a big change for us, and our monitoring system is also changing to accommodate the new environment, so I will be spending time this week getting to the bottom of the database issue and making sure we're covering everything we need to with our monitoring systems. As for a better notification system, we can create a webkit-sysadmin list that contains the people with shell access and send admin@webkit mail there. Currently, I'm the only recipient of admin@webkit mail, so we should fix that single point of failure. Does that seem reasonable to everyone? Thanks, -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New feature: CSS3 GCPM
Anything specific or the whole specification? The mixture of features defined in there covers a rather broad spectrum, and sometimes overlaps with features defined elsewhere (i.e. float modifiers v.s. positioned floats, CMYK colors which probably shouldn't be there). Is there a meta bug we can track? Thanks, Peter On Mon, Aug 20, 2012 at 5:15 PM, David Hyatt hy...@apple.com wrote: You're going to see some patches in the coming weeks (first one coming soon) to begin work on implementing: http://www.w3.org/TR/css3-gcpm/ In some cases, there are going to be syntactic deviations from the spec as we experiment (based off discussions that are ongoing in the CSS WG), but in general we'll be implementing the features in the working draft. dave (hy...@apple.com) ___ 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] svns...@macosforge.org ?
I just got back to work and will look into this as soon as possible. I've seen the problem before on other infrastructure, but I don't think we ever could reproduce it. Hopefully I'll have better luck if its consistent now. Thanks, -Bill On Aug 20, 2012, at 9:13 AM, Dana Jansens dan...@chromium.org wrote: FYI This is still continuing to happen. On Tue, Aug 14, 2012 at 5:03 AM, Eric Seidel e...@webkit.org wrote: Bill would know. On Tue, Aug 14, 2012 at 1:58 AM, Philippe Normand ph...@igalia.com wrote: On Wed, 2012-08-08 at 13:52 -0700, Adam Barth wrote: I noticed today that some patches are authored by svns...@macosforge.org: http://trac.webkit.org/search?q=svnsync Is this behavior expected? I guess this is a bug in one of the SVN commit hooks? Philippe ___ 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] New feature: CSS3 GCPM
Addendum: The current Editor's Draft is significant different from the published WD, and includes something similar to CSS Exclusions. Since Adobe is implementing these in WebKit, it may be good to know what your ideas on these are as well :-). http://dev.w3.org/csswg/css3-gcpm/ Thanks, Peter On Mon, Aug 20, 2012 at 5:20 PM, Peter Beverloo pe...@chromium.org wrote: Anything specific or the whole specification? The mixture of features defined in there covers a rather broad spectrum, and sometimes overlaps with features defined elsewhere (i.e. float modifiers v.s. positioned floats, CMYK colors which probably shouldn't be there). Is there a meta bug we can track? Thanks, Peter On Mon, Aug 20, 2012 at 5:15 PM, David Hyatt hy...@apple.com wrote: You're going to see some patches in the coming weeks (first one coming soon) to begin work on implementing: http://www.w3.org/TR/css3-gcpm/ In some cases, there are going to be syntactic deviations from the spec as we experiment (based off discussions that are ongoing in the CSS WG), but in general we'll be implementing the features in the working draft. dave (hy...@apple.com) ___ 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] New feature: CSS3 GCPM
On Aug 20, 2012, at 11:32 AM, Peter Beverloo wrote: Addendum: The current Editor's Draft is significant different from the published WD, and includes something similar to CSS Exclusions. Since Adobe is implementing these in WebKit, it may be good to know what your ideas on these are as well :-). http://dev.w3.org/csswg/css3-gcpm/ Thanks, Peter We're not touching the controversial stuff. :) Specifically we're looking into implementing the screen pagination mode (paged-x/paged-y overflow) and the associated features that come along with that. We're also going to implement page floats and the general improvements to multi-column layout that are in the draft. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New feature: CSS3 GCPM
On 8/20/12 10:07 AM, David Hyatt hy...@apple.com wrote: On Aug 20, 2012, at 11:32 AM, Peter Beverloo wrote: Addendum: The current Editor's Draft is significant different from the published WD, and includes something similar to CSS Exclusions. Since Adobe is implementing these in WebKit, it may be good to know what your ideas on these are as well :-). http://dev.w3.org/csswg/css3-gcpm/ Thanks, Peter We're not touching the controversial stuff. :) Specifically we're looking into implementing the screen pagination mode (paged-x/paged-y overflow) and the associated features that come along with that. We're also going to implement page floats and the general improvements to multi-column layout that are in the draft. Do the multi-column improvements you're considering include column selectors? Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New feature: CSS3 GCPM
On Aug 20, 2012, at 12:40 PM, Alan Stearns wrote: On 8/20/12 10:07 AM, David Hyatt hy...@apple.com wrote: On Aug 20, 2012, at 11:32 AM, Peter Beverloo wrote: Addendum: The current Editor's Draft is significant different from the published WD, and includes something similar to CSS Exclusions. Since Adobe is implementing these in WebKit, it may be good to know what your ideas on these are as well :-). http://dev.w3.org/csswg/css3-gcpm/ Thanks, Peter We're not touching the controversial stuff. :) Specifically we're looking into implementing the screen pagination mode (paged-x/paged-y overflow) and the associated features that come along with that. We're also going to implement page floats and the general improvements to multi-column layout that are in the draft. Do the multi-column improvements you're considering include column selectors? Nope. I want to wait a bit and see if we get all the selector stuff reconciled with regions. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] svns...@macosforge.org ?
Thanks Bill. There's no big rush. It just seems to be happening periodically. Adam On Mon, Aug 20, 2012 at 9:22 AM, William Siegrist wsiegr...@apple.com wrote: I just got back to work and will look into this as soon as possible. I've seen the problem before on other infrastructure, but I don't think we ever could reproduce it. Hopefully I'll have better luck if its consistent now. Thanks, -Bill On Aug 20, 2012, at 9:13 AM, Dana Jansens dan...@chromium.org wrote: FYI This is still continuing to happen. On Tue, Aug 14, 2012 at 5:03 AM, Eric Seidel e...@webkit.org wrote: Bill would know. On Tue, Aug 14, 2012 at 1:58 AM, Philippe Normand ph...@igalia.com wrote: On Wed, 2012-08-08 at 13:52 -0700, Adam Barth wrote: I noticed today that some patches are authored by svns...@macosforge.org: http://trac.webkit.org/search?q=svnsync Is this behavior expected? I guess this is a bug in one of the SVN commit hooks? Philippe ___ 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] What's the proper care and feeding of the Apple Mac Lion Pixel Results?
I'm attempting to fix some repaint bugs in WebKit, thus I'm using the --pixel tests. run-webkit-tests -p fast/repaint shows a bunch of failures on my Mac Lion box. I'd like to fix those failures, but I'm not sure what the proper procedure is. run-webkit-tests -p fast/repaint --reset-results changes nearly 200 pngs! in fast/repaint (presumably due to changed checksums embedded in the pngs?) Is there a proper way to maintain pngs for the Apple Mac Lion port? Should I just check mine in? Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Trac/Svn Migration - Friday the 27th, 7-9am PDT
On Aug 6, 2012, at 4:43 AM, Yuta Kitamura yu...@chromium.org wrote: As a workaround, try this: log in to trac, and visit https://trac.webkit.org/prefs/language to change the UI language. Apparently this preference page is hidden, but seems to work. The lack of a preferences link is due to some things not working or being useful before. For example, the Full Name and Email fields on the general tab aren't the same as the Profile link due to our custom user authentication system. I'm not sure if setting those will do anything for you, but since the Date/Time and Language settings are useful I added the link next to Profile. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of multithreaded image decoding
On Fri, Aug 17, 2012 at 1:54 AM, Dong Seong Hwang luxte...@company100.netwrote: 2012/8/14 Dong Seong Hwang luxte...@company100.net Trigger image decoding early in layout and scroll will certainly relieve flashing though it can’t completely remove the problem. We will apply this optimization to parallel image decoder. I changed parallel image decoder to trigger decoding on layout as Alpha suggested. Unfortunately, it does not seem to relieve flashing. I tested the change on Tumblr site, but the difference was visually indistinguishable. By itself it won't help - you also need to synchronize at raster time (i.e. block if the image isn't available). Once the encoded bits are downloaded off the wire and we've fire the load event on the image, we have to block the next raster on having the decoded pixels available. I think the way to look at this is running a race. Your goal is to have a non-main thread run a race - decode the images - and try to complete faster than the main thread would have. The finish line is the point at which the raster engine needs access to the decoded pixels for a given image. At that point, you have to block the rasterization process until the pixels are ready. The start line is sometime after the bits are downloaded off of the network and before the raster engine needs it. If you think of the current code in that model, the start line is when we first attempt to paint an image that isn't in the decode cache and the finish line is when we hand it to the GraphicsContext. Those happen to be a straight call through and there's no useful main thread work to be done in that time so we decode on the main thread. The only way to speed this up with threads would be to use multiple threads to decode a given image or to split the decode and resize operations across threads. Useful, but there's limited utility. The real trick is to move either the start or the finish line. Starting the decode on layout is one way to move the start line forward and provide more time for the thread to get the image ready before paint time. You could even consider starting sooner - such as on network load - but the tradeoff there is the sooner you start decoding the less information you will have about how the image will actually be used. You might start decoding an image that will never be painted, or decode at the wrong scale or with the wrong clip. The closer you get to the actual paint time the more accurate your information will be. For instance after layout you can have a pretty good guess at whether an image will be in the viewport and the scale, although the layout might change again before painting. This indicates that you may want some sort of decoding queue with decoding jobs that can be added, modified, or removed after being entered into the queue. The other line to move is the finish line. You could imagine that instead of passing GraphicsContext commands directly to the raster backend (CoreGraphics/cairo/skia/etc) you instead buffer the commands into queue and play them later. Then you could start the decoding process when you hit the WebCore paint call for the image and only block when passing the buffered commands into the actual backend. Buffering the GraphicsContext commands could allow for a number of other optimizations (collapsing draws, dropping fully obscured draw calls, etc) The raster backend may even be capable of taking a promise for decoded data instead of the data itself which would let it push the finish line further back. This last option is what we're pursuing in skia as part of other optimizations, but might be useful for other backends. I think you have a lot of options here. I want to emphasize that I think the user experience is the most important thing to keep in mind with all of this work. Displaying the page faster is a great enhancement to a user's happiness and improving our image decoding can definitely get us some big wins. I think any successful project here will have to be invisible to the end user - we can't have pages flashing in unpredictably. - James However, theoretically there must be some improvements. I want to discuss more about it while parallel image decoder is reviewed. ___ 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 simpler proposal for handling failing tests WAS: A proposal for handling failing layout tests and TestExpectations
On Sat, Aug 18, 2012 at 8:31 PM, Filip Pizlo fpi...@apple.com wrote: On Aug 18, 2012, at 5:55 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 18, 2012, at 5:11 PM, Filip Pizlo fpi...@apple.com wrote: Maybe at this point we can agree to let Dirk land some variant of this with whatever half-way sensible name (any of the options on the table are decent) and see how it works? It seems that the only thing anyone is disagreeing over is naming and which files to keep around, which is a much smaller set of differences than status-quo versus any variant of this proposal. I agree that we should adopt some variant over the status quo. As you rightly noted, there are too many different ways to handle tests that deviate from the original expectation, and we have the opportunity to obsolete most of those ways with an approach that combines advantages of multiple current approaches. However, I fear that whatever names we pick for the first round will then be unchangeable due to status quo bias (which we see a lot of in test infrastructure discussions, indeed, even this one). And anyone arguing against change at that point will have a valid argument that a huge global rename of tests is a bad idea. So I think it's worth expending a little effort to find names that are good. Would you object to -expected-failure/-unexpected-pass as a naming scheme, along with the approach of keeping both around when they are used? I don't mind -expected-failure/-unexpected-pass, and I think that the slightly added verbosity will make things clearer. Would you also advocate having the tooling mandate that the expected files are in either, but never both, of these two states: 1) -expected.foo 2) -expected-failure.foo/-unexpected-pass.foo That is, if we're not in a failing state, the -expected suffix is what we use. Dirk, what do you think? (And a possibly correct retort will be to tell us that we're bikeshedding. ;-)) I think I'm lost :) I think this is partially because Maciej didn't respond to my previous questions about this proposal, and partially because I'm not actually sure which combinations you're now proposing we have (there was something like twelve different variants :). Perhaps someone can recap how they expect things to work and what the extensions being proposed for each case are? While I agree with Maciej's point that it would be nice if -expected.txt referred to whatever we currently expect to happen, as this discussion indicates, the definition of expected itself starts to become unclear. This is partially why I only wanted there to be one baseline allowed for a given test regardless of pass/fail/unknown status. The other (and IMO more serious) flaw with allowing more than one baseline to exist at a time is that the one that isn't actually being exercised is subject to bitrot, and hence it's not clear how relevant it will stay. But it's hard to discuss this clearly without being referring to the different names and cases, and so I'll wait until someone can recap first. -- Dirk -F Regards, Maciej -Filip On Aug 18, 2012, at 2:01 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 18, 2012, at 1:08 AM, Filip Pizlo fpi...@apple.com wrote: I like your idea of having both the result-we-currently-expect and the result-we-think-may-be-more-correct to be checked in. I still prefer Dirk's naming scheme though. I think if we had both checked in, the result-we-think-may-be-more-correct should be named something other than -expected, since it is not, in fact, expected. That was the basis of my naming scheme. I think I would be happy with any scheme that had both checked in, and matched the criteria that you never have a file named -expected that is unexpected. For example, there could be schemes with no file named expected. If you let it be verbose, you could have: Single result: foo-expected.txt Possibly-worse current result, possibly-better older result: foo-expected-failure.txt foo-unexpected-pass.txt I get the notion that expected always means literally what it seems to mean from the standpoint of whether the tooling is silent for the test (actual == expected) or has something to say. But I think that if the tooling is behaving right, your concern that a test would fail if it did *not* match the failing result would be addressed: the tooling could be silent for actual == failing (if a failing file exists) but notify you of an unexpected pass if actual == expected. But if you match neither, you get a failure for not matching the failing result. That still strikes me as a little goofy. Not failing is failing, and getting the expected result is unexpected. I think my extra-verbose naming scheme above would better match what you suggest the tool UI would do. Maybe there is a more concise way to get the same point across. Regards, Maciej ___
Re: [webkit-dev] Trac/Svn Migration - Friday the 27th, 7-9am PDT
On Aug 6, 2012, at 4:16 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, With the new Trac I noticed two little bit annoying thing: Author name: - https://trac.webkit.org/browser/trunk As far as I remember before the update we could see the full email addresses of the authors. Now we can see only the email addresses before @. It makes harder to identify the author. Can we get the full mail address (and/or IRC nick, full name) somehow? (It seems we still get full mail addresses for wiki: https://trac.webkit.org/wiki/WikiStart?action=history ) I can't seem to find an option or even an easy hack to get the full author name in there, so it'll have to stay this way until I finish with more important things like the database stability. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
