Closed Bug 4803 Opened 21 years ago Closed 21 years ago
Text overflows within table, column border elongated
* TITLE/SUMMARY Text overflows within table, column border elongated * STEPS TO REPRODUCE 0) Launch Apprunner 1) View http://www.ivillage.com (or the sortof-simplified test case at http:// www.prometheus-music.com/gecko/ivillage5.html. I can simplify further if preferred.) * RESULT - What happened a. The vertical grey stripe between the right-most column and the column to its left is stretched to about 10 pixels. b. Correspondingly, the last character of the "DAILY CHECK" and "COMMUNITY" is shifted onto the following line. If you remove the content text from the 3rd column (e.g. the equal pay day & star talk articles), the divider between the 2nd and 3rd column shrinks in width, and the title texts no longer overflows to the following line on Mac OS [but the last character of the "DAILY CHECK" title does carry over to the next line]. (You can see this at http://www.prometheus-music.com/gecko/ivillage6.html) * REGRESSION - Occurs On Mac OS Apprunner (4.8.99 AM optimized build) Win32 Apprunner (4.8.99 AM optimized build [NT 4, Service Pack 3]) - Doesn't Occur On Linux Apprunner (4.7.99 AM optimized build) * CONFIGURATIONS TESTED - [Mac] Power Mac 8500/120 (233 Mhz 604e), 64 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.5.1 - [Win32] Vectra VL (233 Mhz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3. - [Linux] Vectra VL (266 Mhz P2), 96 MB RAM.
[duh. yeah, shoulda put that directly into HTMLTables. thanks for moving it]
[As a courtesy FYI, this still takes place in the 4.22.99 Mac OS build.]
Moving to M7.
Moving to M9.
This bug is still present in July 29 build on Windows 98 (buildid: 1999072908). It may be a duplicate of (or at least similar to) bug#3094
Assignee: karnaze → kipp
Status: ASSIGNED → NEW
Target Milestone: M9 → M10
When nsTableCellFrame::Reflow of the 1st cell in the attachement reflows the child (area frame) unconstrained, it returns a max element width of 4 pixels (converted from twips) and it should be 1 pixel. Reassigning to Kipp.
An interesting bug that mostly has to do with how nav4 handles whitespace at the end of lines; my newly resurrected TrimTrailingWhiteSpace logic seems to handle this problem (and others) neatly.
Fixed in the Sept 23rd build.
You need to log in before you can comment on or make changes to this bug.