Closed Bug 35355 Opened 25 years ago Closed 24 years ago

[TEXT]displays blank: local html file, one long line, no spaces, no markup, no \n at end

Categories

(Core :: Layout, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: jruderman, Assigned: dbaron)

References

Details

Attachments

(2 files)

Steps to reproduce: 1. Create a local html file with the following text (it should be one continuous word, and the file shouldn't have a \n at the end): aaaaaaaaaaaaaaaMaaOaaZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2. Load it in mozilla using a file:/// url. Actual results: at least when mozilla is maximized and the word can't all fit on one page without scrolling, nothing is displayed (often not even a scrollbar). Expected results: text is displayed with a horizontal scrollbar. Things to notice: 1. Making the text shorter until it can all display on one page makes it display correctly. 2. Making the text longer will eventually make the horizontal scrollbar appear (at about 1.5 page lengths?) The text still doesn't show up. 3. Loading the page through a webserver makes it display correctly. 4. Loading the file as a .txt file displays correctly (with a fixed-width font) 5. Putting a \n at the end of the file fixes it. 6. Putting <b> </b> around the 'O' makes the whole thing display correctly 7. Putting <b> </b> around the second-to-last 'a' makes the bold 'a' and the 'a' after it display, but nothing else. PC, Windows 98, c:\httpd\HtDocs\bleh.html, nightly build 2000 040908.
Off to layout land; the parser is loading the file correctly, and the content model is fine.
Assignee: rickg → buster
won't be in beta2, should be fixed before FCS.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M18 → M19
This bug has been marked "future" because we have determined that it is not critical for netscape6.0. If you feel this is an error, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M19 → Future
Depends on: 40741
Now displays correctly on load, but text disappears if you start scrolling around.
Attached file testcase (deleted) —
Component: Parser → Layout
Summary: displays blank: local html file, one long line, no spaces, no markup, no \n at end → [TEXT]displays blank: local html file, one long line, no spaces, no markup, no \n at end
Stealing this, since I'm working on it, although I may have to give it back...
Assignee: buster → dbaron
Status: ASSIGNED → NEW
The problem is caused by the text frame having a width that is way too low. Thi s doesn't happen for all text frames...
This bug doesn't exist on Linux.
nsTextFrame::MeasureText is returning the wrong value...
Robert, do you have any idea why MeasureText would return a ridiculously small value on Windows only (perhaps even Win95/98 only) if and only if a text frame that is a child of BODY overflows the viewport?
No. It happens on NT too. I will investigate.
It's a bug in nsRenderingContextWin::GetWidth. > while ((breakIndex >= 0) && (width > aAvailWidth)) { > start = aBreaks[breakIndex - 1]; Suspicious, eh? :-)
The Unicode version appears to be OK. If you put some Unicode characters in the string it works.
Do you understand the code well enough to be sure that that's the right fix, as opposed to changing the indices into the two arrays on the following two lines?
Yes. When we enter the loop, breakIndex really is the index of some break (i.e. 0 <= breakIndex < aNumBreaks). At each iteration, we are trying to back up from break "breakIndex" to break "breakIndex - 1". If breakIndex == 0 then we are trying to back up from break 0 to break -1. That's a bad idea.
Fix checked in. Thanks, Robert.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verif fixed 2000 093008. Added comment to bug 31487 about the margins not being correct on the testcase.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: