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)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: jruderman, Assigned: dbaron)
References
Details
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 5•24 years ago
|
||
Now displays correctly on load, but text disappears if you start scrolling
around.
Assignee | ||
Comment 6•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
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
Assignee | ||
Comment 7•24 years ago
|
||
Stealing this, since I'm working on it, although I may have to give it back...
Assignee: buster → dbaron
Status: ASSIGNED → NEW
Assignee | ||
Comment 8•24 years ago
|
||
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...
Assignee | ||
Comment 9•24 years ago
|
||
This bug doesn't exist on Linux.
Assignee | ||
Comment 10•24 years ago
|
||
nsTextFrame::MeasureText is returning the wrong value...
Assignee | ||
Comment 11•24 years ago
|
||
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.
Assignee | ||
Comment 16•24 years ago
|
||
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.
Assignee | ||
Comment 18•24 years ago
|
||
Fix checked in. Thanks, Robert.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 19•24 years ago
|
||
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.
Description
•