Closed
Bug 234319
Opened 21 years ago
Closed 14 years ago
document.write("<img ....>") inside a table does not expand a surrounding div
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mozilla, Unassigned)
References
()
Details
Attachments
(2 files)
User-Agent:
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
This only seems to happen if the page isn't cached (so once it's cached it works
fine but shift-reload breaks it again). This problem did not exist in Firebird
0.7, so the bug was introduced between 0.7 and 0.8.
In the example code at http://www.nexusuk.org/moztest/test1.html there is a div
with a table inside it. Inside the table there is some javascript that uses
document.write() to display an image. The div tag has a style that sets
overflow:hidden. When the page is displayed, it should display a "Get Firefox"
banner, but the div doesn't seem to expand to accomodate the image, so the image
overflows and gets hidden by the overflow:hidden style.
There is another test page at http://www.nexusuk.org/moztest/test2.html whcih
does exactly the same, except the document.write() also outputs some text. The
text expands the div correctly, so the top of the image is visible.
Reproducible: Always
Steps to Reproduce:
1. Go to the test URI
2. If the page displays correctly (the "Get Firefox" banner is displayed) then
use shift-reload to clear it from the cache.
3.
Actual Results:
The contents of the div were not displayed, so I get a blank page.
Expected Results:
The div should expand to include the whole contents, so the page should display
the "Get Firefox" banner.
I have seen this bug on several different systems running different versions of
RedHat and Fedora linux. I have also been told that it affects Mozilla 1.6 but
have not confirmed this. The systems I've tested on have Athlon XP 1900+ and
2100+ CPUs.
The problem only presents itself when the page isn't cached, so <blind guess> it
looks like it could be rendering the page before it's finished getting the image
from the webserver and not rerendering it once it's finished getting the image.
With the image in the cache, it would already have the image there before
rendering the page.</blind guess>
| Reporter | ||
Comment 1•21 years ago
|
||
Confirmed that the bug is also in the Windoze version of Firefox 0.8.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Comment 2•21 years ago
|
||
not specific to Firefox
Assignee: firefox → general
Component: General → Browser-General
Product: Firefox → Browser
QA Contact: general
Version: unspecified → Trunk
| Reporter | ||
Comment 3•21 years ago
|
||
| Reporter | ||
Comment 4•21 years ago
|
||
| Reporter | ||
Comment 5•21 years ago
|
||
Attached the 2 test cases linked in the original bug report and changed the OS
and component.
Component: Browser-General → JavaScript Engine
OS: Linux → All
Comment 6•21 years ago
|
||
Confirming in firefox 0.8 20040223 Linux. There are a lot of overflow bugs in
Layout:Tables so that may be a better component (but this bug apparently does
not occur unless you use javascript to create the img).
Also note the attached testcases are broken because the img url in them is
wrong. The original url shows the bug though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 7•21 years ago
|
||
This is not a JS engine bug.
/be
Component: JavaScript Engine → Browser-General
| Reporter | ||
Updated•21 years ago
|
Component: Browser-General → DOM
Updated•16 years ago
|
Assignee: general → nobody
QA Contact: general → general
Comment 8•14 years ago
|
||
Perhaps Henri could shed some light on this bug.
Comment 9•14 years ago
|
||
I downloaded the first test case, supplied an image higher than the line height and was able to see the whole image.
WFM. (Maybe [fixed by the html5 parser] in case the old one didn't notify properly in this case or something.)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
| Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•