User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 If you write a Javascript expression in the Javascript console, then clear the output in the JS Console and then try to evaluate the same expression, it doesn't work. Reproducible: Always Steps to Reproduce: 1. Go to the Javascript console 2. Write a Javascript expression 3. Hit Enter or clic Evaluate (it works) 4. Clic the Clean button, but do not erase or modify the Javascript expression 5. Hit Enter or clic Evaluate Actual Results: Firefox doesn't evaluate the Javascript expression until you alter it. If you just delete some character(s) and then write again the same characters in the same position, it still won't evaluate the Javascript expression. You need to add or remove characters. Expected Results: The Javascript expression should have been evaluated without needing to alter it

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040327 Firefox/0.8.0+ It's enough to type a command like "alert('');" and hitting Enter one time. This alert box is displayed. All further evaluations doesn't open the alert box - nothing happens. -> QA

Does this happend in Mozilla suite as well?

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316 -> Javascript Console

*** Bug 292107 has been marked as a duplicate of this bug. ***

*** Bug 316994 has been marked as a duplicate of this bug. ***

*** Bug 326182 has been marked as a duplicate of this bug. ***

This was almost fixed by bug 328932 already.

bz, is the result of multiple setting the src of a frame even deterministic?

Yes. The second set will generally cancel the load of the first set, unless the second set is a javascript: URI which produces no output.

Comment on attachment 229229 [details] [diff] [review] always reset the iframe bz says that the right way to force a frame to reload is to set its location rather than muck about with src attributes. (Make sure you don't loop infinitely.)

This works for me and doesn't require resetting the iframe to about:blank at all.

Comment on attachment 229229 [details] [diff] [review] always reset the iframe Whoops, typo ;-)

Comment on attachment 233499 [details] [diff] [review] use contentDocument.location Won't this regress bug 158475? >+ iframe.contentDocument.location = "javascript: " + code; Nit: Evaluator.location should work here.

Comment on attachment 233505 [details] [diff] [review] use Evaluator.location I was sure I had reproduced bug 158475 earlier this week but it was getting late so I couldn't debug it at the time. Then yesterday I couldn't reproduce it, so I guess the patch is fine after all. Sorry for the delay.

Comment on attachment 233505 [details] [diff] [review] use Evaluator.location I guess I have two questions about this patch: A) Can you also remove blank.html now? Seems like removing the only remaining reference after applying this patch (attribute on the iframe in console.xul) doesn't have any negative effects, though I'm not sure why it doesn't regress bug 328932. B) Looks like it relies on the global scope polluter (or something equally magical) to reference Evaluator directly, is that really desirable?

(In reply to comment #16) > A) Can you also remove blank.html now? There's one further instance (which should keep bug 328932 from regressing): http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/components/console/content/console.xul&rev=1.11&mark=132#129 > B) Looks like it relies on the global scope polluter See comment #13 and the first line of function displayResult. Seems like reason for a different bug should we want to change this.

(In reply to comment #17) > (In reply to comment #16) > > A) Can you also remove blank.html now? > > There's one further instance (which should keep bug 328932 from regressing): > http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/components/console/content/console.xul&rev=1.11&mark=132#129 That's what I meant by "the only remaining reference", removing it doesn't regress that bug. Neil has theorized that that other bug was fixed on the trunk by bz's security architecture work, so I think you should just remove that reference and the file itself (from xpfe too).

(In reply to comment #18) > That's what I meant by "the only remaining reference" I misread. This patch now additionally removes all references to blank.html and - while I'm at it - also fixes bug 369097 for both Toolkit and XPFE (which apparently didn't get the fix for bug 342662 to begin with).

Comment on attachment 264477 [details] [diff] [review] removed blank.html (and fixed bug 369097) >Index: toolkit/components/console/content/console.js > function evaluateTypein() > { > var code = gTextBoxEval.value; > var iframe = document.getElementById("Evaluator"); >- iframe.setAttribute("src", "javascript: " + encodeURIComponent(code)); >+ iframe.location = "javascript: " + code.replace(/%/g, "%25); Missing the closing quote here. You also need to use iframe.contentDocument.location if you're going to take this approach. This change should be applied to both toolkit and xpfe versions, to keep them in sync (Neil said he was fine with this on IRC). You also need to remove the blank.html entries from jar.mn. With those changes, I'll r+.

Oh, and I was wanting to patch that escaping bug too, but I think it's best to leave that to a separate patch in the other bug (I can r+ quickly and land it for you).

(In reply to comment #20) > Missing the closing quote here. Good catch. > iframe.contentDocument.location [...] both toolkit and xpfe versions Done. > You also need to remove the blank.html entries from jar.mn. Done.

(In reply to comment #21) > leave that to a separate patch Missed that one. Now done.

Comment on attachment 264483 [details] [diff] [review] without the patch for bug 369097 Hrm, this doesn't behave properly with javascript: URLs that don't cause a new load, e.g. evaluating ("const a=1;", "a;", "a;") will result in ("", 1, error) when it should result in ("", error, error), but I guess that happens currently too because displayResult() is only called onload. This was mentioned in bug 158475 comment 4, so I guess it's known. Might be worth filing a bug on it anyways.

(In reply to comment #24) Filed bug 380422 for this issue.

mozilla/toolkit/components/console/jar.mn 1.7 mozilla/toolkit/components/console/content/console.js 1.7 mozilla/toolkit/components/console/content/console.xul 1.12 mozilla/toolkit/components/console/content/blank.html removed mozilla/xpfe/components/console/resources/content/console.js 1.26 mozilla/xpfe/components/console/resources/content/console.xul 1.38 mozilla/xpfe/components/console/resources/content/blank.html removed

Oh, and mozilla/xpfe/components/jar.mn 1.90, too (oops).

v. with CVS build of Thunderbird version 3.0a1 (20070511)