[chromium-dev] WebKit roll status
Hi all, Just a note to let you know what's up with webkit rolls (or lack thereof) right now. We're at r51794 and have been for a while. Tip-of-tree webkit is at r51868. * All manner of svg tests are borked from some reason around r 51800, senorblanco is on that. * A couple of build breaks obscured things for a while, ajwong has resolved those already. I'm putting together a CL to roll deps to r51868 and update test expectations to expect the svg failures (as recommended by senorblanco). This may be a little bit of a bumpy ride. PS. Oh, and my car broke down this morning. Just my lucky day i guess :) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
For the curious, as of WebKit 51800, SVG Filters are enabled by default. In theory (since this code is cross-platform), this should just require us turning them on in Chrome, and rebaselining the affected tests (about 24 on Windows). In practice, however, some of the code behind #if ENABLE(SVG_FILTERS) on the V8 bindings side may have rotted, and need some attention. Also, there are also a huge number of additional tests are failing on Linux (481) for reasons unknown as yet. This issue is being tracked at http://code.google.com/p/chromium/issues/detail?id=29737 Stephen On Tue, Dec 8, 2009 at 3:23 PM, Michael Nordman micha...@chromium.orgwrote: Hi all, Just a note to let you know what's up with webkit rolls (or lack thereof) right now. We're at r51794 and have been for a while. Tip-of-tree webkit is at r51868. * All manner of svg tests are borked from some reason around r 51800, senorblanco is on that. * A couple of build breaks obscured things for a while, ajwong has resolved those already. I'm putting together a CL to roll deps to r51868 and update test expectations to expect the svg failures (as recommended by senorblanco). This may be a little bit of a bumpy ride. PS. Oh, and my car broke down this morning. Just my lucky day i guess :) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
I wonder if we should investigate and determine the cause of Linux failures before rolling. :DG On Tue, Dec 8, 2009 at 12:43 PM, Stephen White senorbla...@chromium.org wrote: For the curious, as of WebKit 51800, SVG Filters are enabled by default. In theory (since this code is cross-platform), this should just require us turning them on in Chrome, and rebaselining the affected tests (about 24 on Windows). In practice, however, some of the code behind #if ENABLE(SVG_FILTERS) on the V8 bindings side may have rotted, and need some attention. Also, there are also a huge number of additional tests are failing on Linux (481) for reasons unknown as yet. This issue is being tracked at http://code.google.com/p/chromium/issues/detail?id=29737 Stephen On Tue, Dec 8, 2009 at 3:23 PM, Michael Nordman micha...@chromium.org wrote: Hi all, Just a note to let you know what's up with webkit rolls (or lack thereof) right now. We're at r51794 and have been for a while. Tip-of-tree webkit is at r51868. * All manner of svg tests are borked from some reason around r 51800, senorblanco is on that. * A couple of build breaks obscured things for a while, ajwong has resolved those already. I'm putting together a CL to roll deps to r51868 and update test expectations to expect the svg failures (as recommended by senorblanco). This may be a little bit of a bumpy ride. PS. Oh, and my car broke down this morning. Just my lucky day i guess :) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
yikes 481 failures on linux... k... holding off rolling until we get a handle on the nature of the linux borkage On Tue, Dec 8, 2009 at 12:45 PM, Dimitri Glazkov dglaz...@google.comwrote: I wonder if we should investigate and determine the cause of Linux failures before rolling. :DG On Tue, Dec 8, 2009 at 12:43 PM, Stephen White senorbla...@chromium.org wrote: For the curious, as of WebKit 51800, SVG Filters are enabled by default. In theory (since this code is cross-platform), this should just require us turning them on in Chrome, and rebaselining the affected tests (about 24 on Windows). In practice, however, some of the code behind #if ENABLE(SVG_FILTERS) on the V8 bindings side may have rotted, and need some attention. Also, there are also a huge number of additional tests are failing on Linux (481) for reasons unknown as yet. This issue is being tracked at http://code.google.com/p/chromium/issues/detail?id=29737 Stephen On Tue, Dec 8, 2009 at 3:23 PM, Michael Nordman micha...@chromium.org wrote: Hi all, Just a note to let you know what's up with webkit rolls (or lack thereof) right now. We're at r51794 and have been for a while. Tip-of-tree webkit is at r51868. * All manner of svg tests are borked from some reason around r 51800, senorblanco is on that. * A couple of build breaks obscured things for a while, ajwong has resolved those already. I'm putting together a CL to roll deps to r51868 and update test expectations to expect the svg failures (as recommended by senorblanco). This may be a little bit of a bumpy ride. PS. Oh, and my car broke down this morning. Just my lucky day i guess :) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
On Tue, Dec 8, 2009 at 12:55 PM, Michael Nordman micha...@chromium.org wrote: yikes 481 failures on linux... k... holding off rolling until we get a handle on the nature of the linux borkage This is probably the result of Markus's first WebKit patch. It was LGTMed and he asked that it be landed and didn't think that it would break anything. However, it appears that he didn't know about the pixel tests! http://trac.webkit.org/changeset/51827 You might want to revert it for now, although it should be ok to rebaseline any pixel tests that changed. It's just a very minor change in the scrollbar colours. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
Ah... thank you for the ptr. On Tue, Dec 8, 2009 at 1:00 PM, Adam Langley a...@chromium.org wrote: On Tue, Dec 8, 2009 at 12:55 PM, Michael Nordman micha...@chromium.org wrote: yikes 481 failures on linux... k... holding off rolling until we get a handle on the nature of the linux borkage This is probably the result of Markus's first WebKit patch. It was LGTMed and he asked that it be landed and didn't think that it would break anything. However, it appears that he didn't know about the pixel tests! http://trac.webkit.org/changeset/51827 You might want to revert it for now, although it should be ok to rebaseline any pixel tests that changed. It's just a very minor change in the scrollbar colours. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
Oh, yes, that wouldn't be surprising :-/ There now is a new WebKit API for setting the scrollbar colors in Linux, and theWebKit change doesn't set the colors. That's waiting for the second half of the changelist which is pending in http://codereview.chromium.org/400027 Even after that pending changelist is going to be submitted, the pixel tests will probably fail, as the new code has slightly different pixel values than the old code. We could change that, but it would make the code much uglier. So, at this time, there are a couple of choices. Let me know, what you prefer: - fix the problem with the black scrollbars in testshell. This is easy. The WebKit change currently sets all colors to zero, unless somebody explicitly sets them to something else. We can pick different default values that will at least make the scrollbars visible. This would still require rebasing the pixel tests. And we have to make a decision on whether to apply this as an incremental change or whether to rollback the current WebKit change. It's gonna be a rely simple low-risk change. - add ugly backwards compatibility code that realizes the situation when colors for the scrollbars have never been set and that then falls back on using the exact same old pixel values. I am not in favor of this, but if the consensus is that that's what we should do, I'll change the code accordingly. Markus -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
- fix the problem with the black scrollbars in testshell. This is easy. The WebKit change currently sets all colors to zero, unless somebody explicitly sets them to something else. We can pick different default values that will at least make the scrollbars visible. This would still require rebasing the pixel tests. And we have to make a decision on whether to apply this as an incremental change or whether to rollback the current WebKit change. It's gonna be a rely simple low-risk change. Let's go with this. You'll have a chance all about the great rebaselining tool in the process. :) Michael will roll and add all the failures to expectations, creating a bug for you to rebaseline. :DG Markus On Tue, Dec 8, 2009 at 13:09, Dimitri Glazkov dglaz...@chromium.org wrote: Ouch. And all scrollbars in pixel tests are now black (see attached). Yeah, I think we should roll this one out. Welcome to the wonderful world of WebKit, Markus! :DG On Tue, Dec 8, 2009 at 12:59 PM, Adam Langley a...@google.com wrote: On Tue, Dec 8, 2009 at 12:55 PM, Michael Nordman micha...@chromium.org wrote: yikes 481 failures on linux... k... holding off rolling until we get a handle on the nature of the linux borkage This is probably the result of Markus's first WebKit patch. It was LGTMed and he asked that it be landed and didn't think that it would break anything. However, it appears that he didn't know about the pixel tests! http://trac.webkit.org/changeset/51827 You might want to revert it for now, although it should be ok to rebaseline any pixel tests that changed. It's just a very minor change in the scrollbar colours. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
Yes, It sounds like in all cases, there's going to be a big rebaseline-them-all-on-linux step at some point, the sooner the better. Given the nature of the problem (scrollbar drawing differences), lets roll and deal with the rebaselining seperately. But that should be done soonish, in the interim we'll the expected scrollbar drawing diffs could be masking real bugs. Gee.. lots of fun to put hundreds of expected failures in test_expecations for linux :) On Tue, Dec 8, 2009 at 1:30 PM, Adam Langley a...@google.com wrote: On Tue, Dec 8, 2009 at 1:27 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Let's go with this. You'll have a chance all about the great rebaselining tool in the process. :) Michael will roll and add all the failures to expectations, creating a bug for you to rebaseline. Ok. Markus is going to do a quick WK patch, before we roll, to set the defaults to something like the current values. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
http://codereview.chromium.org/400027/diff2/27001:30003/30013 On Tue, Dec 8, 2009 at 13:30, Adam Langley a...@google.com wrote: On Tue, Dec 8, 2009 at 1:27 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Let's go with this. You'll have a chance all about the great rebaselining tool in the process. :) Michael will roll and add all the failures to expectations, creating a bug for you to rebaseline. Ok. Markus is going to do a quick WK patch, before we roll, to set the defaults to something like the current values. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
