User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008032605 Minefield/3.0b5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008032605 Minefield/3.0b5pre the exact description with screenshots can be found at http://atos.wmid.amu.edu.pl/~d138460/fire2/path.html this is just a short desc: 1. putting a form to a <td> with innerHTML property 2. filling the edit box, works fine 3. innerHTML = ''; 4. putting the form for the second time, filling the edit boxe 5. there is a button on the form, its onclick equals "alert('first:'+theForm1.field1.value); fun1(); clearForm1();" the fun1 is a function that accesses theForm1.field1.value and alerts it. unexpectedly the first alert prints the correct value that you typed in the edit box, but the second alert (in function 'fun1()') prints the value that was present in the edit box when you were filling the form for the first time (point 2.) Reproducible: Always you can find the code and try it yourself: http://atos.wmid.amu.edu.pl/~d138460/fire2/bug.html http://atos.wmid.amu.edu.pl/~d138460/fire2/bug.js

Reporter, are you still seeing this issue with Firefox 3.6.x or later in safe mode? If not, please close. These links can help you in your testing. http://support.mozilla.com/kb/Safe+Mode http://support.mozilla.com/kb/Managing+profiles

Yes, the bug is still present in Firefox 3.6.6 in safe mode. However the links don't work anymore so i've attached a zip archive with all files needed to reproduce the bug. The bug is quite easy to workaround BUT ONLY WHEN YOU KNOW IT EXISTS and it's hard to find it yourself cause the buggy behavior doesn't appear when you fill the form for the first time. I found it when was trying to make a web-app with two panels next to each other and with panel content loaded dynamically (ajax+innerHTML)

When I follow the steps in path.html, I get a JS exception when I click the "check for bug" button the second time. This happens because theForm1 is a nodelist, not a node. Presumably we're failing to remove the old form (as with 1.9.2) and also adding the new one... In any case, the key is that document.theForm1 is updated to the new form (or on trunk has the new form added) while window.theForm1 is not. Is the global scope polluter caching stuff somehow?

I filed bug 579079 on the trunk behavior for document.theForm1.

Yeah, looks like the global scope polluter just caches the value in a slot and doesn't update it. This only affects quirks-mode pages that make use of the global scope polluter, so not sure how much it matters in practice.... We might be able to fix it, at the cost of a perf hit, by making the polluter resolve as shared props and having the getter actually get instead of relying on the slot.

We should just make the gsp a proxy.

Fixed in bug 895758.