Not a security bug.
Can you attach a reduced Testcase showing your Issue? https://bugzilla.mozilla.org/attachment.cgi?bugid=646845&action=enter Did it work in Fx 3.6? What is the last Beta of Fx 4 it worked okay?
I'm having this same problem in Firefox 5.
Created attachment 545171 [details] Test Case This is a test case for the issue described in this ticket. To reproduce the issue click on the purple button. A JQuery dialog will open. Enter in some text and click okay. Click on the purple button again. This time enter in some additional text and click cancel. Click on the purple button again and you will see that the text you entered when you clicked cancel is still there. It should not be there.
Confirmed the Behavior of Comment 4 Testcase against Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110711 Firefox/8.0a1 ID:20110711030829 Google Chrome 14/Opera Next is as expected. Last good nightly: 2010-06-05 First bad nightly: 2010-06-06 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b219912edfec&tochange=ac1ed3f6b2e7 => Bug 567701/Bug 534785?
Ehsan, could you take a look?
Here's what's happening here. When the textarea gets a new frame, we add a script runner for PrepareEditorEvent, and *before* that script runner is called, the textarea loses its frame again, which makes the PrepareEditorEvent::Run method called later a no-op, so we lose the editor's current value along the run. I think I have a fix for this at hand, but I really want to get a minimized testcase for this, but I really don't know how to create reframes like that (i.e., reframing the creating a frame for the textarea, destroying it and creating it once again while under the same script blocker).
Created attachment 546614 [details] [diff] [review] Patch (v1) This is the fix. Ideas about how to create a minimized testcase for this are appreciated!
Comment on attachment 546614 [details] [diff] [review] Patch (v1) r=me
6 years ago