1. Run FB
2. Open Console Tab
3. Make some code in console of FB like

function myTestFunction(){ alert("foo"); }

4. Execute it via Ctrl+Enter
5. Go to Scripts Tab. In list of all scripts I expect the new just created script with name like 1,2,3...etc. but there are nor any such scripts in that list. And of cause I can't debug function myTestFunction because I can't find it.

In previous versions 1.8 this scheme worked perfectly. Any of such script appeared in Scripts Tab in Scripts List under sequence numbered name.

Issue appears under any version of Firefox and any versions of OS.

refered to http://groups.google.com/group/firebug/browse_thread/thread/bd8ada616b1b354c/979aff79df9443f8?show_docid=979aff79df9443f8

Seems this was broken in r12003.

Sebastian

r12003, really?

Honza

Well, I tried it by jumping back and forth in the history and r12001 didn't have that problem. Though when trying to get a clean working copy of r12003 or r12001 my Subclipse striked and got stuck in the process, so I couldn't verify. I'll try it on another PC later.

Sebastian

And? What's about solution?

Sorry for the delay. r12003 is really the culprit. I checked it now with the github repo and got the same result.

https://github.com/firebug/firebug/commit/b3fb058354966731e7a0a1046b64fbab16755963 is working. https://github.com/firebug/firebug/commit/7d4670926b4975b52a92593639c942b6be46316f not.

The "firebug_rjs" is used within the URI of the injected scripts, which was removed in the named revision.

Sebastian

And what I have to do?

At the moment nothing. The info in comment 7 was an internal comment for the developers. We'll tell you, if we need more info from you.

Sebastian

I'm so sorry for my insistence but it's very important function, because of it I can not debug any changes in scripts until reload a page. It's terrible for me.

chrome:// urls are filtered by debugger, so because of r12003 commandLineExposed is not shown anymore :(

one way around it is to map commandlineExposed to its' file:// url in require.load where paths for modules with changed locations are modified

fix committed in https://github.com/firebug/firebug/commit/311f59ef10f87d68ddb27478bbdc924b253f50a0 used data: uri instead

thanks to Sebastian for investigating this, (and shame on me for breaking:(

Now they are displayed again inside the Location Menu. Thanks for that, Harutyun!

Though one question: Do the scripts have to be named that way? I mean now they are prefixed by "FirebugEvaluate=function(t,w)w.eval(t)". Formerly they were prefixed with the page name. See the attached screenshots.

Sebastian

for the version before r12003 they are prefixed by consoleExposed instead of page name (like on your screenshot in Comment 7) with which version do you get output like script_executed_via_command_line_before.jpg? maybe there was some code for beautifying names before that?

i think the best will be if they are prefixed with "FirebugConsole"

That was FB 1.7.3.

Sebastian

FB 1.7 was injecting console into the page, but that was quite fragile.

we can add comment into the string but can't get rid of "=function(t,w)w.eval(t)" part:( do you think it's worth to add special handling for this names into the script popup?

I vote yes! Grouping them under "command line" (maybe with the evaluated expressions as part of their names) seems like much better UX.

I agree with Simon. We should even make the style inside the Location Menu different to the other items to distinguish it even more.

Sebastian

Grouping them under "command line" ( +1

we should even make the style inside the Location Menu different to the other items to distinguish it even more. Could we have a quick mockup? :-)

Honza

Could we have a quick mockup? :-) Here it is. Simple but recognizable. We could also decide to move the "Command Line" entry to another place (i.e. bottom or top of the menu) for further distinction. Besides that the tooltip shouldn't show the URL or code but instead give a hint that the displayed entry was created through the Command Line.

Sebastian

Hm, the popup includes internal scripts run by the auto-completer.

Where? This shouldn't happen.

Sebastian

When I type something like 'document...' (->document.URL.trim.call) in the command line, I see something like 6 new scripts of the form data:FirebugEvaluate=function(t,w)w.eval(t)/event/seq/N in the script dropdown. (The number 6 could be reduced, if needed; the code was written under the assumption that we should avoid touching content objects and thus evaluates a lot of things in content scope.)

we can add argument to eval to use "data:" protocol only when user evaluates something

I am seeing problems with the FBTest of issue 5033 related to stepping over the Command Line code and I thought it could be related to your changes for this issue, Harutyun. I already wrote Honza about this but I thought you might be able to help here.

Sebastian

Amirjanyan: what happens if you revert https://github.com/firebug/firebug/commit/311f59ef10f87d68ddb27478bbdc924b253f50a0

And:

1) Run manually: console/5033/issue5033 2) Run console/api/profile.js 3) Do you see unresponsive script dialog?

I am also marking as blocker, this problem slows done more automated tests I think.

Honza

And of course, you need to revert r12003 to properly test, I guess. Honza

So, I can confirm that the test issue 5033 works again (the whole test suite runs actually much better) if: https://github.com/firebug/firebug/commit/311f59ef10f87d68ddb27478bbdc924b253f50a0 is reverted.

I don't know if there is different solution and/or if we should report a new JSD bug (given that JSD1 won't be there for long). One question, can we just change createChromeBlockingFilters (firebug-service.js) instead of using data uri?

Anyway, I see following problems in the current implementation:

1) Enable Console and Script 2) Load Load http://getfirebug.com/tests/content/branches/1.10/console /5033/issue5033.html 3) Execute following in the Console (testFunction function is implemented on the page)

function myTestFunction() { testFunction() }

4) Go to the Script panel, pick the new entry in the location list, create breakpoint at lines 4 and 10 (why it's twice there?) to break when testFunction() is executed.

5) Switch to the Console panel and execute myTestFunction(), debugger doesn't break -> BUG

6) Create a breakpoint within testFunction() and execute "myTestFunction()" in the console.

7) Debugger breaks

8) Select the Stack side panel and pick myTestFunction, no source code is displayed in the Script panel -> BUG

Amirjanyan, we need you :-)

Honza

The test-suite is really blocked by the problem so, I reverted: https://github.com/firebug/firebug/commit/311f59ef10f87d68ddb27478bbdc924b253f50a0

at:

https://github.com/firebug/firebug/commit/3b7fbadb8a99a4d700fa88eae998e47adb3b413e

We really need to find a solution for this (perhaps also reverting r12003)

Honza

looks like chrome sources were filtered only in https://github.com/firebug/firebug/blob/master/trace/FBTrace/chrome/firebug/content/js/scriptPanel.js#L1214 and my data hack wasn't needed

If I remove the following lines:

if (compilationUnit.getURL().substr(0, 9) == "chrome://") return false;

I still don't see scripts (executed in the command line) in the Script panel's location list.

Honza

seems like scrtipt filter toggle is buggy too if you set it to all disable,enable firebug you should see it there are also some intermittent bugs like sometimes stack panel is empty or debugging buttons not shown but that happens for normal scripts too https://github.com/firebug/firebug/pull/12 reverts r12003 should i merge it to master or you can test first?

Sebastian, could you please test the pull-request and check if it helps?

Honza

I'd still be better if we could selectively make only some CommandLine.evaluate scripts show up in the script panel (comment 23, etc.). Same flag could also fix issue 5432, probably.

I have tested the patch, but I am still seeing the same problems described in Comment 28

Honza

Sorry for not writing earlier. I also already tested the patch before and let the test suite run and several tests were still failing with it.

Sebastian

Issue 5757 has been merged into this issue.

Issue 2602 has been merged into this issue.

Issue 5777 has been merged into this issue.