dynamically changing document.getElementById("xxx").style.display fails on large page

RESOLVED FIXED

Status

()

Core
DOM: CSS Object Model
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: Stefan A. Möller, Assigned: jst)

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910

Altering the visibility of a <div> using
document.getElementById("xxx").style.display
does not work if the size of the <div> is larger than the browser window.

This is a regression, it used to work with Mozila 1.1


Reproducible: Always

Steps to Reproduce:
compare the next two attachments
(Reporter)

Comment 1

16 years ago
Created attachment 98873 [details]
it works with a small <div>
(Reporter)

Comment 2

16 years ago
Created attachment 98874 [details]
...but it doesn't work with a large <div>

Comment 3

16 years ago
confirmed with linux trunk build 20020912
regression between trunk builds 2002082008 and 2002082105
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
roc, any ideas?  Looks like we never paint the new div for some reason.... (and
the content area goes dead).
This is a scrolling problem and I've seen it in a few other places. When the
scrolled area is resized it doesn't automatically get scrolled back into view.
What you're seeing is "below the bottom of the document".

It would be great if someone could narrow down the regression by downloading
trunk builds to find the smallest window in which the bug appeared. That would
probably make this pretty trivial to fix. Andrew, Stefan, can you do that?
(Reporter)

Comment 6

16 years ago
> It would be great if someone could narrow down the regression by downloading
> trunk builds to find the smallest window in which the bug appeared.
It seems Andrew has done that already!? See comment #3
I'll bet a donut that it was the checkin for bug 163800.

Comment 9

16 years ago
ahh... then the same thing is happening in bug 163970, right?

Comment 11

16 years ago
Should be fixed by backout checkin for bug 163800
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.