<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>134940</bug_id>
          
          <creation_ts>2014-07-15 14:04:50 -0700</creation_ts>
          <short_desc>Large height/width for body causes page rendering to fail</short_desc>
          <delta_ts>2014-08-19 14:20:12 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>Layout and Rendering</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>ASSIGNED</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Bem Jones-Bey">bjonesbe</reporter>
          <assigned_to name="alan">zalan</assigned_to>
          <cc>zalan</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1022552</commentid>
    <comment_count>0</comment_count>
      <attachid>234949</attachid>
    <who name="Bem Jones-Bey">bjonesbe</who>
    <bug_when>2014-07-15 14:04:50 -0700</bug_when>
    <thetext>Created attachment 234949
testcase

The attached test case doesn&apos;t render in WebKit Nightly, but it renders fine in Safari 7.0.5.

In a local build, it triggers signed integer overflow with many LayoutUnit operations, and there are places where the computed &quot;bottom&quot; coordinate is negative. If I do a build with saturated layout arithmetic enabled, then these LayoutUnit operations no longer cause integer overflows, but it still doesn&apos;t render. I haven&apos;t been able to determine where the core issue is.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1030108</commentid>
    <comment_count>1</comment_count>
    <who name="Bem Jones-Bey">bjonesbe</who>
    <bug_when>2014-08-19 14:08:37 -0700</bug_when>
    <thetext>Looks like this has been fixed by some other change.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1030111</commentid>
    <comment_count>2</comment_count>
    <who name="alan">zalan</who>
    <bug_when>2014-08-19 14:14:11 -0700</bug_when>
    <thetext>It still fails on trunk/nightly builds for me.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1030114</commentid>
    <comment_count>3</comment_count>
    <who name="Bem Jones-Bey">bjonesbe</who>
    <bug_when>2014-08-19 14:20:12 -0700</bug_when>
    <thetext>(In reply to comment #2)
&gt; It still fails on trunk/nightly builds for me.

Oh, you&apos;re right, it doesn&apos;t draw the X, but it does render the background color. It didn&apos;t even render the background color when I filed this issue, which is why I was confused.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>234949</attachid>
            <date>2014-07-15 14:04:50 -0700</date>
            <delta_ts>2014-07-15 14:04:50 -0700</delta_ts>
            <desc>testcase</desc>
            <filename>new-big.html</filename>
            <type>text/html</type>
            <size>167</size>
            <attacher name="Bem Jones-Bey">bjonesbe</attacher>
            
              <data encoding="base64">PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KPHN0eWxlPgpib2R5IHsKICAgIHdpZHRoOiAz
MzU1NDQyOHB4OwogICAgaGVpZ2h0OiAzMzU1NDQyOHB4OwogICAgYmFja2dyb3VuZC1jb2xvcjog
eWVsbG93Owp9Cjwvc3R5bGU+Cjxib2R5PgogIFgKPC9kaXY+CjwvYm9keT4KPC9odG1sPgo=
</data>

          </attachment>
      

    </bug>

</bugzilla>