squeezed the life out of this GIF, but you get the point on the screenshot - see how it exploded outwards.
62.75 KB, image/gif
413 bytes, text/html
441 bytes, text/html
461 bytes, text/html
80 bytes, image/gif
399 bytes, text/html
5.05 KB, patch
|Details | Diff | Splinter Review|
BuildID: 2000091508 sorry if this is a duplicate, was unable to find another quite this extreme. also, not sure if it belongs to HTML Tables or not ... go to URL ... page loads and appears to load correctly - yet when finishes loading the page table content explodes outward/horizontally. Reproducible: Always Steps to Reproduce: 1. go to url 2. watch as page loads 3. page finishes loading 4. page reflows as table expands horizontally (make sure your screen res is a large one - i'm running 1280x1024) Actual Results: page reflows onload Expected Results: table should stick to defined, fixed width not sure what in the HTML is doing this
Not seeing this w. 2000092212 on Win95. Page may have changed, of course, between the reporter's visit and my own.
WFM on Windows 2000 , Build :2000091920 also wfm in Windows 98 with build : 2000081008
Downloaded 2000092212 on my Win98 box. Still does it for me. Does it now both on WinNT4 and Win98 for me. Odd it isn't doing it on other's machines. Will create an attachment - screen shot.
Created attachment 15384 [details] squeezed the life out of this GIF, but you get the point on the screenshot - see how it exploded outwards.
Created a smaller testcase. Image is causing the reflow problem. Need to see if this has already been reported - will confirm bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This testcase is behaving differently than on my local machine but if you reload, the image placeholder expands after a minute and forces the table movement.
Dup of #40892?
it looks to me like the ALT text is doing it on the above attachment, am I wrong? this would be after an image that was supposed to load didn't load ... but neither the star wars site nor a page i have in development (which i can't show as it is for a client and unfinished - still might be able to distill test case from it though, maybe tomorrow) has a broken image. Am i making that up (misunderstanding)? The test case doesn't have HEIGHT and WIDTH defined, however I just saved the file off and it seems to do the same thing with the H/W attributes defined as well. Then I took out the ALT text and the page reflowed, however my guess is that the spec would read that the table should reflow if the image does not exist (help?). With the ALT text it reflows to fit the words (i made the alt text a long run on sentence and it did just that), and without the ALT text it reflows to simply collapse. That may indeed be correct behavior. I can look at it further, but the question is - are these two different bugs? I could be mistaken, but I think we need a test case with legit graphics.
The testcase was broken down from the 'starwars' page. On that page, the image I broke that down to (img/new.gif) had no dimensions or alt tag. I will try to provide a revised testcsae.
I am attaching another testcase (essentially the same but with an image that has dimensions and 'alt'). When I first load this page, the second column 'jumps' to the right. But if I reload, it 'jumps' back. This is the behavior I saw on the starwars page. The difference is that after the reload, it does not jump to the right again - in order to see that behavior you need to open the page anew. So this may or may not be the same problem. The problem is clearly evident on the 'startwars' page.
Nominating this for RTM. This is a serious reflow problem.
Adding rmt+. PDT, this really needs to be fixed for rtm. It is basic stuff and could affect any nested table that has a width specified.
Status: NEW → ASSIGNED
Priority: P3 → P2
Whiteboard: [rtm+] fix-in-hand (need to run regression tests)
Whiteboard: [rtm+] fix-in-hand (need to run regression tests) → [rtm need info] fix-in-hand
Changing to rtm+.
Whiteboard: [rtm need info] fix-in-hand → [rtm+] fix-in-hand a=buster, r=dcone
rtm++ per discussion with PDT. Must land on the trunk one day ahead of the branch.
Whiteboard: [rtm+] fix-in-hand a=buster, r=dcone → [rtm++] fix-in-hand a=buster, r=dcone
Whiteboard: [rtm++] fix-in-hand a=buster, r=dcone → [rtm++] fix-in-hand a=buster, r=dcone (fixed on tip)
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Whiteboard: [rtm++] fix-in-hand a=buster, r=dcone (fixed on tip) → [rtm++] fix-in-hand a=buster, r=dcone
Verified fixed on Win, Mac and Linux with 10_11 branch build. Added vtrunk keyword.
Verified Fixed on trunk builds. Testcases and starwars site look good and don't "explode" at end of load. linux 101808 RedHat 6.2 win32 101804 NT 4 mac 101804 Mac OS9 Setting bug to Verified and removing vtrunk keyword
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.