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-

Daniel Martin

Reported 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> ';

Attachments
Patch (132.70 KB, patch) 2012-07-13 05:26 PDT, Arpita Bahuguna	no flags	Details Formatted Diff Diff
Patch (134.12 KB, patch) 2012-07-16 01:46 PDT, Arpita Bahuguna	eric: review-	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Brett Wilson (Google)

Comment 1 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.

Daniel Martin

Comment 2 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.

Peter Kasting

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

See also bug 28201 (probably same root cause).

Alexey Proskuryakov

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

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

Arpita Bahuguna

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

Created attachment 152227 [details] Patch

Build Bot

Comment 6 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

WebKit Review Bot

Comment 7 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

Arpita Bahuguna

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

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

Arpita Bahuguna

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

Created attachment 152498 [details] Patch

Arpita Bahuguna

Comment 10 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.

Eric Seidel (no email)

Comment 11 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.

Kent Tamura

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

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

Kent Tamura

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

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

Note You need to log in before you can comment on or make changes to this bug.