NEW 29636
Long text lines are rendered as empty for the first 2**16 characters 
https://bugs.webkit.org/show_bug.cgi?id=29636
Summary Long text lines are rendered as empty for the first 2**16 characters
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
DetailsFormatted DiffDiff
Patch (134.12 KB, patch)
2012-07-16 01:46 PDT, Arpita Bahuguna 		eric: review-
DetailsFormatted DiffDiff
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.