Closed Bug 169987 Opened 22 years ago Closed 18 years ago

{inc}swapping div tags via javascript from css display 'block' to 'none' leaves following div in wrong place.

Categories

(Core :: Layout: Block and Inline, defect)

defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: danielt, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1

If I set up three div tags such that the first and second are swapped by a
javascript function that switches their display from none to block and back
again, the third winds up out of place. Swapping the third's display to none and
then back to block causes it to go where it belongs.

Reproducible: Always

Steps to Reproduce:
1.Look at the test case I'll provide.
2.Click on the top red block. It should disapear, and the green one take it's
place...
3.But the bottom block is no longer right underneath it!
4.Click on the bottom block, and it will go to the correct position.

Actual Results:  
The bottom block moves to an incorrect position.

Expected Results:  
The bottom block should remain in the same place (more or less).

I've tested this on Linux in Mozilla 1.1, and also on today's (Sept. 20th's)
nightly build on Win XP--same results. I originally came across the problem
because I'm using this sort of block/none display for a left menu tree that
expands or collapses on mouse clicks. I'm a little puzzled because it's only
recently that I've seen this problem--I'm not sure if I started seeing it
because of something I changed, or because there was some sort of regression bug
that popped up in Mozilla. Anyway, the test case I'll submit seems to indicate
that it's not just a code problem (although I won't be too surprised if I get an
email back pointing out some silly mistake I've made--sorry in advance if that's
the case).
Attached file testcase
This is the test case I said I would post. Instructions in my original bug
posting, or on the testcase page itself. Hope this works--er, doesn't work. :
).
Resizing the window makes the red box display at the correct position.

--> Layout
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: Linux → All
Hardware: PC → All
Priority: -- → P3
Target Milestone: --- → Future
There's also a problem on our website at http://www.ebuconnect.de

1. Click on "Produkte"
2. Clock on "Elektronischer Geschäftsverkehr"
3. The submenu doesn't appear because the 2nd menu won't move down, instead the
text will be written over the 2nd menu item
4. Resize the window, the menu appears
5. Click on "Management Info"
6. Then "Geschäftsprozessmodelle"
7. The menu here works perfect (same code)
Severity: normal → major
If you resize the window, the browser reflows. 

Try it: using the testcase, click the red div, see the gap, then resize the window.

This bug became in 1.3a. I was hoping it was passing; now I see it is here to
stay in 1.3.


Here's another example of the bug in mozilla:
URL: http://dhtmlkitchen.com/js/images/preload/index.jsp
steps to reproduce:

1) go to url
2) try to use menutree
3) notice that menus don't open

The behavior on my site is different, but very similar.
I noticed that AnimTree does not work only when I have position: fixed for the
tree root.

changing position: fixed fixes my problem.
.
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
Priority: P3 → --
QA Contact: cpetersen0953 → ian
Summary: swapping div tags via javascript from css display 'block' to 'none' leaves following div in wrong place. → {inc}swapping div tags via javascript from css display 'block' to 'none' leaves following div in wrong place.
Target Milestone: Future → ---
This looks like a duplicate of bug 138142

[Sorry, I have no idea how to take that further.]

Reasons for thinking so are that if a DIV container is inserted around the 3
DIVs in the test case, behavior is quite different, as described for 138142. In
this case there is simply no previous element providing a margin.
I can't see any change in the behaviour of testcase between
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)
The testcase in attachment 100046 [details] seems to be working fine both
in SeaMonkey 2006120701 (pre reflow branch) and 2006120801 (post) on Linux.

The left navigation menu at http://www.ebuconnect.de seems to work fine in
2006120701 but not in 2006120801. (FWIW, the menu works in Opera9, Webkit
and IE7).  I filed bug 363329 on that.

-> WORKSFORME
Status: NEW → RESOLVED
Closed: 18 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: