All users were logged out of Bugzilla on October 13th, 2018

Very long line is not fully rendered

VERIFIED WORKSFORME

Status

VERIFIED WORKSFORME
18 years ago
7 years ago

People

(Reporter: mats, Unassigned)

Tracking

({testcase})

Trunk
x86
All
testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME, URL)

Attachments

(8 attachments, 1 obsolete attachment)

(Reporter)

Description

18 years ago
DESCRIPTION:
Very long comment line is not rendered in view-source window.

STEPS TO REPRODUCE:
1. Load first testcase of bug 89731.
2. View -> Page Source.

ACTUAL RESULTS:
There are two long comment lines in that testcase - the second one does not
render. If you try to select some text on that (empty) line it will be rendered
partly.

EXPECTED RESULTS:
Line rendered.

DOES NOT WORK CORRECTLY ON:
Mozilla nightly build 2001-07-20-03 on Windows 98 SE.
Communicator 4.74 on Windows 98 SE.

WORKS CORRECTLY ON:
MSIE 5.00 on Windows 98 SE.
WFM, Win NT, build 2001081403.

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla1.2
Bulk moving Moz1.2 bugs to future-P3. I will pull from this list when scheduling
post Mozilla1.0 work.
Priority: -- → P3
Target Milestone: mozilla1.2 → Future
Seeing this with linux cvs 2002-03-13, and not only in view-source. Another
testcase: Original report of bug 130725. Scroll way right, at some point the
text stops displaying unless selected.
OS: Windows 98 → All
Summary: Very long comment line is not rendered in view-source window → Very long line is not fully rendered
javascript:alert(window.pageXOffset); tells me the text stops displaying
properly at about 32k px, i.e. near 2^15 px. ...so this may be somewhat related
to bug 51385, where some form elements repeat (at least vertically) every 2^16
px. Not to mention the other weirdnesses of attachment 71729 [details]...

Comment 6

17 years ago
Created attachment 90843 [details]
long text within <pre> tags 

when you "text zoom" the page to 120 % - 200% , the text disappears from the
screen.

Comment 7

17 years ago
notes on comment 5 :- (specific to macoS 10.1)

attachment 90700 [details]
- text file with only aplhanumeric characters
- The file size is 1k.
- text disappears when "text zoom" is 675%

attachment 907001
- text file with escape characters sprinkled within
- The file size is 43K 
- text dsappears when "text zoom" is between 100% - 200%

attachment 907002
- text file with null characters sprinkled within
- The file size is 1K 
- text disppears when "text zoom" is 450%

attachment 907003
- a long text file with alpanumeric characters
- The file size is 51K 
- text disppears when "text zoom" is 100%

attachment 907004
- text file with whitespace characters sprinkled within
- The file size is 5K
- text disppears when "text zoom" is between 90% - 120%
Keywords: testcase

Comment 8

15 years ago
Created attachment 149519 [details]
4000 char example displays first 3072 chars

While investigating bug 196144 I discovered this bug again.  I'm on Windows ME
running Mozilla build 2004052709.  Long lines of HTML source are not rendered
properly in the View Source window when wrapping is turned off.  Everything
displays ok when wrap long lines is selected.

I attach three testcases:
test-long-line-3000.html (3000 char example works ok)
test-long-line-4000.html (4000 char example displays first 3072 chars)
test-long-line-5000.html (5000 char example displays first 3072 chars but first
910-920 chars are invisible).

This was reported a while ago and fixed at a lower line length (512/1024) - bug
67938 - but is now occurring after 3,072 characters.  Additionally in the 5,000
character example you'll see the first 910-920 characters go invisible.

This bug really should be assigned to someone who is still active on the
project.

Comment 9

15 years ago
Created attachment 149520 [details]
4000 char example displays first 3072 chars
Attachment #149519 - Attachment is obsolete: true

Comment 10

15 years ago
Created attachment 149521 [details]
5000 char example displays first 3072 chars but first 910-920 chars are invisible

Comment 11

15 years ago
Created attachment 149522 [details]
3000 char example works ok

Comment 12

15 years ago
reassign to default owner/QA since current assignee is formerly-netscape.com.tld.
Assignee: kmcclusk → general
Status: ASSIGNED → NEW
QA Contact: chrispetersen → ian

