Fix infinite recursion in computePreferredLogicalWidths.

Fix infinite recursion in computePreferredLogicalWidths.

RenderReplaced::computeReplacedLogicalWidth walks up to it's
containingBlock in some cases and asks for the containingBlock's
width. If the containingBlock's width itself depends on the
RenderReplaced's width, then we infinite loop. Avoid the
infinite loop by making sure that width/min-width/max-width
are all specified on the containingBlock, which will keep
the width from depending on it's children.

Added FIXMEs. I think we should delete all this containingBlock
walking code, but it needs to be done carefully to make sure
percentage widths on <svg> keep working. The spec actually
considered this undefined behavior, but suggests doing the
crazy that we do here.

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

[ojan, 2014-03-04 19:09:08]

I'm not terribly happy with this fix. I think the existing code is a bit crazy,
but fixing it all up is more work than I'd like to put into it at the moment.

I tried just deleting all the code in question, but that broke a bunch of tests.
Mostly the changes actually made us match Firefox rendering, but there were a
couple cases where we didn't correctly compute percentage widths on <svg>. This
needs someone to think through how percentage widths on <svg> *should* work and
rewrite this code.

[esprehn, 2014-03-04 20:22:04]

lgtm, that's a crazy bug

[ojan, 2014-03-04 22:03:19]

The CQ bit was checked by ojan@chromium.org

[commit-bot: I haz the power, 2014-03-04 22:04:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ojan@chromium.org/186913003/1

[commit-bot: I haz the power, 2014-03-05 18:37:22]

Change committed as 168511

[davve, 2014-03-06 08:06:59]

> This needs someone to think through how percentage widths on <svg> *should*
work and rewrite this code.

Just for the reference, the way I think percentage widths (and heights) on <svg>
should work is outlined in as a draft patch in
https://codereview.chromium.org/26390004/, i.e. make width/height presentation
attributes (map them to style) and let percentages be handled in the normal CSS
way. There are a couple of problems:

*  we may break some content, especially content written for Blink/WebKit like a
lot of testcases that uses the old behavior both intentionally and
unintentionally.

* It's not what IE(10) does. I've received some clues that IE handles SVGs as
non-replaced block content but I don't have the full picture of what they do.

* There is some controversy regarding mapping *default* 100% width/height values
to style. This is discussed a bit in
http://code.google.com/p/chromium/issues/detail?id=308992.

As for this specific piece of code, I can't say much except that we need
_something_ to not fall into the 300(x150) trap for SVG content without
intrinsic width (but with intrinsic ratio).