Closed Bug 63945 Opened 24 years ago Closed 23 years ago

Reflowproblems with nested tables and images

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: sicking, Assigned: karnaze)

Details

(Keywords: testcase)

Attachments

(5 files)

Image 1 for testcase
11.72 KB, image/gif
Details
Image 2 for testcase
1.86 KB, image/gif
Details
Image 3 for testcase
821 bytes, image/gif
Details
html for testcase
536 bytes, text/html
Details
second testcase (could be a different bug)
572 bytes, text/html
Details 
Try reloading the attachment a few time. I'm able to get a couple different 
strange layouts; images stacking on top of each other, tablesizes beign totally 
off etc. However everything falls into place if the browserwindow is resized. 
The testcase contains the following code:

<html>
  <body>
    <table border="1">
      <tr>
        <td style="background: url(top_background.gif);">
          <table border="0" cellpadding="0" cellspacing="0">
            <tr>
              <td><img src="top_main.gif"></td>
              <td><img src="top_icons.gif"></td>
            </tr>
          </table>
        </td>
      </tr>
    </table>
  </body>
</html>
This next one is a bit harder to reproduce but the differance is that it can't 
be fixed by just resizeing the window.  It can however be fixed by changing the 
textsize...

Try reloading until the images with the icons gets shifted about 70 pixels to 
the right. The table and the big image should have correct position and size.

One other thing I noted with both theese testcases is that painting dosn't work 
correctly for images and borders which has wrong position.
Keywords: mozilla1.0
This could be a duplicate of bug 63703.

Seeing this on linux asweel... Changing to All,All
OS: Windows 98 → All
Hardware: PC → All
Might be related to bug 63445
This seems different from bug 63445 and bug 63703.  Moving to HTMLTables.  Is
this a regression?
Assignee: clayton → karnaze
Component: Layout → HTMLTables
QA Contact: petersen → chrisd
Don't know if it's an regression. First time testing it in mozilla.

If anybody is having problems with reproducing the second testcase I could 
probobly make one that is more easily reproduced but requires an bigger 
testcase. Get this behaviour 95% of the time on the original page (which is 
behind our firewall)
It seems that when an image arrives late, the table is build up with that second
image first, waiting for that first image to arrive. After receiving the second
image, the table need to be redrawn, but that doesn't happen! You can trigger a
redraw by resizing the browser window.

And as tested this, the smaller image almost always was first received, you may
see that image at the left first. Then it's covered by the larger (second) image.
Just run the HTML testcase 50 times with build 2001011204 and without a single
leyout error! Is that fix of bug 63445 helping out here?
QA contact update
QA Contact: chrisd → amar
Maybe this is related to problems with layout on http://www.slo-lanparty.com/
page. Just visit the page (create account if you need ) and just visit forum
(labled Tabla in top menu). When a long page loads it the zext is almost always
moved up a bit in each table cell. If I just hit the back button and then
forward button the problem is gone and page is OK as it redraws I guess.

I'm using Mozilla 2001072108 on Windows XP RC1 (it happens also in Windows 2000
SP2).
CCing myself.
Is the overlapping of the text and image in 
http://www.csmonitor.com/todays_paper/graphical/today/index.html
caused by this bug? This has been happening quite a long time.
I have also seen similar layout oddity in Niketown's (www.nike.com) web shop.
Strangely, opening the same source in Composer with supplementing img src URLs
works perfectly OK.
Keywords: testcase
Both testcases WFM win98 2001-08-30-03. Amar could you verify this bug?
 Hirata Masakazu: the url is not working. I generally dont like this kind of
atttaching url's to a bug 'may be it is the same problem?'. If you can extract a
testcase from the url, attach it to the bug, ( I know you can do it). Otherwise
we will have these zombie bugs for ever in the bug database, because they are
unclosable. My comment is just an incarnation of the one issue per bugreport idea.

Bernd 
Well I have to say tha it WFM on www.slo-lanparty.com. I visit the page
regularly and the problem doesn't show anymore. So it looks it's been fixed.
Will try other links a bit.
Marking wfm based on comments.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
 The URL provided by hirata masakazu does not work.. and 
http://www.slo-lanparty.com/ works fine on 2001-10-08 builds
Marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: