Error Console evaluates commands only one time

VERIFIED FIXED in mozilla1.9alpha5

Status

Toolkit Graveyard
Error Console
--
minor
VERIFIED FIXED
14 years ago
a year ago

People

(Reporter: Pau Garcia i Quiles, Assigned: Simon Bünzli)

Tracking

Trunk
mozilla1.9alpha5

Details

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

14 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: bugzilla
Summary: Javascript console doesn't evaluate after clicking "Clear" button → Javascript console evaluates commands only one time

Comment 2

14 years ago
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
Component: General → JavaScript Console
Product: Firefox → Browser
Version: unspecified → Trunk

Comment 4

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

Updated

12 years ago
OS: Windows XP → All

Comment 5

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

Updated

12 years ago
QA Contact: bugzilla → js-console

Comment 6

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

Updated

11 years ago
Summary: Javascript console evaluates commands only one time → Error Console evaluates commands only one time
(Assignee)

Comment 7

11 years ago
Created attachment 229229 [details] [diff] [review]
always reset the iframe

This was almost fixed by bug 328932 already.
Assignee: bross2 → zeniko
Status: NEW → ASSIGNED
Attachment #229229 - Flags: superreview?(neil)
Attachment #229229 - Flags: review?(mconnor)

Comment 8

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

Comment 9

11 years ago
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 10

11 years ago
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.)
Attachment #229229 - Flags: superreview?(neil) → superreview+
(Assignee)

Comment 11

11 years ago
Created attachment 233499 [details] [diff] [review]
use contentDocument.location

This works for me and doesn't require resetting the iframe to about:blank at all.
Attachment #229229 - Attachment is obsolete: true
Attachment #233499 - Flags: superreview?(neil)
Attachment #233499 - Flags: review?(mconnor)
Attachment #229229 - Flags: review?(mconnor)

Comment 12

11 years ago
Comment on attachment 229229 [details] [diff] [review]
always reset the iframe

Whoops, typo ;-)
Attachment #229229 - Flags: superreview+ → superreview-

Comment 13

11 years ago
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.
(Assignee)

Comment 14

11 years ago
Created attachment 233505 [details] [diff] [review]
use Evaluator.location
Attachment #233499 - Attachment is obsolete: true
Attachment #233505 - Flags: superreview?(neil)
Attachment #233505 - Flags: review?(mconnor)
Attachment #233499 - Flags: superreview?(neil)
Attachment #233499 - Flags: review?(mconnor)

Comment 15

11 years ago
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.
Attachment #233505 - Flags: superreview?(neil) → superreview+
(Assignee)

Updated

11 years ago
Attachment #233505 - Flags: review?(mconnor) → review?(gavin.sharp)
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?
(Assignee)

Comment 17

10 years ago
(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).
(Assignee)

Comment 19

10 years ago
Created attachment 264477 [details] [diff] [review]
removed blank.html (and fixed bug 369097)

(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).
Attachment #233505 - Attachment is obsolete: true
Attachment #264477 - Flags: review?(gavin.sharp)
Attachment #233505 - Flags: review?(gavin.sharp)
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+.
Attachment #264477 - Flags: review?(gavin.sharp) → review-
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).
(Assignee)

Comment 22

10 years ago
Created attachment 264482 [details] [diff] [review]
fixed breakage

(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.
Attachment #264477 - Attachment is obsolete: true
(Assignee)

Comment 23

10 years ago
Created attachment 264483 [details] [diff] [review]
without the patch for bug 369097

(In reply to comment #21)
> leave that to a separate patch

Missed that one. Now done.
Attachment #264482 - Attachment is obsolete: true
Attachment #264483 - Flags: review?(gavin.sharp)
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.
Attachment #264483 - Flags: review?(gavin.sharp) → review+
(Assignee)

Updated

10 years ago
Blocks: 380422
(Assignee)

Comment 25

10 years ago
(In reply to comment #24)
Filed bug 380422 for this issue.
No longer blocks: 380422
Whiteboard: [checkin needed]
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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Target Milestone: --- → mozilla1.9alpha5
Oh, and mozilla/xpfe/components/jar.mn 	1.90, too (oops).
v. with CVS build of Thunderbird version 3.0a1 (20070511)
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey

Updated

8 years ago
Component: Error Console → Error Console
Product: SeaMonkey → Toolkit
QA Contact: error-console → error.console
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.