Rework SVG sizing

Rework SVG sizing

The basis of this change is to map explicit width and height
attributes to CSS properties, essentially promoting them to
presentation attributes. Note that implicit "100%" width and height
are not mapped.

This enables us to remove the concept of "percentage intrinsic size"
and rely on normal CSS rules to resolve percentage values.

The change has been approved by the SVG WG and the spec is being
updated. Minutes here:

http://www.w3.org/2014/04/07-svg-minutes.html#item03

Many of the -expected updates are caused by SVG size changes in turn
affecting where line breaks are inserted.

BUG=308992
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=171958

[ojan, 2014-03-19 20:17:48]

This looks great. We should absolutely do this. Do all the tests pass?

[davve, 2014-03-20 07:35:00]

On 2014/03/19 20:17:48, ojan wrote:
> This looks great. We should absolutely do this. Do all the tests pass?

No, not at all. Many tests rely on the current, unspecified behavior. Yesterday
I started rebasing this patch to latest trunk and updating the tests just to see
how much testsuite breakage there would be.

See discussions in crbug.com/308992 where Dirk raised some issues where he
thinks this (and what Firefox has implemented) gives sub-optimal results
(basically falling back to 300x150 too often).

[pdr., 2014-03-21 17:19:20]

On 2014/03/20 07:35:00, David Vest wrote:
> On 2014/03/19 20:17:48, ojan wrote:
> > This looks great. We should absolutely do this. Do all the tests pass?
> 
> No, not at all. Many tests rely on the current, unspecified behavior.
Yesterday
> I started rebasing this patch to latest trunk and updating the tests just to
see
> how much testsuite breakage there would be.
> 
> See discussions in crbug.com/308992 where Dirk raised some issues where he
> thinks this (and what Firefox has implemented) gives sub-optimal results
> (basically falling back to 300x150 too often).

Can you summarize the changes for authors here and how it will differ from
Mozilla's approach? The codechange here looks reasonable but I'd like to make
sure I understand the implications of it.

[davve, 2014-03-24 08:29:52]

> Can you summarize the changes for authors here and how it will
> differ from Mozilla's approach? The codechange here looks reasonable
> but I'd like to make sure I understand the implications of it.

Some of this will a rehash of bug 308992. I hope that's OK.

The work originates in the desire to remove the notion of percentage
intrinsic width/height from the blink code base. There are no such
thing in the spec(s) anymore.

See:

http://lists.w3.org/Archives/Public/www-style/2010Nov/0077.html

http://www.w3.org/TR/SVG11/coords.html#IntrinsicSizing states:

"Note: the ‘width’ and ‘height’ attributes are not the same as the CSS
width and height properties. Specifically, percentage values do not
provide an intrinsic width or height, and do not indicate a percentage
of the containing block. Rather, once the viewport is established,
they indicate the portion of the viewport that is actually covered by
image data."

When Mozilla made this change they discovered it wasn't web
compatible:

https://bugzilla.mozilla.org/show_bug.cgi?id=611099
https://bugzilla.mozilla.org/show_bug.cgi?id=668163

What they did to address this was to make width and height
presentation attributes. The SVG WG has an action point to address
this in the SVG spec but it hasn't happened yet:

https://www.w3.org/Graphics/SVG/WG/track/actions/3576

What's still somewhat of an open question is what to do with *default*
values for width and height on the SVG root element. The spec
currently states the default value to be 100%. Together with being
presentation attributes this would potentially mean that:

<div style="width:100px;height:100px">
  <svg xmlns="http://www.w3.org/2000/svg"></svg>
</div>

would be equivalent to:

<div style="width:100px;height:100px">
  <svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%"></svg>
</div>

in turn equivalent to:

<div style="width:100px;height:100px">
  <svg xmlns="http://www.w3.org/2000/svg" style="width: 100%; height:
100%"></svg>
</div>

which unambiguously gives an 100x100 SVG image.

But this is not what Mozilla did. They think (and I agree) that
mapping default 100% values for width and height leads to confusing
results!

When an SVG image has intrinsic ratio (through the viewBox attribute),
the intrinsic ratio would be *ignored* when the SVG is inside a fixed
height container but *honored* when they're in an auto height
container.

Let's modify the example above with a viewBox attribute:

<div style="width:100px;height:100px">
  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10"></svg>
</div>

which with default value mapping would be equivalent to:

