[css-sizing] Ensure positive available size on replaced elements

third_party/WebKit/Source/core/layout/LayoutBox.cpp

 /*
  * Copyright (C) 1999 Lars Knoll (knoll@kde.org)
  *           (C) 1999 Antti Koivisto (koivisto@kde.org)
  *           (C) 2005 Allan Sandfeld Jensen (kde@carewolf.com)
  *           (C) 2005, 2006 Samuel Weinig (sam.weinig@gmail.com)
  * Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010 Apple Inc. All rights reserved.
  * Copyright (C) 2013 Adobe Systems Incorporated. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
@@ skipping 2821 matching lines @@
         LayoutUnit availableLogicalWidth;
         return computeIntrinsicLogicalWidthUsing(logicalWidth, availableLogicalWidth, borderAndPaddingLogicalWidth()) - borderAndPaddingLogicalWidth();
     }
     case FitContent:
     case FillAvailable:
     case Percent:
     case Calculated: {
         // FIXME: containingBlockLogicalWidthForContent() is wrong if the replaced element's writing-mode is perpendicular to the
         // containing block's writing-mode.
         // https://bugs.webkit.org/show_bug.cgi?id=46496
-        const LayoutUnit cw = isOutOfFlowPositioned() ? containingBlockLogicalWidthForPositioned(toLayoutBoxModelObject(container())) : containingBlockLogicalWidthForContent();
+        const LayoutUnit cw = std::max(LayoutUnit(), isOutOfFlowPositioned() ? containingBlockLogicalWidthForPositioned(toLayoutBoxModelObject(container())) : containingBlockLogicalWidthForContent());

[cbiesinger, 2016/06/27 18:43:49]

So, why do these functions return a negative value? Wouldn't it be better to fix
them not to do that?

[jfernandez, 2016/06/27 21:38:43]

I though about that, actually. However, I've got lots of doubts on that
approach. First of all, these functions are quite old and widely used. Actually,
there are similar defensive logic in both, webkit and blink (look at
computeLogicalWidth function). My impression is that this logic is far for being
homogeneous; while the function
containingBlockLogicalWidthForPositioned avoids any negative value on each of
its branches, the
case of containingBlockLogicalWidthForContent is different on that regard. 

The negative values comes from the fact that width (border or content box,
depending on the box sizing, I guess)  can be less than border, padding, margin
and scrollbar. Hence, it's quite easy to define cases here the content width is
a negative value. In the case of the above mentioned function, it returns either
overrideContainingBlockContentLogicalWidth, or availableLogicalWidth
or clientLogicalWidth, all of them unprotected against negative values. 

Additionally, containingBlockLogicalWidthForContent is a virtual method, which
is defined as availableLogicalWidth, so we should protect upper classes as well
against negative values.

So I'm not sure there is an easy fix for that, considering how sensible those
functions are. 

         Length containerLogicalWidth = containingBlock()->style()->logicalWidth();
         // FIXME: Handle cases when containing block width is calculated or viewport percent.
         // https://bugs.webkit.org/show_bug.cgi?id=91071
         if (logicalWidth.isIntrinsic())
             return computeIntrinsicLogicalWidthUsing(logicalWidth, cw, borderAndPaddingLogicalWidth()) - borderAndPaddingLogicalWidth();
         if (cw > 0 || (!cw && (containerLogicalWidth.isFixed() || containerLogicalWidth.hasPercent())))
             return adjustContentBoxLogicalWidthForBoxSizing(minimumValueForLength(logicalWidth, cw));
         return LayoutUnit();
     }
     case Auto:
@@ skipping 2024 matching lines @@
         m_rareData->m_snapAreas->remove(&snapArea);
     }
 }
 
 SnapAreaSet* LayoutBox::snapAreas() const
 {
     return m_rareData ? m_rareData->m_snapAreas.get() : nullptr;
 }
 
 } // namespace blink