Closed Bug 104012 Opened 24 years ago Closed 23 years ago

table pushed out to the right to far

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.2alpha

People

(Reporter: mozbugz, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: regression, testcase, Whiteboard: [bae:20011127])

Attachments

(17 files)

WD site layout rendering starts ok as seen here, still transfering data.
94.46 KB, image/gif
Details
WD final rendered Layout
86.67 KB, image/gif
Details
Source code for page.
14.60 KB, text/plain
Details
composer Normal View
86.41 KB, image/gif
Details
Compose Show All Tags
101.32 KB, image/gif
Details
Composer Preview
86.50 KB, image/gif
Details
ie6 ok here
88.09 KB, image/gif
Details
094 milestone is ok
80.62 KB, image/gif
Details
ns 6.1 ok
106.56 KB, image/gif
Details
Rendered page from file load of above HTML in 2001100903
56.88 KB, image/gif
Details
FP source using <TBODY> tags instead of <BODY> for embedded table, renders ok from Local File.
19.21 KB, text/plain
Details
adding so FP2k source will render from bugzilla server in Mozilla from web.
19.21 KB, text/html
Details
FP shot of table layout way far out to right.
101.21 KB, image/gif
Details
closer testcase for window-1252 rendering problem on WD site.
81.75 KB, image/gif
Details
FP 2K default new blank HTML document example, conflicts with Mozilla Default ISO-8859-1
47.65 KB, image/gif
Details
adding another one for div at this from n.p.d.css : http://banjo.partitur.se/demo.html
1.32 KB, text/html
Details
view using Mozilla 12-19-09 build. - shows selection view of source tags.
94.56 KB, image/gif
Details
this is similar problem, I'm not duping bug 102800, similar, but has more problems with the page layout then this one, this also probably can produce a better testcase on this site, as I have found other bugs which exists: probably make this one a blocker for 102800. 1) Composer renders this site in Preview first time like it is suppose to be viewed and Mozilla does not. 2) Doing a reload sometimes renders page correctly. 3) Hitting Back button, then forward (which loads page from cache renders page correctly.
Attached file Source code for page. —
Attached image composer Normal View —
Attached image Compose Show All Tags —
Attached image Composer Preview —
Attached image ie6 ok here —
Attached image 094 milestone is ok —
Attached image ns 6.1 ok —
I know it is broke somewhere in between 094 landing on 9-13 and the builds I have installed on 9-26 and the builds since then are broken.. (it appears to be a possible painting of code problem with the Layout, or Parser that may have bugs landed in between.
Keywords: regression, testcase
dont know if this will be possibly affected by checking for bug 100895
I'm checking to see if another doc type helps this render.. at first glance, I'd say that currently this is a doctype quirks mode problem, or possible change in the way quirks mode has rendered in the past versus the way it renders now. Question? Does Composer add the Transitional Doctype 4.01 to every document to view it? If that is the case then it would make a difference in the way Composer views any pages or files.
hmmm this document has 2 <body> tags, might be invalid or evangelism
not just that it appears to have an imbedded html document inside itself like the the import does, not just the body tag, but more.. doesn't explain why milestones I listed work fine on this page, while the trunk is not rendering correctly.
it appears that composer does some modifications and uses the <tbody> tags and gets rid of some other code that is in view page source's view.
I also wanna say as you look at the Edit-page source, it is a Frontpage 4.0 document.. with an embedded document.. Can we find out two things before marking invalid or evangalism? 1) why the truck is not rendering this the way it should be rendered.. 2) is this an issue with the interpretation of rendering Frontpage content?
I dont think its evangalism, more like a change happened in Mozilla's painting layout on first rendering from website. As every other instance renders the page as it is suppose to look if you read all my comments and take a look at the screenshots closely.
ok, maybe mozilla played with the code since the ns6.1 and 094 landed on branch.. Frontpage 2K shot here shows whitespace or a table tags that do not calculate widths correctly while rendering. I have several more screenshots from FP for this site to back this up as a testcase.
it also appears maybe there is a problem with the render with the <TBODY> tags.. HTML4 spec, which should substite for <body> tags within a table.. as this is the case with compose had frontpage recognize these.. view page source just shows 2 body tags.. the second for the embedded page. <TBODY> for table body tags, it should have <TFOOT> for bottom and <THEAD> for the embedded table <head> code .. it appears WD didn't use these, Which I cannot verify if that is the source code from their server, (need to leach it off their server) or the fact that the parser doesn't completely understand these substitions when encountering the code that view source page produces. view page source and composer source show different code for the same page. The questions then are: 1) is Mozilla having problems rendering these tags? 2) if not, is this site using code that is view-source output we see? 3) if #2, mozilla is not substituting these tags #1 rendering logic to #2. 4) if neither #1, #2, or #3 then back to <TD width> problems or painting issue.
I pulled the Page with IE webpage saving.. and am uploading the FP source which Mozilla does render correctly with <TBODY> tags. adding attachment. #1) works.
FP source as it is not the whole website as the URL. so either mozilla has first time rendering problem with these tbody tags and embedded body tags.. or it is similar to bug 102800 where there are problems with rendering that resizes tables, width, etc.. and leaves it pushed out to the right. Not sure if we should go to dupmode yet for this, or evangalism. Because I got some more checking to do on bug 102800, which also may help me figure this out. I'll be back for more.
Summary: header table contents pushes out main table.. → table contents pushes out main table..
I found the problem.. as in bug 104013 this page uses a character coding of windows-1252. after it loads I change it back to ISO-windows-8859-1 it is fine.. this page has an embedded char code.. that is not our default.. FrontPage 4.0 produces this. This is reproducable always.. bug 102800 also uses this charset=windows-1252 if you save the webpage with IE. both bugs exhibit the same type of problems as I have narrowed down the problem with windows.1252 rendering further on the WD site as the new attachment I'll add. Bad Layout Stems from FrontPage default Charset as the next attachment you can see here.
ok, dropping the charset arguement.. I changed the memcache=0 and diskcache=0 and check cache=never so I can reproduce this better than I thought. anytime you change the character-coding mozilla appears to be loading from the cache like I noted before, and page doesn't go back to a bad render.. Is this a regression? still trying to devel deeper for tried a true testcase here. -more later.
Blocks: 102800
Summary: table contents pushes out main table.. → page rendering using its charset-windows-1252 from FP, pushs table out to right, just fine if using ISO-8859-1
Summary: page rendering using its charset-windows-1252 from FP, pushs table out to right, just fine if using ISO-8859-1 → table pushed out to the right to far
Sorry for the SPAM.. sorry, sorry, 100xsorryxeach message... Apologies for those who are recieving all that email for this one! Forgive me please.. just trying to figure this out while keeping a documentation here.. I see it is emailing everyone each time. I dont like that feature. argh.. -Dennis
maybe see if the alignment code is broken when trying to align in embedded tables with multiple width sizes.
Status: UNCONFIRMED → NEW
Ever confirmed: true
update: I seeing new info, possible change to a bug for rowspan, colspan elements on 9-19.. is changing either the nested tables inheritance of table elements for the worse or to the correct way. I've got a much narrower testcase.. if I use just the inside table I see one result, if I have a lot of the outer elements, I see Mozilla render it sometimes correctly, most of the time the same as the inner most element.. I just have to put it all together. It appears the outer elements are overriding some inner elements to render as intented. Mozilla randomly changes tables to one or more seperate tables causing it to render unintented. So as soon as I can put this all together into a multiple testcase I will give another update. I also have more screenshots to see what I'm talking about.
URL: http://store.westerndigital.com/produ... → http://store.westerndigital.com/produ...
it appears that the problem is with the div tags.. and a possible checkin in the div tag parsing.. or div tags & alignment of <img src & align="right"> and the tableborder is pushed out.. via either element overriding.. (most likely) or changes in how tables respond to this.. getting close here.
Chris, I haven't looked closely yet at the demo file.. but should get some time in here later this week.
Just at first glance at that attachment: it has a div tag.. but as you load the url in the browser you see the browser acting funny and then moving it.. I think maybe this was the problem with the www.storagereview.com bug I filed.. but maybe also similar to zdnet bug or the tweak3d.net bug.. so I'll do some more checking with those as I get time.
I'm wondering if the issue in bug 97619 that marc A. mentioned (2001-10-10 comment) about changes to transitional doctypes from using Quirks to Standard is affecting the layout regressions that maybe issues where the site is using <center> tags that override the alignment from <td>, <img src> tags, or <div> tag alignment.
just adding the doctype for transitional sometimes causes the layout to render correctly.. but it will still on clicking 'reload' several times will render incorrectly.. so a problem exists in <div> tags and <center> + alignment code.. some combination of these.. if (standards mode is used on transitional now instead of quicks) does that change the div, center, aligment tags are handled vs quirks? thanks, dennis
Target Milestone: --- → mozilla1.2
just an update, no changes yet to mozilla have changed this behavior on this wd page.
adding: <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=22274#c98">#98</a> for the jumpyness comment I see in this page as well.
western digital changed their webpage recently at the above URL.
I looked through the attached code and the constructs of the code is awful -- missing closing tags, stray closing tags, etc. Also, the TD that contained the Product Description section shows that the text is really within an image, since the image displayed to the right, that may have accounted for the table cell to be pushed out. Running the document through Composer undoubtedly cleaned this page up so it would make sense that it rendered correctly. Since the site has been updated, and knowing that the site was just poorly marked up, I would like to mark this as wontfix
Whiteboard: [bae:20011127]
this is a recent view of the page as mozilla's composer shows the borders of the tags for the images & tables.
beppe, I was trying to look thru the code to see if that was the real problem here.. like in bug 91432. (code block alignment) to see if that is why this page renders badly.
oops, make that bug 91423.
Attachment #54028 - Attachment mime type: text/plain → text/html
Impossible to triage the problem. beppe@netscape.com agrees in comment 42. Site has been redesigned, no clear testcase. The best one, attachment 53043 [details], looks even worse in Opera. Markup is tag soup de luxe. Dennis, if you still can reproduce the problem in a current build - please open a new bug report, thanks. --> WORKSFORME
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: