Bug 29636

Summary:

Long text lines are rendered as empty for the first 2**16 characters

Product:

WebKit

Reporter:

Daniel Martin <dtm>

Component:

Layout and Rendering

Assignee:

Nobody <webkit-unassigned>

Status:

NEW ---

Severity:

Normal

CC:

ap, arpitabahuguna, austin.cheney, brettw, dglazkov, eric, jimmy.selgen, mitz, pkasting, vijayan.bits, webkit.review.bot

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
Patch	none
Patch	eric: review-

Description Daniel Martin 2009-09-22 04:35:40 PDT

The following perl script outputs an html file that should be rendered as three lines inside a <pre> block.  When opened in Safari ( 4.0.3 (531.9.1) ) or in Google Chrome (3.0.195.21), the first and third lines are blank for the first 65536 characters.  The middle line, slightly shorter than 65536 characters, is rendered in full.

#! /usr/bin/perl
print '<html>
<head>
<title>Long lines, bad webkit</title>
</head>
<body>
<pre>
';
print "$_ " for (1..12_774);
print '<br>';
print "$_ " for (1..12_773);
print '<br>';
print "$_ " for (1..12_775);
print '
</pre></body>
</html>
';

Comment 1 Brett Wilson (Google) 2009-09-22 06:44:04 PDT

I think this is Windows' text drawing command rejecting a string that's "too long." The way to fix it would be to get a conservative estimate of what text actually appears in the current clip, and only draw those characters.

Comment 2 Daniel Martin 2009-09-22 10:20:44 PDT

I'm also seeing this bug on Safari running on MacOS, so I don't think it's a windows bug.

Comment 3 Peter Kasting 2009-09-22 10:42:16 PDT

See also bug 28201 (probably same root cause).

Comment 4 Alexey Proskuryakov 2012-06-13 10:07:45 PDT

*** Bug 88996 has been marked as a duplicate of this bug. ***

Comment 5 Arpita Bahuguna 2012-07-13 05:26:02 PDT

Created attachment 152227 [details]
Patch

Comment 6 Build Bot 2012-07-13 05:38:59 PDT

Comment on attachment 152227 [details]
Patch

Attachment 152227 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/13239079

Comment 7 WebKit Review Bot 2012-07-13 06:03:04 PDT

Comment on attachment 152227 [details]
Patch

Attachment 152227 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13240083

Comment 8 Arpita Bahuguna 2012-07-13 07:18:02 PDT

Okay.. I understand the problem that the typecasting will bring here. Need to check further on this.

Comment 9 Arpita Bahuguna 2012-07-16 01:46:31 PDT

Created attachment 152498 [details]
Patch

Comment 10 Arpita Bahuguna 2012-07-16 02:36:51 PDT

Changing the datatype of m_len can obviously have its many typecasting ramifications. Have currently made m_len as an integer (similar to m_start).
This would probably have issues too (typecasting to unsigned) but since we don't expect length to be negative, this can perhaps be ignored.(?)

Also, this would have an additional overhead of increasing the size of our InlineTextBox by 2bytes.

Comment 11 Eric Seidel (no email) 2012-07-16 10:11:29 PDT

Comment on attachment 152498 [details]
Patch

I would expect this to be a large increase in memory usage for WebKit.  I'm surprised there is not a COMPILE_ASSERT to verify the size of InlineTextBox.

Comment 12 Kent Tamura 2012-08-10 18:06:48 PDT

*** Bug 90739 has been marked as a duplicate of this bug. ***

Comment 13 Kent Tamura 2012-08-10 18:07:19 PDT

*** Bug 51168 has been marked as a duplicate of this bug. ***