Closed Bug 257199 Opened 21 years ago Closed 21 years ago

inserting frames does not create necessary anonymous table frames

Categories

(Core :: Layout: Tables, defect)

x86
All
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 148810

People

(Reporter: robert.strong.bugs, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040827 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040827 Firefox/0.9.1+ This was discussed on Mozillazine http://forums.mozillazine.org/viewtopic.php?t=119389 regarding http://www.mcafee.com/us/. When the files are saved to my system and viewed they render as they should... when uploaded to a server they no longer render properly. I fixed a couple of minor XHTML and CSS validation errors in the original and placed them on my server at http://exchangecode.com/mcafee/test.html. Reproducible: Sometimes Steps to Reproduce: 1. Copy the files from http://exchangecode.com/mcafee/ locally. 2. Compare test.html when viewed locally to one on the server. 3. Actual Results: The page is rendered differently most of the time Expected Results: The page should be rendered the same... preferably as it is seen when viewing it locally. This same results were experienced with both: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040827 Firefox/0.9.1+ and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040817 This may have to do with network speed. I have noticed that if I navigate to a new page and then go back that it renders it properly.
I created another html file and removed the javascript along with the css files that don't pertain to this issue and the problem is still present. http://exchangecode.com/mcafee/test2.html The only files necessary for testing should be the test2.html and default.css... I am leaving the rest there for now for reference.
When the problem occured I can resize the window and zoom the page and the problem remains. DOMI shows that the "missing" DIVs are in the DOM and have a specified width of 242px but that their computed width is 0px. The specified style for these DIVs have "display:table; float:left;", yet their children are "display:block". With a debug build I get: ###!!! ASSERTION: How'd we get a floated inline frame? The frame ctor should've dealt with this.: 'aReflowState.mStyleDisplay->mFloats == NS_STYLE_FLOAT_NONE', file nsLineLayout.cpp, line 1275 Break: at file nsLineLayout.cpp, line 1275 ###!!! ASSERTION: How'd we get a floated inline frame? The frame ctor should've dealt with this.: 'aReflowState.mStyleDisplay->mFloats == NS_STYLE_FLOAT_NONE', file nsLineLayout.cpp, line 1227
Assignee: general → nobody
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout: Tables
Ever confirmed: true
OS: Windows XP → All
QA Contact: general → core.layout.tables
Attached image page viewed locally
Screenshot of same page when viewed locally
Attached file Testcase
Frame dump: TableOuter(div)(1)... [state=00010004] [content=0x84c73b8] [sc=0x8517928]< Table(div)(1)... [state=00010004] [content=0x84c73b8] [sc=0x85173b0]< Text(2)@0x8517d00[0,0,F] {0,0,0,0} [state=00000426] sc=0x8517cd4< "" > > > Yet the content dump looks OK. I think I've seen this problem before when the intermediate anonymous table frames fails to appear.
Keywords: testcase
Whiteboard: DUPEME
Just wanted to note though it may not be relevant that with the testcase it appears that it isn't possible to navigate away from the page and then come back to it to see it render properly where as this is possible when viewing the mcafee site as well as http://exchangecode.com/mcafee/test2.html. Also, the testcase doesn't display properly when it is local as well.
Summary: Incorrect page rendering - difference when file is local vs. on server → inserting frames does not create necessary anonymous table frames
Depends on: 148810
Boris this is a dupe, that bug 148810, is of course a diffult to fix bug. The code here goes through ContentAppended which does not handle pseudo frames *** This bug has been marked as a duplicate of 148810 ***
Status: NEW → RESOLVED
Closed: 21 years ago
No longer depends on: 148810
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: