[chromium] Disable unprefixed css transitions until they're functional
Created attachment 180754 [details] Patch
Comment on attachment 180754 [details] Patch Attachment 180754 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/15543212 New failing tests: transitions/transitions-parsing.html
Created attachment 180759 [details] Patch
Comment on attachment 180759 [details] Patch OK. Why not just commit updated results?
Should this be tagged WebExposed? I don't really know what that keyword is used for.
The existing results will be correct once the define is back on, so I figured this causes less churn.(In reply to comment #4) > (From update of attachment 180759 [details]) > OK. Why not just commit updated results? The existing results will be correct once the define is back on, so I figured this causes less churn. > Should this be tagged WebExposed? I don't really know what that keyword is used for. I'm not sure. Can't hurt I guess, but since this restores the state pre-r138184, having that keyword on bug 93136 might make more sense :-)
Comment on attachment 180759 [details] Patch Rejecting attachment 180759 [details] from commit-queue. Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', u'--status-host=queues.webkit.org', ..." exit_code: 1 cwd: /mnt/git/webkit-commit-queue /mnt/git/webkit-commit-queue/Source/WebKit/chromium/ChangeLog neither lists a valid reviewer nor contains the string "Unreviewed" or "Rubber stamp" (case insensitive). Full output: http://queues.webkit.org/results/15527824
Created attachment 180766 [details] Patch for landing
Comment on attachment 180766 [details] Patch for landing Clearing flags on attachment: 180766 Committed r138488: <http://trac.webkit.org/changeset/138488>
All reviewed patches have been landed. Closing bug.
(In reply to comment #6) > > Should this be tagged WebExposed? I don't really know what that keyword is used for. > > I'm not sure. Can't hurt I guess, but since this restores the state pre-r138184, having that keyword on bug 93136 might make more sense :-) As this changes web observable behavior in Chromium (by disabling the unprefixed features), please include it. It doesn't matter whether it's been in a released Chrome version yet, that filtering will happen later. Thanks!
(In reply to comment #11) > (In reply to comment #6) > > > Should this be tagged WebExposed? I don't really know what that keyword is used for. > > > > I'm not sure. Can't hurt I guess, but since this restores the state pre-r138184, having that keyword on bug 93136 might make more sense :-) > > As this changes web observable behavior in Chromium (by disabling the unprefixed features), please include it. It doesn't matter whether it's been in a released Chrome version yet, that filtering will happen later. Thanks! Actually this change is slowing me down. https://bugs.webkit.org/attachment.cgi?id=183761&action=review Of course the test LayoutTests/fast/events/event-creation.html is failing on Chromium and I really don't want to skip that one as it contains lot of good tests. Also putting the tests in a separate file (so I could skip it in Chromium) seems weird as all events are in the file. Landing an special expected file for chromium seems like burden to me too. Chromium is the only port turning off this feature in trunk, all other ports turn that feature off in their release branch. In fact it's beneficial for me to get people testing the unprefixing. It's not per-say a new feature but it's nice for me to see on real use case, real websites how the prefixed/unprefixed code lives. Can Chromium turn that off later in the process? Thanks.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #6) > > > > Should this be tagged WebExposed? I don't really know what that keyword is used for. > > > > > > I'm not sure. Can't hurt I guess, but since this restores the state pre-r138184, having that keyword on bug 93136 might make more sense :-) > > > > As this changes web observable behavior in Chromium (by disabling the unprefixed features), please include it. It doesn't matter whether it's been in a released Chrome version yet, that filtering will happen later. Thanks! > > Actually this change is slowing me down. > > https://bugs.webkit.org/attachment.cgi?id=183761&action=review > > Of course the test LayoutTests/fast/events/event-creation.html is failing on Chromium and I really don't want to skip that one as it contains lot of good tests. Also putting the tests in a separate file (so I could skip it in Chromium) seems weird as all events are in the file. Landing an special expected file for chromium seems like burden to me too. As suggested earlier, you could add a pref that forces this on and set the pref in the tests. That's how transitional states are usually handled as far as I understand. We don't want to ship a binary with broken transitions.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #6) > > > > > Should this be tagged WebExposed? I don't really know what that keyword is used for. > > > > > > > > I'm not sure. Can't hurt I guess, but since this restores the state pre-r138184, having that keyword on bug 93136 might make more sense :-) > > > > > > As this changes web observable behavior in Chromium (by disabling the unprefixed features), please include it. It doesn't matter whether it's been in a released Chrome version yet, that filtering will happen later. Thanks! > > > > Actually this change is slowing me down. > > > > https://bugs.webkit.org/attachment.cgi?id=183761&action=review > > > > Of course the test LayoutTests/fast/events/event-creation.html is failing on Chromium and I really don't want to skip that one as it contains lot of good tests. Also putting the tests in a separate file (so I could skip it in Chromium) seems weird as all events are in the file. Landing an special expected file for chromium seems like burden to me too. > > As suggested earlier, you could add a pref that forces this on and set the pref in the tests. That's how transitional states are usually handled as far as I understand. > Ok I could do that. > We don't want to ship a binary with broken transitions. How this could happen if it's turn off in release branches?
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > (In reply to comment #11) > > > > (In reply to comment #6) > > > > > > Should this be tagged WebExposed? I don't really know what that keyword is used for. > > > > > > > > > > I'm not sure. Can't hurt I guess, but since this restores the state pre-r138184, having that keyword on bug 93136 might make more sense :-) > > > > > > > > As this changes web observable behavior in Chromium (by disabling the unprefixed features), please include it. It doesn't matter whether it's been in a released Chrome version yet, that filtering will happen later. Thanks! > > > > > > Actually this change is slowing me down. > > > > > > https://bugs.webkit.org/attachment.cgi?id=183761&action=review > > > > > > Of course the test LayoutTests/fast/events/event-creation.html is failing on Chromium and I really don't want to skip that one as it contains lot of good tests. Also putting the tests in a separate file (so I could skip it in Chromium) seems weird as all events are in the file. Landing an special expected file for chromium seems like burden to me too. > > > > As suggested earlier, you could add a pref that forces this on and set the pref in the tests. That's how transitional states are usually handled as far as I understand. > > > > Ok I could do that. > > > We don't want to ship a binary with broken transitions. > > How this could happen if it's turn off in release branches? And as we speak, it's getting really stable. I fixed the DOM events (except the patch I'm talking about) and the rest is pretty much aligning with the spec which is not "broken".
> > Ok I could do that. > > > > > We don't want to ship a binary with broken transitions. > > > How this could happen if it's turn off in release branches? Our dev channel gets branched from trunk and released every week. > And as we speak, it's getting really stable. I fixed the DOM events (except the patch I'm talking about) and the rest is pretty much aligning with the spec which is not "broken". Cool, once things mostly work we can turn it back on for chromium.