<div style="width:100px;height:100px">
  <svg xmlns="http://www.w3.org/2000/svg" style="width: 100% height: 100%"
viewBox="0 0 20 10"></svg>
</div>

The image would still be 100x100 even though 100x50 would be the
reasonable size. *Especially* when you place more content in the same
container:

<div style="width:100px;height:100px">
  <!-- Imagine other content -->
  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 10"></svg>
  <!-- Imagine other content -->
</div>

Having the SVG 100x100 there is ... unfortunate and likely not what a
user wants or expects. Not mapping default width and height to style
gives much more predictable and useful results!

To sum up, I'd like the corresponding change to be made to Blink to
see if it's compatible with the web we're seeing. I'm not, at this
stage, planned to differ from what Firefox does but unexpected things
may turn up along the way.

[davve, 2014-03-24 10:07:22]

> Let's modify the example above with a viewBox attribute:
> 
> <div style="width:100px;height:100px">
>   <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10"></svg>
> </div>

Typo: Should be viewBox="0 0 20 10"

[pdr., 2014-04-15 02:46:10]

I saw this was recently updated :) Ready for a review yet?

I noticed there are some changes in calculateImageIntrinsicDimensions and
friends that seem to apply to more than just SVG images. Do those codepaths
affect other images, and if not, is it possible to assert that?

https://codereview.chromium.org/26390004/diff/244001/Source/core/css/svg.css
File Source/core/css/svg.css (right):

https://codereview.chromium.org/26390004/diff/244001/Source/core/css/svg.css#...
Source/core/css/svg.css:53: position: absolute
position: absolute seems odd to me. Can you talk a bit about why it's needed?

[fs, 2014-04-15 09:01:24]

https://codereview.chromium.org/26390004/diff/244001/LayoutTests/accessibilit...
File LayoutTests/accessibility/svg-image-expected.txt (right):

https://codereview.chromium.org/26390004/diff/244001/LayoutTests/accessibilit...
LayoutTests/accessibility/svg-image-expected.txt:1: 
I noticed that there's a lot of these "stray whitespace" type changes to
*-expected.txt files. I guess it's somehow related to the <svg> in the test
changing size?

[Erik Dahlström (inactive), 2014-04-15 09:37:42]

https://codereview.chromium.org/26390004/diff/244001/LayoutTests/svg/in-html/...
File LayoutTests/svg/in-html/sizing/svg-inline.js (right):

https://codereview.chromium.org/26390004/diff/244001/LayoutTests/svg/in-html/...
LayoutTests/svg/in-html/sizing/svg-inline.js:369: doCombinationTest(
shouldn't there be tests for explicit 'auto' and 'inherit' too?

should those keywords be allowed in the width/height attributes, or just in
style? Firefox doesn't seem to map 'inherit' and 'auto' in the width/height
attributes.

Since allowing these keywords would not work fully without changing the SVG DOM
I'm leaning towards disallowing 'auto' and 'inherit' in the width/height
attributes for now, and then possibily allowing it in the future assuming the
baseVal/animVal DOM for width/height has been dropped.

[davve, 2014-04-15 15:55:09]

> I saw this was recently updated :) Ready for a review yet?

I think it's pretty close to ready. There are a couple of kinks left to iron
out, position:absolute on svg roots that you found being one of them. Will let
you know when I'm waiting for input. :)

> I noticed there are some changes in calculateImageIntrinsicDimensions and
> friends that seem to apply to more than just SVG images. Do those codepaths
> affect other images, and if not, is it possible to assert that?

Are you thinking of the changes in
RenderBoxModelObject::calculateImageIntrinsicDimensions? That code path do
affect other images, but no other images than SVG has had percentage intrinsic
width/height AFAIK. I.e. all images are now assumed to have a fixed intrinsic
width/height (which may be zero).

[davve, 2014-04-15 15:55:23]

https://codereview.chromium.org/26390004/diff/244001/LayoutTests/svg/in-html/...
File LayoutTests/svg/in-html/sizing/svg-inline.js (right):