Updated

15 years ago
Priority: P3 → --
Target Milestone: Future → ---

Comment 13

15 years ago
Created attachment 149527 [details]
4000 chars no spaces breaks in HTML renderer too

I can now confirm that the HTML renderer has the same problem as View Source
when displaying lines greater than 3072 chars long without line wrapping. 
Please see latest testcase: test-long-line-4000b.html.	Again, this is
confirmed in Windows ME Mozilla build 2004052709.

Bug 196144 is a dup of this one.

Comment 14

15 years ago
Notes in bug 196144 spoke of a 4096 limit on Linux before this problem arose. 
But it's definitely a problem after 3072 chars on Windows.

Comment 15

15 years ago
I just isolated a bug in Mozilla 1.7 (originally seen in Netscape 7.1) that
seems to be this same issue.  I'm running on Windows XP.  I'm viewing text files
hosted on an Apache server - I tried Apache on both XP and Linux with the same
results.

The text files contain a single long line of "x" characters.  If they contain
4095 or more characters, the page comes up blank.  (I'll attach this one as a
test case.)  Then if I select any character by blindly clicking where the text
should be, they all become visible.  When I deselect, all goes blank again.

For a line 4096 characters long, if I select any character from the second one
onward, the text becomes visible.  If I select the first character, only that
one is visible.  With 4100 characters, when I select any character from the
sixth onward, all becomes visible.  But if I select any of characters 1-5, only
the selected characters and those to the left of them are visible.  This pattern
continues for long lines.

If I double-click over the invisible text, it's all highlighted as a solid gray
rectangle with the text still not visible.

The thresholds change as I zoom in and out with "Ctrl +" and "Ctrl -".

I've noticed a vaguely similar problem with IE 6 rendering long lines in text
files, but the problem occurs at a much higher threshold.

Comment 16

15 years ago
Created attachment 149834 [details]
Test case with 4095 x characters on a single line

Smallest text file that reproduces the problem for me.

Comment 17

15 years ago
Created attachment 149835 [details]
Text file with 4100 x characters on a single line

Test case that shows additional strangeness - depending on where I select, some
or all of the line becomes visible.

Comment 18

15 years ago
*** Bug 196144 has been marked as a duplicate of this bug. ***

Comment 19

15 years ago
*** Bug 202175 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Depends on: 237085

Updated

14 years ago
Blocks: 264405

Updated

14 years ago
Blocks: 235344

Updated

13 years ago
Blocks: 302294

Updated

13 years ago
Blocks: 321142

Updated

13 years ago
No longer blocks: 321142

Updated

13 years ago
Blocks: 321142

Comment 20

12 years ago
Is this bug still occurring? I can't see any problem with the test cases on Mac.

Comment 21

12 years ago
It is still occurring; at least on Firefox 2.0.  Coincidentally, I noticed it while cooking up some data URIs at the website of this bug's QA contact.

The text is not displayed on the page or when viewing source.  Moving a window around caused some of the text to repaint in the browser window.

Comment 22

12 years ago
Created attachment 245046 [details]
screenshot

Comment 23

12 years ago
(In reply to comment #21)
> The text is not displayed on the page or when viewing source.  Moving a window
> around caused some of the text to repaint in the browser window.

Michael, What OS are you using? And can you reproduce it using attachment 149527 [details] (keep increasing the font size and see if the line disappears)? I can't reproduce with Windows XP or Mac OS X 10.4.

Comment 24

12 years ago
This is happening for me on WinXP, in SeaMonkey 1.5a and now SM2.0a. In attachment 149527 [details] , the first line is invisible until I highlight a section of it. If I highlight some of the early part of the line, say from char 20 to 40, all the characters from 1 to 40 will be visible. If I highlight a few characters toward the middle of the line, then the entire line becomes visible.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/2007062706 SeaMonkey/2.0a1pre
Product: Core → Core Graveyard
I can't confirm any of the bugs listed here in Aurora 6.0a2 on OS X 10.6. Please reopen if you can reproduce the issue.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 26

7 years ago
Verified WFM, Aurora 9.0a2 on OSX 10.7.1 and Nightly 20111007 on Linux.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.