Re: [webkit-dev] When are patches added to EWS Queue?
We're still having Queue troubles today. Bandaids are in place for the moment, but expect possible service outages today. Sorry. :( I'll email webkit-dev when everything is back to stable. -eric On Tue, Dec 7, 2010 at 7:30 PM, Adam Barth aba...@webkit.org wrote: Hi Brian, We had an issue with the EWS today when the machine ran out of disk. I'm in the process of bringing up a new machine with 10x the disk space. There's nothing you need to do. Everything should get rolling shortly. Adam On Tue, Dec 7, 2010 at 7:20 PM, Brian Weinstein bweinst...@apple.com wrote: I uploaded a patch a couple of hours ago (uplodaded https://bugs.webkit.org/attachment.cgi?id=75850action=edit to bug https://bugs.webkit.org/show_bug.cgi?id=50586). However, after those couple of hours, it doesn't even look like it has been queued in the EWS system (a couple of bots EWS bots are idle, and the bubbles don't have numbers on them to indicate where the patch is in the queue). Is there something I can do to add my patch to the queue? Do I need to re-upload it? Thanks, Brian Weinstein ___ 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] Pixel tests and displaying text
If you never write layout tests, you can stop reading. Right now few ports run pixel tests (a shame). One reason is because we frequently need different reference images for each port, and creating hundreds or thousands of these is a hassle. Maintenance burden also increases. We could greatly decrease the number of these baselines by following a simple rule: don't display text unless you need to. For example, let's say I have a test that is supposed to display a green square. If the test output is: A green square means this test passes. If there is any red below, fail. [green square here] ...then for each platform that has different font rendering, whether that be subpixel AA differences, font size differences, or anything else, we'll need new baselines. By contrast, if that explanation was in an HTML comment inside the test code, and the output was a simple green square, one baseline would serve for all ports. I think this doesn't really hinder tracking down test failures, for a couple of reasons: * Most tests are green = pass, red = failure by convention, so frequently a pixel result that differs from the baseline is easily classifiable at a quick glance. * When this isn't the case, one of the first steps in understanding the test output is to read the test, at which point the HTML comment will explain things. Obviously, some tests need to display text, but this seems to me to be a good rule of thumb. Am I missing anything? If not, is anyone interested in helping to make this change on existing tests where possible, to trim the number of baselines in the tree and make it easier for new ports to bring up pixel tests? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel tests and displaying text
I think we should just switch the default for text vs. pixel tests. Make tests require a script layoutTestController.dumpPixels()/script to dump pixels. We could also white-list certain directories.[1] -eric 1. If we did add white-listing, I'd like to move away from our hacky-in-run-webkit-tests white-lists to an explict on-disk per-directory config file or similar. Understanding why fast/loader turns on the loader callbacks when you're writing a test has driven more than one would-be-webkit-hacker crazy. :) On Wed, Dec 8, 2010 at 12:43 PM, Simon Fraser simon.fra...@apple.comwrote: On Dec 8, 2010, at 12:13 PM, Peter Kasting wrote: If you never write layout tests, you can stop reading. Right now few ports run pixel tests (a shame). One reason is because we frequently need different reference images for each port, and creating hundreds or thousands of these is a hassle. Maintenance burden also increases. We could greatly decrease the number of these baselines by following a simple rule: don't display text unless you need to. For example, let's say I have a test that is supposed to display a green square. If the test output is: A green square means this test passes. If there is any red below, fail. [green square here] ...then for each platform that has different font rendering, whether that be subpixel AA differences, font size differences, or anything else, we'll need new baselines. By contrast, if that explanation was in an HTML comment inside the test code, and the output was a simple green square, one baseline would serve for all ports. I think this doesn't really hinder tracking down test failures, for a couple of reasons: * Most tests are green = pass, red = failure by convention, so frequently a pixel result that differs from the baseline is easily classifiable at a quick glance. * When this isn't the case, one of the first steps in understanding the test output is to read the test, at which point the HTML comment will explain things. Obviously, some tests need to display text, but this seems to me to be a good rule of thumb. Am I missing anything? If not, is anyone interested in helping to make this change on existing tests where possible, to trim the number of baselines in the tree and make it easier for new ports to bring up pixel tests? I totally agree, and have been avoiding test in pixel tests as much as possible recently. One useful strategy is to add explanatory notes to the test as HTML comments, so the purpose of the test is easily determined by someone looking at the source. Simon ___ 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] Pixel tests and displaying text
On Dec 8, 2010, at 12:13 PM, Peter Kasting wrote: If you never write layout tests, you can stop reading. Right now few ports run pixel tests (a shame). One reason is because we frequently need different reference images for each port, and creating hundreds or thousands of these is a hassle. Maintenance burden also increases. We could greatly decrease the number of these baselines by following a simple rule: don't display text unless you need to. For example, let's say I have a test that is supposed to display a green square. If the test output is: A green square means this test passes. If there is any red below, fail. [green square here] ...then for each platform that has different font rendering, whether that be subpixel AA differences, font size differences, or anything else, we'll need new baselines. By contrast, if that explanation was in an HTML comment inside the test code, and the output was a simple green square, one baseline would serve for all ports. I think this doesn't really hinder tracking down test failures, for a couple of reasons: * Most tests are green = pass, red = failure by convention, so frequently a pixel result that differs from the baseline is easily classifiable at a quick glance. * When this isn't the case, one of the first steps in understanding the test output is to read the test, at which point the HTML comment will explain things. Obviously, some tests need to display text, but this seems to me to be a good rule of thumb. Tests that involve text can still have cross-platform results if they use the Ahem font. See for example http://trac.webkit.org/browser/trunk/LayoutTests/fast/css/first-letter-set-text.html?rev=55196. Am I missing anything? If not, is anyone interested in helping to make this change on existing tests where possible, to trim the number of baselines in the tree and make it easier for new ports to bring up pixel tests? PK ___ 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] Pixel tests and displaying text
On Dec 8, 2010, at 12:13 PM, Peter Kasting wrote: We could greatly decrease the number of these baselines by following a simple rule: don't display text unless you need to. Seems like a good idea. I’m worried a bit, though, that if we can’t use any text in them at all, the tests are then not at all self explanatory. You have to be an expert on the test to understand what it’s testing and what success and failure look like. Maybe we can come up with a new form of test that puts the explanation of the test somewhere that will not be dumped and the test in a frame, and have the pixel tests dump only the frame. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel tests and displaying text
On Wed, Dec 8, 2010 at 12:57 PM, Darin Adler da...@apple.com wrote: I’m worried a bit, though, that if we can’t use any text in them at all, the tests are then not at all self explanatory. You have to be an expert on the test to understand what it’s testing and what success and failure look like. I think for tests where we're worried that's the case, we should (for now) just go ahead and continue using text and having separate baselines. The per-test cost is relatively low and the number of tests that fall into this bucket is hopefully small? Maybe we can come up with a new form of test that puts the explanation of the test somewhere that will not be dumped and the test in a frame, and have the pixel tests dump only the frame. That would also work. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel tests and displaying text
On Dec 8, 2010, at 1:02 PM, Peter Kasting wrote: the number of tests that fall into this bucket is hopefully small? Maybe we should talk about some specific tests. I can‘t think of many tests with no text that are self explanatory! -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel tests and displaying text
On Wed, Dec 8, 2010 at 1:04 PM, Darin Adler da...@apple.com wrote: On Dec 8, 2010, at 1:02 PM, Peter Kasting wrote: the number of tests that fall into this bucket is hopefully small? Maybe we should talk about some specific tests. I can‘t think of many tests with no text that are self explanatory! It's not so much whether the test is self-explanatory as whether, given a result that differs from the baseline, it's obvious whether it's a failure and how to proceed. The particular change that triggered this thread, for example, was http://trac.webkit.org/changeset/73531 . The tests added in this commit are basically of the standard some number of green squares; red = failure form. Moving the explanatory text from them into the HTML for the tests themselves would not greatly decrease the ease with which someone could understand why they'd suddenly started failing the tests. Text is more useful when it's more likely that differences will occur that are not obviously either OK or wrong. In that case, having the text in the test output saves a trip to the HTML source on the part of the person trying to figure out whether he's seeing a failure. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel tests and displaying text
On Dec 8, 2010, at 12:57 PM, Darin Adler wrote: On Dec 8, 2010, at 12:13 PM, Peter Kasting wrote: We could greatly decrease the number of these baselines by following a simple rule: don't display text unless you need to. Seems like a good idea. I’m worried a bit, though, that if we can’t use any text in them at all, the tests are then not at all self explanatory. You have to be an expert on the test to understand what it’s testing and what success and failure look like. Maybe we can come up with a new form of test that puts the explanation of the test somewhere that will not be dumped and the test in a frame, and have the pixel tests dump only the frame. Do HTML comments fulfill this? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel tests and displaying text
On Dec 8, 2010, at 1:23 PM, Simon Fraser wrote: On Dec 8, 2010, at 12:57 PM, Darin Adler wrote: On Dec 8, 2010, at 12:13 PM, Peter Kasting wrote: We could greatly decrease the number of these baselines by following a simple rule: don't display text unless you need to. Seems like a good idea. I’m worried a bit, though, that if we can’t use any text in them at all, the tests are then not at all self explanatory. You have to be an expert on the test to understand what it’s testing and what success and failure look like. Do HTML comments fulfill this? Peter, Simon, You both have convinced me that HTML comments could be fine for explaining what a test is testing. Maybe we could come up with a format that makes it likely we’ll spot those comments. The success vs. failure aspects can probably be addressed by the “see no red” and other such things. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel tests and displaying text
On Wed, Dec 8, 2010 at 2:03 PM, Darin Adler da...@apple.com wrote: You both have convinced me that HTML comments could be fine for explaining what a test is testing. Maybe we could come up with a format that makes it likely we’ll spot those comments. In the (few) tests I've written, I generally use top-of-file comments that describe both the expected results and what the underlying causes for potential failures are. See for example the layout test at the bottom of https://bugs.webkit.org/attachment.cgi?id=72387action=review . PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tip: Use 64-bit git binaries on Mac OS X
I've posted a patch to make webkit-patch warn users when they're on a 64-bit system with a 32-bit git: https://bugs.webkit.org/show_bug.cgi?id=50715 4 seconds on every git status is huge. webkit-patch upload has to run at least 3 git status commands (due to expecting files to change on disk during operation), so this means a savings of 12 seconds on your machine! -eric On Tue, Dec 7, 2010 at 4:04 PM, Mihai Parparita mih...@chromium.org wrote: After complaining to a Linux-using friend for the n-th time that git status was much slower on my Snow Leopard machine than on his Linux box, I decided to look into why this is. As it turns out, most people get git binaries from http://code.google.com/p/git-osx-installer/, which are 32-bit. Switching to 64-bit binaries made git status go from 6.58s to 2.50s (mainly because this does fewer mmaps). You can download a 64-bit binary installer from https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg , or you can build it yourself (more details at http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html ). Mihai ___ 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] Tip: Use 64-bit git binaries on Mac OS X
FYI, my git status runs on my Mac Book Pro were an average of 9.2 seconds (git version 1.7.1, git-osx-installer) before installing Mihai's 64bit build (git version 1.7.3.3), and were 6.0 seconds after. -eric On Wed, Dec 8, 2010 at 2:20 PM, Eric Seidel e...@webkit.org wrote: I've posted a patch to make webkit-patch warn users when they're on a 64-bit system with a 32-bit git: https://bugs.webkit.org/show_bug.cgi?id=50715 4 seconds on every git status is huge. webkit-patch upload has to run at least 3 git status commands (due to expecting files to change on disk during operation), so this means a savings of 12 seconds on your machine! -eric On Tue, Dec 7, 2010 at 4:04 PM, Mihai Parparita mih...@chromium.orgwrote: After complaining to a Linux-using friend for the n-th time that git status was much slower on my Snow Leopard machine than on his Linux box, I decided to look into why this is. As it turns out, most people get git binaries from http://code.google.com/p/git-osx-installer/, which are 32-bit. Switching to 64-bit binaries made git status go from 6.58s to 2.50s (mainly because this does fewer mmaps). You can download a 64-bit binary installer from https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg , or you can build it yourself (more details at http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html ). Mihai ___ 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] Pixel tests and displaying text
On Dec 8, 2010, at 1:02 PM, Peter Kasting wrote: On Wed, Dec 8, 2010 at 12:57 PM, Darin Adler da...@apple.com wrote: I’m worried a bit, though, that if we can’t use any text in them at all, the tests are then not at all self explanatory. You have to be an expert on the test to understand what it’s testing and what success and failure look like. I think for tests where we're worried that's the case, we should (for now) just go ahead and continue using text and having separate baselines. The per-test cost is relatively low and the number of tests that fall into this bucket is hopefully small? All tests benefit from being obviously self-describing. I've had to debug failing tests that didn't describe what they were testing in words, and it's pretty hard a lot of the time to tell what is even supposed to be happening. Maybe we can come up with a new form of test that puts the explanation of the test somewhere that will not be dumped and the test in a frame, and have the pixel tests dump only the frame. That would also work. I like Darin's idea. Perhaps the dumpAsPixels call could take a frame argument. It's really handy if tests can be self-describing in the browser. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel tests and displaying text
On Dec 8, 2010, at 2:03 PM, Darin Adler wrote: On Dec 8, 2010, at 1:23 PM, Simon Fraser wrote: On Dec 8, 2010, at 12:57 PM, Darin Adler wrote: On Dec 8, 2010, at 12:13 PM, Peter Kasting wrote: We could greatly decrease the number of these baselines by following a simple rule: don't display text unless you need to. Seems like a good idea. I’m worried a bit, though, that if we can’t use any text in them at all, the tests are then not at all self explanatory. You have to be an expert on the test to understand what it’s testing and what success and failure look like. Do HTML comments fulfill this? Peter, Simon, You both have convinced me that HTML comments could be fine for explaining what a test is testing. Maybe we could come up with a format that makes it likely we’ll spot those comments. The success vs. failure aspects can probably be addressed by the “see no red” and other such things. Maybe we could come up with a way to print the explanation in the browser only, and not in DumpRenderTree. A simple convention could be: if (!window.layoutTestController) document.write(Explanation of what the test is testing goes here.); This is slightly more convenient than an HTML comment when you open a test in the browser to see what's going on. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tip: Use 64-bit git binaries on Mac OS X
Mark Rowe pointed out to me over IRC that the real problem is we're blowing out the vnode cache. Even on an 8GB machine, the default cache is too small for all of WebKit to fit in it. On my 4GB machine (and on Mark's 8GB) we tried incrementing the cache to 384000 (the 4GB default is 64512 and the 8GB default is 128000). My git status times dropped again by over 50% to 2.6 seconds! (still an eternity compared to a linux machine of course...) If you'd like to play around with this, you can set your vnode cache limit with: sudo sysctl -w kern.maxvnodes=384000 You can read it with: sysctl kern.maxvnodes You can test to see if the cache is large enough by trying: git status; time git status the second one should be very fast if your cache is large enough. I don't know what the exact right trade-off is. I believe the vnode cache uses wired memory (which is a limited resource!). As far as I can tell you can't decrease the cache max w/o rebooting. sysctl will set it, but setting it to a smaller number seems to have not effect. I don't know how to make the setting last across reboots. Mark mentioned that putting the setting in /etc/sysctl.conf should work, but that at least for his machine that didn't seem to have any effect for this particular setting. That's what I know. -eric On Wed, Dec 8, 2010 at 3:02 PM, Eric Seidel e...@webkit.org wrote: FYI, my git status runs on my Mac Book Pro were an average of 9.2 seconds (git version 1.7.1, git-osx-installer) before installing Mihai's 64bit build (git version 1.7.3.3), and were 6.0 seconds after. -eric On Wed, Dec 8, 2010 at 2:20 PM, Eric Seidel e...@webkit.org wrote: I've posted a patch to make webkit-patch warn users when they're on a 64-bit system with a 32-bit git: https://bugs.webkit.org/show_bug.cgi?id=50715 4 seconds on every git status is huge. webkit-patch upload has to run at least 3 git status commands (due to expecting files to change on disk during operation), so this means a savings of 12 seconds on your machine! -eric On Tue, Dec 7, 2010 at 4:04 PM, Mihai Parparita mih...@chromium.org wrote: After complaining to a Linux-using friend for the n-th time that git status was much slower on my Snow Leopard machine than on his Linux box, I decided to look into why this is. As it turns out, most people get git binaries from http://code.google.com/p/git-osx-installer/, which are 32-bit. Switching to 64-bit binaries made git status go from 6.58s to 2.50s (mainly because this does fewer mmaps). You can download a 64-bit binary installer from https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg, or you can build it yourself (more details at http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html). Mihai ___ 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] We released Firebug 1.6.0 with console.table(), time for Web Inspector?
We released Firebug 1.6.0 with console.table(), might it now be time for Web Inspector to implement it? Steven Roussey ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] We released Firebug 1.6.0 with console.table(), time for Web Inspector?
Oops, I didn't mean for that to be so short! This is probably my first time posting to this list (ok, now second), so let me know what I might be doing correctly, or incorrectly. I want to contribute to webkit and web inspector in the future, so hopefully this will be a learning exercise. Though in this particular case, the code is not mine. The original contributor to the Web Inspector bug got Firebug people interested and it got deployed with us first. I had thought that with Chrome's fast turn-arounds, that it was already there, but I was wrong. Seems the contributor gave up: https://bugs.webkit.org/show_bug.cgi?id=38664#c52 I think the idea that the API needs wider review on the webkit mailing list is now moot. What would I need to do to to move this forward? Remember, this is my first time! Thanks! -steve-- Steven Roussey On Wed, Dec 8, 2010 at 3:45 PM, Steven Roussey srous...@gmail.com wrote: We released Firebug 1.6.0 with console.table(), might it now be time for Web Inspector to implement it? Steven Roussey ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel tests and displaying text
On Wed, Dec 8, 2010 at 3:24 PM, Maciej Stachowiak m...@apple.com wrote: Maybe we could come up with a way to print the explanation in the browser only, and not in DumpRenderTree. A simple convention could be: if (!window.layoutTestController) document.write(Explanation of what the test is testing goes here.); This is slightly more convenient than an HTML comment when you open a test in the browser to see what's going on. At least when I've been tracking down test failures, the most convenient thing is the pixel output itself, which I have in both raw and diff form in the various Chromium dashboards. At the point when I need to manually open the test in some fashion, text displayed in the document versus text appearing in the source code are about equally accessible -- if anything, the latter is better for me (opening text editors is easy). Really, I suspect that all that really matters is that we establish some convention, so that I don't have to try opening the test outside the testing environment, reading the source, etc., all in hope of an explanation that I'm not sure exists. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] We released Firebug 1.6.0 with console.table(), time for Web Inspector?
On Wed, Dec 8, 2010 at 4:06 PM, Steven Roussey srous...@gmail.com wrote: Oops, I didn't mean for that to be so short! This is probably my first time posting to this list (ok, now second), so let me know what I might be doing correctly, or incorrectly. I want to contribute to webkit and web inspector in the future, so hopefully this will be a learning exercise. Though in this particular case, the code is not mine. The original contributor to the Web Inspector bug got Firebug people interested and it got deployed with us first. I had thought that with Chrome's fast turn-arounds, that it was already there, but I was wrong. Seems the contributor gave up: https://bugs.webkit.org/show_bug.cgi?id=38664#c52 I think the idea that the API needs wider review on the webkit mailing list is now moot. What would I need to do to to move this forward? Remember, this is my first time! Hi Steve, I would suggest manually finding qualified reviewers for the patch, and asking them via email whether they can look at it. A quick search through WebCore/ChangeLog for inspector/ turns up a couple of reviewers of earlier patches. Also, a recent addition to the webkit-patch script is webkit-patch upload --suggest-reviewers which automates this process. -Ken Thanks! -steve-- Steven Roussey On Wed, Dec 8, 2010 at 3:45 PM, Steven Roussey srous...@gmail.com wrote: We released Firebug 1.6.0 with console.table(), might it now be time for Web Inspector to implement it? Steven Roussey ___ 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] Canvas Issues: Ping
There are two canvas issues I'd like to see resolved ASAP: 1. Failing Philip's Canvas test: toDataURL.jpeg.alpha https://bugs.webkit.org/show_bug.cgi?id=40147 Related: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11431 http://trac.webkit.org/changeset/73173 This is a tricky issue, as mentioned by the comments in trac. No response from Mozilla: does apple have an opinion on this? IE9 seems to follow the spec. 2. Fallback content in canvas element not focusable https://bugs.webkit.org/show_bug.cgi?id=50126 An [input] tag inside of a canvas element: [canvas][input /][/canvas] should be able to receive .focus events and tabindex navigation. This is currently working in IE9, and likely works FF4. Thought I'd send up a flare. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] We released Firebug 1.6.0 with console.table(), time for Web Inspector?
Hi Ken! I would suggest manually finding qualified reviewers for the patch, I think it stalled since it was reviewed, but it needed some sort of API discussion on this list. At this point, such discussion is too late and compatibility with Firebug is more important. That said, while the semantics of the API are not really up for discussion anymore, the decision on whether to include it or not is still valid. So from what I can tell (please correct me!), is that it can't go forward without review in this list, as said by web inspector reviewers. So there is catch-22 here if everyone points at everyone else. :) Admittedly, I did promise to gather some data to standardize the console at the W3C, and haven't gotten around to it. Is that a preferred way forward? Anyway, it seemed like getting permission from people on the list was a stumbling block, so I thought I would start here, and when settled, return to the bug. I say return, but I wasn't a participant in it. But you get the idea! I will investigate webkit-patch and the --suggest-reviewers option while I wait. Thanks for the pointers, it will keep me busy! -steve-- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] We released Firebug 1.6.0 with console.table(), time for Web Inspector?
On Wed, Dec 8, 2010 at 4:56 PM, Steven Roussey srous...@gmail.com wrote: Hi Ken! I would suggest manually finding qualified reviewers for the patch, I think it stalled since it was reviewed, but it needed some sort of API discussion on this list. At this point, such discussion is too late and compatibility with Firebug is more important. That said, while the semantics of the API are not really up for discussion anymore, the decision on whether to include it or not is still valid. So from what I can tell (please correct me!), is that it can't go forward without review in this list, as said by web inspector reviewers. So there is catch-22 here if everyone points at everyone else. :) Admittedly, I did promise to gather some data to standardize the console at the W3C, and haven't gotten around to it. Is that a preferred way forward? Don't take my advice as authoritative, but if Firebug is already implementing it and developers or utility libraries are already using it for debugging, I think getting this change into WebKit in parallel to standardizing the new API with the W3C would be fine. Otherwise the implementation is going to stall for a long time. Again, I think finding a couple of reviewers experienced with the inspector code, and asking them privately if they can review it, is the way to go. (I think they're already CC'd on the report.) Or post an update to the bug asking the CC'd individuals for review again. -Ken Anyway, it seemed like getting permission from people on the list was a stumbling block, so I thought I would start here, and when settled, return to the bug. I say return, but I wasn't a participant in it. But you get the idea! I will investigate webkit-patch and the --suggest-reviewers option while I wait. Thanks for the pointers, it will keep me busy! -steve-- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Looking for information on how to access certain functionality with python.
Hello, I am looking for information on how to access a few browser features with python. I would like to control the browser session (in paticular, cookies, proxies, and user-agent), get access to downloaded files (css/js/images/flash), and have full DOM control. I found pywebkitgtk, which seems to be moving toward using gobject but from what I understand gobject still lacks a lot of the functionality I am looking for (and I was not able to get webkit to compile with support for it). I also experimented with python-webkit (the pywebkitgtk branch found here: http://www.gnu.org/software/pythonwebkit/). It had all of the DOM functionality I was looking for but no control over the browser session and no access to downloaded files. First of all, do any of the current webkit branches have this functionality easily accessible already? If not, what files do I need to expose to python to access this functionality? I was told that the session is controlled by whatever the webkit branch chose to handle connections (GTK: libcurl), but how do I control that from webkit? Does webkit pass connection settings along, and receive full headers (including cookies) back or is that all done outside of webkit code? From what I read everything downloaded is represented as a WebResource object? How can I gain access to these and get information from them from a web-frame. Is there a get_web_resources() function or something? If I am barking up the wrong tree and need to look somewhere else entirely please let me know. Regards, Hari ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Looking for information on how to access certain functionality with python.
This is not a list for getting help using WebKit. It’s for discussion development of WebKit. This page http://webkit.org/contact.html mentions other lists that might be appropriate for a question like this. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rebaselining render tree dumps
Am 08.12.2010 um 00:55 schrieb Ryosuke Niwa: Hi all, Since this would require a lot of rebaselines anyways, can we also add some enhancements to DRT? I propose to an option to dump as text with images. In many editing tests, we don't need render tree dumps because we care more about how DOM looks like before and after editing operations. However, we also need to verify that selection and caret are rendered properly on multiple occasions, and the only way to do this right now is to use a pixel test. But even then, dumping render tree is not helpful and almost harmful because it doesn't tell us how selection / caret are rendered (this can never be tested by comparing text) and hides some important information about DOM and makes us rebaseline tests whenever there's slight change (that we don't care) in the render tree. James (jamesr) and I talked about this on IRC, and he said this feature will also be useful for repaint tests and canvas tests. We can implement this feature by adding dumpAsTextWithImage to layoutTestController, which forces DRT to dump as text but also outputs the png image. For repainting tests, we can also add dumpRepaintRects to output more information about painting. Hi Ryosuke, this feature is already available. I've implemented it for the svg/ dynamic-updates test, DRT hooks are available. dumpAsText() takes an optional boolean parameter that toggles this. // svg/dynamic-updates tests set enablePixelTesting=true, as we want to dump text + pixel results if (window.layoutTestController) layoutTestController.dumpAsText(true /* enablePixelTesting */); That will give you a dumpAsText result + a pixel test result. Hope that helps.. Cheers, Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