https://codereview.chromium.org/26390004/diff/244001/LayoutTests/svg/in-html/...
LayoutTests/svg/in-html/sizing/svg-inline.js:369: doCombinationTest(
On 2014/04/15 09:37:43, Erik Dahlström wrote:
> shouldn't there be tests for explicit 'auto' and 'inherit' too?

For 'auto', I'd rather only add combinations that change sizing behavior from
existing already existing values. The inline tests are quite quick,
but adding combinations to the object tests would add considerable
time.

Testing that 'inherit' is mapped (or not mapped) would be better
tested in a separate test, IMHO.

> should those keywords be allowed in the width/height attributes, or
> just in style? Firefox doesn't seem to map 'inherit' and 'auto' in
> the width/height attributes.
>
> Since allowing these keywords would not work fully without changing
> the SVG DOM I'm leaning towards disallowing 'auto' and 'inherit' in
> the width/height attributes for now, and then possibily allowing it
> in the future assuming the baseVal/animVal DOM for width/height has
> been dropped.

Sounds good to me. Unless there is a reason to map them I don't see
why we should.

https://codereview.chromium.org/26390004/diff/244001/Source/core/css/svg.css
File Source/core/css/svg.css (right):

https://codereview.chromium.org/26390004/diff/244001/Source/core/css/svg.css#...
Source/core/css/svg.css:53: position: absolute
On 2014/04/15 02:46:10, pdr wrote:
> position: absolute seems odd to me. Can you talk a bit about why it's needed?

I have this on my list of things to do. Current ramblings:

position: absolute is a bit of a hack to get the height percentage value to
resolve against the viewport dimensions. Could and should probably be replaced
with a corresponding "hack"/fix in the c++ code instead, somewhere in
RenderReplaced::hasReplacedLogicalHeight() or
RenderBoxModelObject::hasAutoHeightOrContainingBlockWithAutoHeight().

The RenderView (containing block of the root svg) has style height:auto, so we
need to avoid falling into turning height: 100% into height: auto in some way.
As for position:absolute, hasAutoHeightOrContainingBlockWithAutoHeight has a
check for isOutOfFlowPositioned() that makes us able to resolve the height to
the viewport (since position:absolute stuff is outside normal flow it doesn't
contribute to auto height ancestors thus it being safe to resolve it percentages
without loops).

I will continue to look into this.

[davve, 2014-04-16 14:35:29]

Filed crbug.com/364051 and crbug.com/363949 on issues we might want to fix in
follow-up patches. Neither of them are regressions.

Bots seem happy now, so it might be time for review. If you like I could split
out the XMLErrors.cpp change to a separate CL and land that before the rest?

If you like me to rebaseline some of these manually as part of this patch, let
me know. (I don't have the lucid chroot setup yet; the script failed on me when
I tried)

https://codereview.chromium.org/26390004/diff/244001/Source/core/css/svg.css
File Source/core/css/svg.css (right):

https://codereview.chromium.org/26390004/diff/244001/Source/core/css/svg.css#...
Source/core/css/svg.css:53: position: absolute
On 2014/04/15 15:55:23, David Vest wrote:
> On 2014/04/15 02:46:10, pdr wrote:
> > position: absolute seems odd to me. Can you talk a bit about why it's
needed?
> 
> I have this on my list of things to do. Current ramblings:
> 
> position: absolute is a bit of a hack to get the height percentage value to
> resolve against the viewport dimensions. Could and should probably be replaced
> with a corresponding "hack"/fix in the c++ code instead, somewhere in
> RenderReplaced::hasReplacedLogicalHeight() or
> RenderBoxModelObject::hasAutoHeightOrContainingBlockWithAutoHeight().
> 
> The RenderView (containing block of the root svg) has style height:auto, so we
> need to avoid falling into turning height: 100% into height: auto in some way.
> As for position:absolute, hasAutoHeightOrContainingBlockWithAutoHeight has a
> check for isOutOfFlowPositioned() that makes us able to resolve the height to
> the viewport (since position:absolute stuff is outside normal flow it doesn't
> contribute to auto height ancestors thus it being safe to resolve it
percentages
> without loops).
> 
> I will continue to look into this.

Addressed by allowing boxes to resolve percentages against the frame. See
RenderBoxModelObject::hasAutoHeightOrContainingBlockWithAutoHeight in patch set
14 and later.

https://codereview.chromium.org/26390004/diff/284001/Source/core/css/svg.css
File Source/core/css/svg.css (right):

https://codereview.chromium.org/26390004/diff/284001/Source/core/css/svg.css#...
Source/core/css/svg.css:52: width: 100%;
I'll drop the trailing semi-colon to follow the surrounding style.

[pdr., 2014-04-16 18:17:03]

LGTM with two minor nits.

https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
File Source/core/svg/SVGSVGElement.cpp (right):

https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
Source/core/svg/SVGSVGElement.cpp:295: if (outermost && (name ==
SVGNames::widthAttr || name == SVGNames::heightAttr)) {
May be cleaner just to move outermost in:
if (isOutermostSVGSVGElement && ...)

https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
Source/core/svg/SVGSVGElement.cpp:330: if (widthChanged || attrName ==
SVGNames::heightAttr) {
Do you need to check isSVGRoot here?

[davve, 2014-04-17 11:39:22]

https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
File Source/core/svg/SVGSVGElement.cpp (right):

https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
Source/core/svg/SVGSVGElement.cpp:295: if (outermost && (name ==
SVGNames::widthAttr || name == SVGNames::heightAttr)) {
On 2014/04/16 18:17:04, pdr wrote:
> May be cleaner just to move outermost in:
> if (isOutermostSVGSVGElement && ...)

Will do.

https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
Source/core/svg/SVGSVGElement.cpp:330: if (widthChanged || attrName ==
SVGNames::heightAttr) {
On 2014/04/16 18:17:04, pdr wrote:
> Do you need to check isSVGRoot here?

Shuffling stuff around here led me to discover a regression.

My initial plan was to integrate the following two lines with the block above
that calls setNeedsLayoutAndPrefWidthsRecalc() which made me wonder if
setNeedsLayoutAndPrefWidthsRecalc really is needed in combination with
setNeedsStyleRecalc. Writing tests for that made discover that SVG animations on
the root element doesn't work as they should:

<!doctype html>
<style>
  svg { background: blue }
</style>
<div style="width: 100px; height: 400px; border: 3px dashed purple">
  <svg width="50px" height="200px">
    <animate attributeName="width" to="20px" dur="3s" begin="0s"/>
  </svg>
  More stuff on the line
</div>

doesn't reset as it should after the animation has finished. I've looked at it
some, but I still don't know exactly what's wrong. It looks like the underlying
animated property isn't updated as it should on end. Or that the attribute sync
is off somehow. So many moving parts here... Will have to come back to this
later, possibly after Easter.

[pdr., 2014-04-17 21:49:08]

On 2014/04/17 11:39:22, David Vest wrote:
>
https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
> File Source/core/svg/SVGSVGElement.cpp (right):
> 
>
https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
> Source/core/svg/SVGSVGElement.cpp:295: if (outermost && (name ==
> SVGNames::widthAttr || name == SVGNames::heightAttr)) {
> On 2014/04/16 18:17:04, pdr wrote:
> > May be cleaner just to move outermost in:
> > if (isOutermostSVGSVGElement && ...)
> 
> Will do.
> 
>
https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
> Source/core/svg/SVGSVGElement.cpp:330: if (widthChanged || attrName ==
> SVGNames::heightAttr) {
> On 2014/04/16 18:17:04, pdr wrote:
> > Do you need to check isSVGRoot here?
> 
> Shuffling stuff around here led me to discover a regression.
> 
> My initial plan was to integrate the following two lines with the block above
> that calls setNeedsLayoutAndPrefWidthsRecalc() which made me wonder if
> setNeedsLayoutAndPrefWidthsRecalc really is needed in combination with
> setNeedsStyleRecalc. Writing tests for that made discover that SVG animations
on
> the root element doesn't work as they should:
> 
> <!doctype html>
> <style>
>   svg { background: blue }
> </style>
> <div style="width: 100px; height: 400px; border: 3px dashed purple">
>   <svg width="50px" height="200px">
>     <animate attributeName="width" to="20px" dur="3s" begin="0s"/>
>   </svg>
>   More stuff on the line
> </div>
> 
> doesn't reset as it should after the animation has finished. I've looked at it
> some, but I still don't know exactly what's wrong. It looks like the
underlying
> animated property isn't updated as it should on end. Or that the attribute
sync
> is off somehow. So many moving parts here... Will have to come back to this
> later, possibly after Easter.

Just add a FIXME and file a bug :) No need to hold this patch up.

[davve, 2014-04-18 09:42:06]

On 2014/04/17 21:49:08, pdr wrote:
> On 2014/04/17 11:39:22, David Vest wrote:
> >
>
https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
> > File Source/core/svg/SVGSVGElement.cpp (right):
> > 
> >
>
https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
> > Source/core/svg/SVGSVGElement.cpp:295: if (outermost && (name ==
> > SVGNames::widthAttr || name == SVGNames::heightAttr)) {
> > On 2014/04/16 18:17:04, pdr wrote:
> > > May be cleaner just to move outermost in:
> > > if (isOutermostSVGSVGElement && ...)
> > 
> > Will do.
> > 
> >
>
https://codereview.chromium.org/26390004/diff/284001/Source/core/svg/SVGSVGEl...
> > Source/core/svg/SVGSVGElement.cpp:330: if (widthChanged || attrName ==
> > SVGNames::heightAttr) {
> > On 2014/04/16 18:17:04, pdr wrote:
> > > Do you need to check isSVGRoot here?
> > 
> > Shuffling stuff around here led me to discover a regression.
> > 
> > My initial plan was to integrate the following two lines with the block
above
> > that calls setNeedsLayoutAndPrefWidthsRecalc() which made me wonder if
> > setNeedsLayoutAndPrefWidthsRecalc really is needed in combination with
> > setNeedsStyleRecalc. Writing tests for that made discover that SVG
animations
> on
> > the root element doesn't work as they should:
> > 
> > <!doctype html>
> > <style>
> >   svg { background: blue }
> > </style>
> > <div style="width: 100px; height: 400px; border: 3px dashed purple">
> >   <svg width="50px" height="200px">
> >     <animate attributeName="width" to="20px" dur="3s" begin="0s"/>
> >   </svg>
> >   More stuff on the line
> > </div>
> > 
> > doesn't reset as it should after the animation has finished. I've looked at
it
> > some, but I still don't know exactly what's wrong. It looks like the
> underlying
> > animated property isn't updated as it should on end. Or that the attribute
> sync
> > is off somehow. So many moving parts here... Will have to come back to this
> > later, possibly after Easter.
> 
> Just add a FIXME and file a bug :) No need to hold this patch up.

You said it :) https://code.google.com/p/chromium/issues/detail?id=364807 filed.
Upload for landing on the way.

[davve, 2014-04-18 09:45:10]

The CQ bit was checked by davve@opera.com

[commit-bot: I haz the power, 2014-04-18 09:45:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/davve@opera.com/26390004/304001

[commit-bot: I haz the power, 2014-04-18 09:46:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-18 09:46:02]

Failed to apply patch for Source/core/svg/graphics/SVGImage.h:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file Source/core/svg/graphics/SVGImage.h
  Hunk #1 FAILED at 56.
  1 out of 1 hunk FAILED -- saving rejects to file
Source/core/svg/graphics/SVGImage.h.rej

Patch:       Source/core/svg/graphics/SVGImage.h
Index: Source/core/svg/graphics/SVGImage.h
diff --git a/Source/core/svg/graphics/SVGImage.h
b/Source/core/svg/graphics/SVGImage.h
index
b8843c51c32298ae30a38512eb819385b03716b3..9de716703f912f65bd621066557162c6b1624f10
100644
--- a/Source/core/svg/graphics/SVGImage.h
+++ b/Source/core/svg/graphics/SVGImage.h
@@ -56,9 +56,6 @@ public:
 
     virtual bool currentFrameHasSingleSecurityOrigin() const OVERRIDE;
 
-    virtual bool hasRelativeWidth() const OVERRIDE;
-    virtual bool hasRelativeHeight() const OVERRIDE;
-
     virtual void startAnimation(bool /*catchUpIfNecessary*/ = true) OVERRIDE;
     virtual void stopAnimation() OVERRIDE;
     virtual void resetAnimation() OVERRIDE;

[davve, 2014-04-18 10:31:00]

The CQ bit was checked by davve@opera.com

[commit-bot: I haz the power, 2014-04-18 10:31:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/davve@opera.com/26390004/324001

[commit-bot: I haz the power, 2014-04-18 10:48:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-18 10:48:32]

Try jobs failed on following builders:
  tryserver.blink on blink_presubmit

[davve, 2014-04-18 14:28:42]

Ojan, do you think you can review Source/web/?

[davve, 2014-04-18 16:04:36]

(Not sure who works on a Good Friday...)

Or Adam, perhaps you could review Source/web?

[eseidel, 2014-04-18 16:12:48]

I don't really fully understand this change.  I take it the SVG spec changed? 
In any case, I trust you and pdr to do the right thing here.  rslgtm.

https://codereview.chromium.org/26390004/diff/344001/Source/core/css/svg.css
File Source/core/css/svg.css (right):

https://codereview.chromium.org/26390004/diff/344001/Source/core/css/svg.css#...
Source/core/css/svg.css:50: svg:root {
I'm surprised we didn't already ahve this.  Or maybe SVGSVGElement has magical
sizing rules?  I remember fighting with this for a loooong time years ago.

https://codereview.chromium.org/26390004/diff/344001/Source/web/tests/data/to...
File Source/web/tests/data/touch-action-simple.html (right):

https://codereview.chromium.org/26390004/diff/344001/Source/web/tests/data/to...
Source/web/tests/data/touch-action-simple.html:59: <svg expected-action='none'
xmlns="http://www.w3.org/2000/svg" height="100%">
Why is this needed?  height=100% is default for SVGSVGElement, no?

[davve, 2014-04-18 17:24:31]

Yes, the SVG WG has a resolution to make changes corresponding to the CL.

I added a link to the minutes to the description. Both me and pdr attended.

https://codereview.chromium.org/26390004/diff/344001/Source/core/css/svg.css
File Source/core/css/svg.css (right):

https://codereview.chromium.org/26390004/diff/344001/Source/core/css/svg.css#...
Source/core/css/svg.css:50: svg:root {
On 2014/04/18 16:12:49, eseidel wrote:
> I'm surprised we didn't already ahve this.  Or maybe SVGSVGElement has magical
> sizing rules?  I remember fighting with this for a loooong time years ago.

WebKit had something similar until
https://bugs.webkit.org/show_bug.cgi?id=76447. It was partly based on a
misunderstanding though, as I've been told from old-timers. The 100% default
values was never intended to be included in the viewport calculation. Making
width/height presentation attributes is a compromise that allows percentage
values to be part of the viewport calculation, but the default value should not
be 100%.

https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0pIR8zVkHWH9jRVN-w8A...

is the link to the slides I presented and posted to blink-dev a couple of weeks
ago.

https://codereview.chromium.org/26390004/diff/344001/Source/web/tests/data/to...
File Source/web/tests/data/touch-action-simple.html (right):

https://codereview.chromium.org/26390004/diff/344001/Source/web/tests/data/to...
Source/web/tests/data/touch-action-simple.html:59: <svg expected-action='none'
xmlns="http://www.w3.org/2000/svg" height="100%">
On 2014/04/18 16:12:49, eseidel wrote:
> Why is this needed?  height=100% is default for SVGSVGElement, no?

See reply to other issue. Height should not 100% by default.

[davve, 2014-04-18 17:26:35]

The CQ bit was checked by davve@opera.com

[commit-bot: I haz the power, 2014-04-18 17:26:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/davve@opera.com/26390004/344001

[commit-bot: I haz the power, 2014-04-18 17:46:09]

Change committed as 171958

[commit-bot: I haz the power, 2014-04-18 17:46:49]

Failed to apply patch for LayoutTests/accessibility/svg-image-expected.txt:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file LayoutTests/accessibility/svg-image-expected.txt
  Hunk #1 FAILED at 1.
  1 out of 1 hunk FAILED -- saving rejects to file
LayoutTests/accessibility/svg-image-expected.txt.rej

Patch:       LayoutTests/accessibility/svg-image-expected.txt
Index: LayoutTests/accessibility/svg-image-expected.txt
diff --git a/LayoutTests/accessibility/svg-image-expected.txt
b/LayoutTests/accessibility/svg-image-expected.txt
index
d0bffd77ef2fca2dd8003bcb40076b29872947ad..2e1fca5fb58b03783b7add3013f24fc6db2880b4
100644
--- a/LayoutTests/accessibility/svg-image-expected.txt
+++ b/LayoutTests/accessibility/svg-image-expected.txt
@@ -1,4 +1,4 @@
-
+ 
 This tests that SVG images are accessible elements and they have the same
attributes as real images.
 
 On success, you will see a series of "PASS" messages, followed by "TEST
COMPLETE".

[eae, 2014-04-18 22:01:22]

This change cased a bunch of SVG tests to start timing out:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40...

[eae, 2014-04-18 22:02:15]

On 2014/04/18 22:01:22, eae wrote:
> This change cased a bunch of SVG tests to start timing out:
> 
>
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40...

As they are new tests added by this change I'll mark them as [ Timeout ] for
now. Please look into it and rework the tests if needed though.