[webkit-dev] Marquee as overflow property's value
Dear WebKit team,
Could someone please elicit as to why marquee is added as one of the
overflow style property's value?
[See: RenderStyleConstants.h]
*enum EOverflow {
OVISIBLE, OHIDDEN, OSCROLL, OAUTO, OOVERLAY, OMARQUEE
};*
Because of this, while setting the style properties for a marquee element
with overflow property specified, the value for the overflow property is
overridden by that value (i.e. either hidden, scroll, visible or auto) and
is thus never set as marquee.
Thus in the current scenario, for a marquee element with overflow
specified, RenderMarquee is never created.
Thanks in advance.
Regards,
Arpita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] List of prefixed APIs in WebKit
While it'd require some archaeology, would it be useful to compile a list of formerly prefixed APIs which have graduated? -Tony On Sat, Apr 7, 2012 at 2:10 AM, Adam Barth aba...@webkit.org wrote: As you might be aware, there's been some amount of debate in the browser community recently about the use of vendor prefixes in the web platform. I'm sure many of you have opinions on this topic, but rather than triggering a long thread about this topic, I'd like to start by gathering some data about WebKit's current use of vendor prefixes. I've put together a list of all the vendor-prefixed APIs I could find in WebKit, at least for DOM interfaces: https://trac.webkit.org/wiki/PrefixedAPIs I'd like to try to understand the current status of these APIs on the standards track. If you happen to know which specifications contain these various APIs (and the standardization status of these specifications), would you be so kind as to add a link from the wiki to the specification? If there isn't a specification, please feel encouraged to note that on the wiki together with any information you're aware of about future plans for writing a specification. I'll do my best to fill in the gaps in a few days. Many thanks, Adam P.S., If you'd be willing to fill in the list of vendor-prefixed CSS properties, I'd appreciate that as well. ___ 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] Marquee as overflow property's value
I think it might be because marquee is non-compliant HTML.
To my knowledge, WebKit only supports marquee in a best-effort capacity for
compatibility with old pages. It is only reasonable to expect that, until (or
unless, since the module's been in CR since 2008) the CSS Marquees module
matures, support (especially interactions with other properties) would be
spotty.
I recommend not using non-standard html elements. Step 1 of your course of
action should be to remove the marquee element from the page and re-examine why
you think you needed it. If you still have a use case for distracting,
scrolling text, consider using javascript to gain the control you require.
Or you could switch to the blink tag. That'd be hella fly.
Style,
Chris
From: webkit-dev-boun...@lists.webkit.org
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Arpita Bahuguna
Sent: Tuesday, April 10, 2012 6:27 AM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] Marquee as overflow property's value
Dear WebKit team,
Could someone please elicit as to why marquee is added as one of the overflow
style property's value?
[See: RenderStyleConstants.h]
enum EOverflow {
OVISIBLE, OHIDDEN, OSCROLL, OAUTO, OOVERLAY, OMARQUEE
};
Because of this, while setting the style properties for a marquee element with
overflow property specified, the value for the overflow property is overridden
by that value (i.e. either hidden, scroll, visible or auto) and is thus never
set as marquee.
Thus in the current scenario, for a marquee element with overflow specified,
RenderMarquee is never created.
Thanks in advance.
Regards,
Arpita
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] handling failing tests (test_expectations, Skipped files, etc.)
There is a significant practical problem to turn the tree red and work with someone to rebaseline the tests. It takes multiple hours for some bots to build and test a given patch. That means, at any moment, you will have maybe tens and in some cases hundreds of failing tests associated with some changelist that you need to track on the bots. You might have more failing tests associated with a different changelist, and so on. How do you propose to track which baselines have been computed by which bots for which changelists? In the past I have seen failing tests because baselines were checked in too soon and some bot had not generated new baselines. Things are even worse when a change goes in late in the day. How will the pending rebaselines be handed off to the new gardener? As the Chromium owner of tests that are frequently broken by third party contributors (they do their best to help us, but cannot generate all 15 or so Chromium expectations), I would much rather have a bug filed against me and a line in the expectations file. At least I then have visibility on what's happening and a chance to verify the results. In a recent pass to clean up expectations we found multiple cases where the wrong result had been committed because the person who did it failed to realize the result was wrong. While you might say fix the test to make it obvious, it is not obvious how to do that for all tests. Why not simply attach an owner and a resolution date to each expectation? The real problem right now is accountability and a way to remind people that they have left expectations hanging. Cheers, Stephen. On Mon, Apr 9, 2012 at 9:19 PM, Julien Chaffraix jchaffr...@webkit.orgwrote: If there's consensus in the mean time that it is better on balance to check in suppressions, perhaps we can figure out a better way to do that. Maybe (shudder) a second test_expectations file? Or maybe it would be better to actually check in suppressions marked as REBASELINE (or something like that)? That sounds quirky as it involves maintaining 2 sets of files. From my perspective, saying that we should discard the EWS result and allow changes to get in WebKit trunk, knowing they will turn the bots red, is a bad proposal regardless of how you justify it. In the small delta where the bots are red, you can bet people will miss something else that breaks. As Ryosuke points out, practically we're already in that situation - from what I can tell, the tree is red virtually all of the time, at least during US/Pacific working hours. It's not clear to me if the EWS has made this better or worse, but perhaps others have noticed a difference. That said, I doubt I like red trees any more than you do :) I wasn't talking about the tree's status quo here as it shouldn't impact the discussion. Just because the tree is red, doesn't mean it's the right thing (tm) to just drop the towel and make it more red (even if we seem to agree on the badness of that :)). To add some thoughts here, saying that the tree is red covers several states (failing tests, not building...) and IMHO the EWS has at least helped on the building side. As far as the tests goes, a lot of platform differences are unfortunately uncovered on the bots. Thanks, Julien ___ 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] handling failing tests (test_expectations, Skipped files, etc.)
On Tue, Apr 10, 2012 at 6:10 AM, Stephen Chenney schen...@chromium.orgwrote: There is a significant practical problem to turn the tree red and work with someone to rebaseline the tests. It takes multiple hours for some bots to build and test a given patch. That means, at any moment, you will have maybe tens and in some cases hundreds of failing tests associated with some changelist that you need to track on the bots. You might have more failing tests associated with a different changelist, and so on. But you have to do this for non-Chromium ports anyway because they don't use test_expectations.txt and skipping the tests won't help you generate new baseline. In my opinion, we should not further diverge from the way things are done in other ports. How do you propose to track which baselines have been computed by which bots for which changelists? In the past I have seen failing tests because baselines were checked in too soon and some bot had not generated new baselines. Things are even worse when a change goes in late in the day. How will the pending rebaselines be handed off to the new gardener? You have to stick around as long as it takes to rebaseline or notify relevant port contributors after your patch lands: http://www.webkit.org/coding/contributing.html clearly says Keeping the tree green In either case, your responsibility for the patch does not end with the patch landing in the tree. There may be regressions from your change or additional feedback from reviewers after the patch has landed. You can watch the tree at build.webkit.org to make sure your patch builds and passes tests on all platforms. It is your responsibility to be available should regressions arise and to respond to additional feedback that happens after a check-in. Changes should succeed on all platforms, but it can be difficult to test on every platform WebKit supports. Be certain that your change does not introduce new test failures on the high-traffic Mac or Windows ports by comparing the list of failing tests before and after your change. Your change must at least compile on all platforms. As the Chromium owner of tests that are frequently broken by third party contributors (they do their best to help us, but cannot generate all 15 or so Chromium expectations), I would much rather have a bug filed against me and a line in the expectations file. At least I then have visibility on what's happening and a chance to verify the results. In a recent pass to clean up expectations we found multiple cases where the wrong result had been committed because the person who did it failed to realize the result was wrong. While you might say fix the test to make it obvious, it is not obvious how to do that for all tests. This is an orthogonal issue to adding failing expectations prior to landing your patch. It's about how rebaseline should be done. I agree that rebaselining a test without understanding what the test intends to test or the correct output is bad. But let's not mangle such a discussion into this thread. Why not simply attach an owner and a resolution date to each expectation? The real problem right now is accountability and a way to remind people that they have left expectations hanging. That's what WebKit bugs are for. Ossy frequently files a bug and cc'es the patch author when a new test is added or a test starts failing and he doesn't know whether new result is correct or not. He also either skips the test or rebaseline the test as needed. He also reverts patches when the patch clearly introduced serious regressions (e.g. crashes on hundreds of tests). - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] handling failing tests (test_expectations, Skipped files, etc.)
On Tue, Apr 10, 2012 at 11:42 AM, Stephen Chenney schen...@chromium.orgwrote: On Tue, Apr 10, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Apr 10, 2012 at 6:10 AM, Stephen Chenney schen...@chromium.orgwrote: There is a significant practical problem to turn the tree red and work with someone to rebaseline the tests. It takes multiple hours for some bots to build and test a given patch. That means, at any moment, you will have maybe tens and in some cases hundreds of failing tests associated with some changelist that you need to track on the bots. You might have more failing tests associated with a different changelist, and so on. But you have to do this for non-Chromium ports anyway because they don't use test_expectations.txt and skipping the tests won't help you generate new baseline. In my opinion, we should not further diverge from the way things are done in other ports. How long on average does it take a builder to get through a change on another port? Right now the Chromium Mac 10.5 and 10.6 dbg builds are processing a patch from about 3 hours ago. About 20 patches have gone in since then. For the Mac 10.5 tree to ever be green would require there being no changes at all requiring new baselines for a 3 hour window. Just because other teams do it some way does not mean that Chromium, with it's greater number of bots and platforms, should do it the same way. Yes, it does mean that we should do it the same way. What if non-Chromium ports started imposing arbitrary processes like this on the rest of us? It'll be a total chaos, and nobody would understand the right thing to do for all ports. We are discussing a process here, not code, and in my mind the goal is to have the tree be as green as possible with all failures tracked with a minimal expectations file and as little engineer time as possible. That's not our project goal. We have continuous builds and regression tests to prevent regressions to improve the stability, not to keep bots green. Please review http://www.webkit.org/projects/goals.html Just look at how often the non-chromium mac and win builds are red. In particular, changes submitted via the commit queue take an indeterminate amount of time to go in, anything from an hour to several hours. Patch authors do not necessarily even have control over when the CQ+ is given. That's why I don't use commit queue when I know my patch requires platform-dependent rebaselines. Even when manually committing, if it takes 3 hours to create baselines then no patches go in in the afternoon. What if the bots are down or misbehaving? We need to promptly fix those bots. I would also point out the waste of resources when every contributor needs to track every failure around commit time in order to know when their own changes cause failures, and then track the bots to know when they are free to go home. But that's clearly stated in the contribution guide line. Why not simply attach an owner and a resolution date to each expectation? The real problem right now is accountability and a way to remind people that they have left expectations hanging. That's what WebKit bugs are for. Ossy frequently files a bug and cc'es the patch author when a new test is added or a test starts failing and he doesn't know whether new result is correct or not. He also either skips the test or rebaseline the test as needed. He also reverts patches when the patch clearly introduced serious regressions (e.g. crashes on hundreds of tests). Yes, Ossy does an excellent job of gardening. Unfortunately, on Chrome we have tens if not hundreds of gardeners and, as this thread has revealed, no clear agreement on the best way to garden. That IS the problem. We have too many in-experiented gardeners that don't understand the WebKit culture or the WebKit process. I strongly believe that keeping the tree green is more important than having a clean expectations file. I disagree. You're effectively just disabling the test temporarily. Finally, there is no pain free way to do this. The question is how to distribute the pain. Right now each gardening is using a process that distributes pain in their preferred way. From a community standpoint it would be nice if the Chromium team could come up with something consistent. The process Chromium port uses should be consistent with non-Chromium ports. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] handling failing tests (test_expectations, Skipped files, etc.)
I don't think we can come up with a hard and fast rule given current tooling. In a theoretical future world in which it's easy to get expected results off the EWS bots (or some other infrastructure), it would be reasonable to expect people to incorporate the correct expected results for any EWS-having ports before committing the patch. I expect we'd all agree that would be better than turning the bots red or adding to test_expectations.txt/Skipped files. In the current world, it's a judgement call. If I expect a patch to need a lot of platform-specific baselines, I'll make sure to commit it at a time when I have hours to spare to cleanup any failures or, if I can't stick around for the bots to cycle, I'll add it to test_expectations.txt appropriately. Both approaches have nasty tradeoffs. It is probably worth writing up a wiki page outlining these two options and explaining why you might do one or the other for people new to the project, but I don't see benefit in trying to pick a hard rule that everyone must follow. Ojan On Tue, Apr 10, 2012 at 11:58 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Apr 10, 2012 at 11:42 AM, Stephen Chenney schen...@chromium.orgwrote: On Tue, Apr 10, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Apr 10, 2012 at 6:10 AM, Stephen Chenney schen...@chromium.orgwrote: There is a significant practical problem to turn the tree red and work with someone to rebaseline the tests. It takes multiple hours for some bots to build and test a given patch. That means, at any moment, you will have maybe tens and in some cases hundreds of failing tests associated with some changelist that you need to track on the bots. You might have more failing tests associated with a different changelist, and so on. But you have to do this for non-Chromium ports anyway because they don't use test_expectations.txt and skipping the tests won't help you generate new baseline. In my opinion, we should not further diverge from the way things are done in other ports. How long on average does it take a builder to get through a change on another port? Right now the Chromium Mac 10.5 and 10.6 dbg builds are processing a patch from about 3 hours ago. About 20 patches have gone in since then. For the Mac 10.5 tree to ever be green would require there being no changes at all requiring new baselines for a 3 hour window. Just because other teams do it some way does not mean that Chromium, with it's greater number of bots and platforms, should do it the same way. Yes, it does mean that we should do it the same way. What if non-Chromium ports started imposing arbitrary processes like this on the rest of us? It'll be a total chaos, and nobody would understand the right thing to do for all ports. We are discussing a process here, not code, and in my mind the goal is to have the tree be as green as possible with all failures tracked with a minimal expectations file and as little engineer time as possible. That's not our project goal. We have continuous builds and regression tests to prevent regressions to improve the stability, not to keep bots green. Please review http://www.webkit.org/projects/goals.html Just look at how often the non-chromium mac and win builds are red. In particular, changes submitted via the commit queue take an indeterminate amount of time to go in, anything from an hour to several hours. Patch authors do not necessarily even have control over when the CQ+ is given. That's why I don't use commit queue when I know my patch requires platform-dependent rebaselines. Even when manually committing, if it takes 3 hours to create baselines then no patches go in in the afternoon. What if the bots are down or misbehaving? We need to promptly fix those bots. I would also point out the waste of resources when every contributor needs to track every failure around commit time in order to know when their own changes cause failures, and then track the bots to know when they are free to go home. But that's clearly stated in the contribution guide line. Why not simply attach an owner and a resolution date to each expectation? The real problem right now is accountability and a way to remind people that they have left expectations hanging. That's what WebKit bugs are for. Ossy frequently files a bug and cc'es the patch author when a new test is added or a test starts failing and he doesn't know whether new result is correct or not. He also either skips the test or rebaseline the test as needed. He also reverts patches when the patch clearly introduced serious regressions (e.g. crashes on hundreds of tests). Yes, Ossy does an excellent job of gardening. Unfortunately, on Chrome we have tens if not hundreds of gardeners and, as this thread has revealed, no clear agreement on the best way to garden. That IS the problem. We have too many in-experiented gardeners that don't understand the WebKit culture or the
Re: [webkit-dev] handling failing tests (test_expectations, Skipped files, etc.)
On Tue, Apr 10, 2012 at 12:29 PM, Ojan Vafai o...@chromium.org wrote: I don't think we can come up with a hard and fast rule given current tooling. In a theoretical future world in which it's easy to get expected results off the EWS bots (or some other infrastructure), it would be reasonable to expect people to incorporate the correct expected results for any EWS-having ports before committing the patch. I expect we'd all agree that would be better than turning the bots red or adding to test_expectations.txt/Skipped files. In the current world, it's a judgement call. If I expect a patch to need a lot of platform-specific baselines, I'll make sure to commit it at a time when I have hours to spare to cleanup any failures or, if I can't stick around for the bots to cycle, I'll add it to test_expectations.txt appropriately. Both approaches have nasty tradeoffs. It is probably worth writing up a wiki page outlining these two options and explaining why you might do one or the other for people new to the project, but I don't see benefit in trying to pick a hard rule that everyone must follow. I agree. Both approaches have pros and cons. Will be good to document on wiki as you say. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] handling failing tests (test_expectations, Skipped files, etc.)
I agree with Ojan. It's clear that there are arguments for both approaches and my initial note did not address all the situations that come up. I will write up something further and put it on the wiki. I will also continue mulling over what sorts of changes to the tools we could do in the short term to make things better. -- Dirk On Tue, Apr 10, 2012 at 12:29 PM, Ojan Vafai o...@chromium.org wrote: I don't think we can come up with a hard and fast rule given current tooling. In a theoretical future world in which it's easy to get expected results off the EWS bots (or some other infrastructure), it would be reasonable to expect people to incorporate the correct expected results for any EWS-having ports before committing the patch. I expect we'd all agree that would be better than turning the bots red or adding to test_expectations.txt/Skipped files. In the current world, it's a judgement call. If I expect a patch to need a lot of platform-specific baselines, I'll make sure to commit it at a time when I have hours to spare to cleanup any failures or, if I can't stick around for the bots to cycle, I'll add it to test_expectations.txt appropriately. Both approaches have nasty tradeoffs. It is probably worth writing up a wiki page outlining these two options and explaining why you might do one or the other for people new to the project, but I don't see benefit in trying to pick a hard rule that everyone must follow. Ojan On Tue, Apr 10, 2012 at 11:58 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Apr 10, 2012 at 11:42 AM, Stephen Chenney schen...@chromium.org wrote: On Tue, Apr 10, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Apr 10, 2012 at 6:10 AM, Stephen Chenney schen...@chromium.org wrote: There is a significant practical problem to turn the tree red and work with someone to rebaseline the tests. It takes multiple hours for some bots to build and test a given patch. That means, at any moment, you will have maybe tens and in some cases hundreds of failing tests associated with some changelist that you need to track on the bots. You might have more failing tests associated with a different changelist, and so on. But you have to do this for non-Chromium ports anyway because they don't use test_expectations.txt and skipping the tests won't help you generate new baseline. In my opinion, we should not further diverge from the way things are done in other ports. How long on average does it take a builder to get through a change on another port? Right now the Chromium Mac 10.5 and 10.6 dbg builds are processing a patch from about 3 hours ago. About 20 patches have gone in since then. For the Mac 10.5 tree to ever be green would require there being no changes at all requiring new baselines for a 3 hour window. Just because other teams do it some way does not mean that Chromium, with it's greater number of bots and platforms, should do it the same way. Yes, it does mean that we should do it the same way. What if non-Chromium ports started imposing arbitrary processes like this on the rest of us? It'll be a total chaos, and nobody would understand the right thing to do for all ports. We are discussing a process here, not code, and in my mind the goal is to have the tree be as green as possible with all failures tracked with a minimal expectations file and as little engineer time as possible. That's not our project goal. We have continuous builds and regression tests to prevent regressions to improve the stability, not to keep bots green. Please review http://www.webkit.org/projects/goals.html Just look at how often the non-chromium mac and win builds are red. In particular, changes submitted via the commit queue take an indeterminate amount of time to go in, anything from an hour to several hours. Patch authors do not necessarily even have control over when the CQ+ is given. That's why I don't use commit queue when I know my patch requires platform-dependent rebaselines. Even when manually committing, if it takes 3 hours to create baselines then no patches go in in the afternoon. What if the bots are down or misbehaving? We need to promptly fix those bots. I would also point out the waste of resources when every contributor needs to track every failure around commit time in order to know when their own changes cause failures, and then track the bots to know when they are free to go home. But that's clearly stated in the contribution guide line. Why not simply attach an owner and a resolution date to each expectation? The real problem right now is accountability and a way to remind people that they have left expectations hanging. That's what WebKit bugs are for. Ossy frequently files a bug and cc'es the patch author when a new test is added or a test starts failing and he doesn't know whether new result is correct or not. He also either skips the test or rebaseline the test as needed. He
[webkit-dev] Updating Media Source implementation
Hi WebKit, I just wanted to let people know that I plan on updating the Media Source implementation to the new 0.4 spechttp://html5-mediasource-api.googlecode.com/svn/tags/0.4/draft-spec/mediasource-draft-spec.html. The updated spec is intended to address a variety of concerns people had with the original 0.3 versionhttp://html5-mediasource-api.googlecode.com/svn/tags/0.3/draft-spec/mediasource-draft-spec.htmlthat got implemented. The update will be tracked as https://bugs.webkit.org/show_bug.cgi?id=83607. My plan is to first update the signatures of the existing methods and then follow up with the new methods as those features get implemented in the Chromium code. I believe this will provide the easiest migration path for people using the current implementation. The changes to WebKit should be relatively minor and primarily constitute changing existing method signatures and forwarding the new methods to the Chromium code. Aaron ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CSS 2.1 Test Suite
Hi there, We currently add tests from the CSS 2.1 suite as we fix them. They get added to the css2.1/20110323 folder in LayoutTests. Most of them don't have native reference tests yet in the suite so we (mostly I) have been adding homebrew reference results to the folder to avoid generating pixel results on all platforms. (see http://webkitmemes.tumblr.com/post/20788159625 !) These reference-results are easily removed once superseded but it might be cleaner just to move them, and the associated css tests, to a folder of their own in fast/css. That will allow css2.1/20110323 to be a clean import that the 8500 or so passing tests can be added to in 20 or 30 batches.[1] It will also make NRWT's reftests harness work with the suite. Does anyone object to that approach? The only thing going against it seems to be the principle that imported tests should be stored separately and together but this is more a case of using them to fix bugs and prevent future regressions while allowing a clean import of the CSS 2.1 test suite to take place in parallel. The problem this does not solve is how we avoid creating pixel results for tests that already pass but which do not have reftests of their own. Again I would be in favour of putting these in fast/css and keeping them there until reftests are added to the suite. This would allow us to prevent them regressing and come up with a reftest for them that can be submitted to the CSS test suite guys. The end result would be that we only directly import to the css2.1 folder those tests in the CSS test suite that have ref tests native to the suite. Thanks, Robert [1] I keep a local and relatively up to date copy of the passing and failing tests in separate folders in my checkout. Yes I know I should create bugs for them and get started on landing the passes. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS 2.1 Test Suite
As we have previous discussed following https://lists.webkit.org/pipermail/webkit-dev/2012-March/019782.html, it's hard to judge whether a given reference result is enough to cover everything the test intends to test. e.g. you can have a bug such that both the test and the reference file ends up having the same rendering result. - Ryosuke On Tue, Apr 10, 2012 at 2:26 PM, Robert Hogan li...@roberthogan.net wrote: Hi there, We currently add tests from the CSS 2.1 suite as we fix them. They get added to the css2.1/20110323 folder in LayoutTests. Most of them don't have native reference tests yet in the suite so we (mostly I) have been adding homebrew reference results to the folder to avoid generating pixel results on all platforms. (see http://webkitmemes.tumblr.com/post/20788159625 !) These reference-results are easily removed once superseded but it might be cleaner just to move them, and the associated css tests, to a folder of their own in fast/css. That will allow css2.1/20110323 to be a clean import that the 8500 or so passing tests can be added to in 20 or 30 batches.[1] It will also make NRWT's reftests harness work with the suite. Does anyone object to that approach? The only thing going against it seems to be the principle that imported tests should be stored separately and together but this is more a case of using them to fix bugs and prevent future regressions while allowing a clean import of the CSS 2.1 test suite to take place in parallel. The problem this does not solve is how we avoid creating pixel results for tests that already pass but which do not have reftests of their own. Again I would be in favour of putting these in fast/css and keeping them there until reftests are added to the suite. This would allow us to prevent them regressing and come up with a reftest for them that can be submitted to the CSS test suite guys. The end result would be that we only directly import to the css2.1 folder those tests in the CSS test suite that have ref tests native to the suite. Thanks, Robert [1] I keep a local and relatively up to date copy of the passing and failing tests in separate folders in my checkout. Yes I know I should create bugs for them and get started on landing the passes. ___ 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] webkitPostMessage
I'm trying to understand why we have both DOMWindow.webkitPostMessage
and DOMWindow.postMessage. I'm also trying to understand the
following comment in {JS,V8}DOMWindowCustom.cpp:
// This function has variable arguments and can be:
// Per current spec:
// postMessage(message, targetOrigin)
// postMessage(message, targetOrigin, {sequence of transferrables})
// Legacy non-standard implementations in webkit allowed:
// postMessage(message, {sequence of transferrables}, targetOrigin);
Specifically:
1) Can we remove webkitPostMessage? If we can't remove it now, is
there a time in the future at which we can remove it?
2) Can we adopt the behavior in the specification (and drop the
non-standard behavior)? If not, should we change the specification to
match our behavior?
Many thanks,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
