325189 - Document not re-rendered after appendChild or removeChild

Status: RESOLVED WORKSFORME

(Core :: Layout: Floats, defect)

Description

[Mark H. Granoff]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

I have a form in which I include a DIV block, e.g

<div id="thefields">
</div>

This DIV contains one or more DIVs containing 3 input fields.

Below the "thefields" DIV block are buttons to add or delete rows (using appendChild and removeChild, respectively). The appendChild operation indeed adds a row, but the page is not re-rendered resulting in the the added nodes being obscured.

Interstingly, if the window is resized (just slightly) the contents of the window "jump" into place, as they should appear.

It is worth noting that this works as expected in Mozilla 1.7.11.

Here is some code:



Reproducible: Always

Steps to Reproduce:

Actual Results:  
The browser window does NOT re-render (until the window is resized manually by dragging an edge or corner) leaving added elements obscrured by other elements already present or leaving white space where removed elements were (rather than closing the white space by moving lower elemnts up).

Expected Results:  
The browser window should re-render to accomodate the added or removed nodes.

This may be related to bug https://bugzilla.mozilla.org/show_bug.cgi?id=324083

Comment 1

[Martijn Wargers (dead)]

Please attach a testcase or give an url that shows the bug.

Comment 2

[Mark H. Granoff]

I am working on a reproducable example for you.

I should note that when I said this was not a problem in Mozilla 1.7.11, I was slightly mistaken. In fact, it WAS a bug in Mozilla as well BUT I was able to find a workaround that forced the window to be re-rendered, which does not seem to have the same effect in Firefox. That workaround was:

    document.body.style.display = 'none';
    document.body.style.display = 'block';

Thanks.

-Mark

Comment 3

[Mark H. Granoff]

Here is a URL that reproduces the bug: http://tbs.granoff.net/ff-newevent.php

Here's what to do:

1. Go down to where you see the item 'Online Registration?' and check the box. The row of fields below the checkbox will become enabled. Below that are two buttons, 'More' and 'Fewer'. 

2. Click the 'More' button. A new row of input fields will appear (as expected), pushing the 'More' and 'Fewer' buttons down, but these buttons are now obscured by the next input field for 'Fee per person'.

3. If you now grab an edge or corner of the window and resize ever so slightly, the window elements "jump" into their correct spot.

Note that the code on this page includes the workaround I mentioned previously which sets document.body.style.display to 'none' and back to 'block'. But, removing this code has no effect on the problem.

-Mark

Comment 4

[Martijn Wargers (dead)]

Attachment: testcase

Ok, I managed to minimise the bug into this, based on the url in comment 3.
In the testcase I've added some comments that you could use as a workaround.
(although removing the <br> also seems to solve the bug).

Comment 5

[Martijn Wargers (dead)]

For the workaround, you should use the border property, because outline is not supported in Mozilla1.7 (-moz-outline only).

This could very well be a duplicate.

Comment 6

[Mark H. Granoff]

Nice work shrinking my example to something more manageable!

Your suggestion (in the example) to mess with the border seems no worse than the hack I had previously. :-) It looks like you're doing that to the element just after the DIV containing the cloned element.

I apologize if this problem is in fact a duplicate; I did do some searching but honestly I figured this was pretty obscure and I wasn't sure if the bugs I found were the same issue or not. I figured it wouldn't hurt to enter it.

Any idea when it might be fixed, duplicate or not? :-)

Thanks for your attention. Much appreciated.

-Mark

Comment 7

[Martijn Wargers (dead)]

(In reply to comment #6)
> Any idea when it might be fixed, duplicate or not? :-)
It will be fixed when it will be fixed ;-)
It could be within one week or within 5 years.

Comment 8

[Walter K.]

Is this fixed now? I cannot reproduce in FF 7.0.1.

Comment 9

[Martijn Wargers (dead)]

Yeah, seems like it is fixed now.

Comment 10

[Mark H. Granoff]

Seems to be fixed. Looks like the prediction in Comment 7 on "5 years" was right. ;-)

Thanks for the follow-up.

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

It was actually fixed between Firefox 2 and Firefox 3.