Avoid division-by-zero in SVGLengthContext::convertValueFromUserUnits

Avoid division-by-zero in SVGLengthContext::convertValueFromUserUnits

If the viewport is valid but empty, we could end up dividing by zero,
which could produce either Infinity or NaN.
This could end up triggering an assert when creating a
CSSPrimitiveValue for the SVGLength in question.

TEST=http/tests/cache/smil-usecounter-in-cached-image.html
BUG=485973
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=195174

[fs, 2015-05-08 13:25:39]

fs@opera.com changed reviewers:
+ davve@opera.com, pdr@chromium.org

[pdr., 2015-05-09 04:28:14]

On 2015/05/08 at 14:43:16, fs wrote:
> 

Codechange LGTM

I don't see this failing locally or on the bots though
(http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=smi...).

[fs, 2015-05-11 08:55:35]

On 2015/05/09 04:28:14, pdr (Slow May 5th - May 18th) wrote:
> On 2015/05/08 at 14:43:16, fs wrote:
> > 
> 
> Codechange LGTM
> 
> I don't see this failing locally or on the bots though
>
(http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=smi...).

Yeah, the odd part is that it shows up in the results for a "later" test in the
same sub-directory:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=htt...

sof alerted me to this, and the stacktrace seemed to add up with the
smil-usecounter-in-cached-image.html in the same directory. I could repro when
running that test alone in a debug build.

[pdr., 2015-05-11 09:49:05]

On 2015/05/11 at 08:55:35, fs wrote:
> On 2015/05/09 04:28:14, pdr (Slow May 5th - May 18th) wrote:
> > On 2015/05/08 at 14:43:16, fs wrote:
> > > 
> > 
> > Codechange LGTM
> > 
> > I don't see this failing locally or on the bots though
> >
(http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=smi...).
> 
> Yeah, the odd part is that it shows up in the results for a "later" test in
the same sub-directory:
> 
>
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=htt...
> 
> sof alerted me to this, and the stacktrace seemed to add up with the
smil-usecounter-in-cached-image.html in the same directory. I could repro when
running that test alone in a debug build.

Ahh... I tried running it alone (and with --iterations=100) but for some reason
it doesn't crash on OSX 10.9.

Looking at the stacktrace... are we running the animation timer for images with
no users?

In any case, LGTM to land.

[pdr., 2015-05-11 09:49:11]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2015-05-11 09:49:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1133783003/1

[fs, 2015-05-11 10:19:24]

On 2015/05/11 09:49:05, pdr (Slow May 5th - May 18th) wrote:
> On 2015/05/11 at 08:55:35, fs wrote:
> > On 2015/05/09 04:28:14, pdr (Slow May 5th - May 18th) wrote:
> > > On 2015/05/08 at 14:43:16, fs wrote:
> > > > 
> > > 
> > > Codechange LGTM
> > > 
> > > I don't see this failing locally or on the bots though
> > >
>
(http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=smi...).
> > 
> > Yeah, the odd part is that it shows up in the results for a "later" test in
> the same sub-directory:
> > 
> >
>
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=htt...
> > 
> > sof alerted me to this, and the stacktrace seemed to add up with the
> smil-usecounter-in-cached-image.html in the same directory. I could repro when
> running that test alone in a debug build.
> 
> Ahh... I tried running it alone (and with --iterations=100) but for some
reason
> it doesn't crash on OSX 10.9.
> 
> Looking at the stacktrace... are we running the animation timer for images
with
> no users?

Yes, it appears so. I'll try to look into this (time permitting.)

[commit-bot: I haz the power, 2015-05-11 11:08:20]

Committed patchset #1 (id:1) as
https://src.chromium.org/viewvc/blink?view=rev&revision=195174

[fs, 2015-05-11 14:34:41]

On 2015/05/11 10:19:24, fs wrote:
> On 2015/05/11 09:49:05, pdr (Slow May 5th - May 18th) wrote:
> > On 2015/05/11 at 08:55:35, fs wrote:
> > > On 2015/05/09 04:28:14, pdr (Slow May 5th - May 18th) wrote:
> > > > On 2015/05/08 at 14:43:16, fs wrote:
> > > > > 
> > > > 
> > > > Codechange LGTM
> > > > 
> > > > I don't see this failing locally or on the bots though
> > > >
> >
>
(http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=smi...).
> > > 
> > > Yeah, the odd part is that it shows up in the results for a "later" test
in
> > the same sub-directory:
> > > 
> > >
> >
>
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=htt...
> > > 
> > > sof alerted me to this, and the stacktrace seemed to add up with the
> > smil-usecounter-in-cached-image.html in the same directory. I could repro
when
> > running that test alone in a debug build.
> > 
> > Ahh... I tried running it alone (and with --iterations=100) but for some
> reason
> > it doesn't crash on OSX 10.9.
> > 
> > Looking at the stacktrace... are we running the animation timer for images
> with
> > no users?
> 
> Yes, it appears so. I'll try to look into this (time permitting.)

The timer is triggered by the animation, and the entire scenario (for the assert
to trigger) is likely timing sensitive (too many breakpoints and it no longer
triggers.) Reminds me a bit about the "40 vs. 60 FPS" issue with SVGImage and
animations, where I was pondering if we could control that via the ImageObserver
(and maybe indirectly the clients) somehow. Seems to share some common ground
with not running the animation at all. Haven't been able to move that out of
mind and into code yet though...