Missing files on script tab with Firefox 30 + Firebug 2.0

[Raul Marzo]

Hi.

I've been using Firebug for debugging javascript for years, and there wasn't any problem to see the source of any file downloaded asynchronously from the script tab in Firebug, like libs using AMD. Not until I upgraded to Firefox 30 and Firebug 2.0. After the upgrade, I can't see any source files downloaded async, and debugging is completely impossible for those. As you can see in the attachments, the number of files I can choose in the script tab is nowhere close to what it was before.  

Does anybody know if is there any Firebug setting that would restore the old behaviour regarding the script tab? Otherwise I see myself having to move to Chrome, which I would like to avoid as there is always small differences between the two, and a co-worker already uses Chrome for debugging.

Thanks in advance.

Confidentiality Notice:  - This message and any attached files may contain information that is confidential and/or subject of legal privilege intended only for the use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this message in error please notify the sender immediately and delete the message.

[Michael K]

Raul,
Did you solve your problem?
Like yourself,  I am having the exact same problem. 

[Raul Marzo]

No, I couldn't. A fresh install, removing my profile, didn't help either, so I reverted to firebug 1.12. I'm afraid if this issue doesn't get solved I'll have to move to Chrome eventually...

[Kyle Dodge]

My firebug automatically updated recently and I am having the same issue, script source files are simply not showing as described in Raul's screenshots above. I had to revert to 1.12 after many failed attempts to restart, change settings, etc. Extremely frustrating that this could get through testing and into the automatic update.

[Jan Honza Odvarko]

One bug that could be related to this problem has been fixed and there is a test Firebug xpi build:
https://code.google.com/p/fbug/issues/detail?id=7521#c13

Can you try it out and let us know whether it solves your issue?

Honza

[Raul Marzo]

I just tested the build, and I now get the full list of scripts, but the original name of the scripts is not displayed as it was before, which makes it really difficult to browse the scripts or find the ones you are looking for. It also seems like some of the results correspond to evals but not to real files. 

[Jan Honza Odvarko]

On Wednesday, July 2, 2014 10:44:57 AM UTC+2, Raul Marzo wrote:

I just tested the build, and I now get the full list of scripts,

Good, that's a progress
 

but the original name of the scripts is not displayed as it was before, which makes it really difficult to browse the scripts or find the ones you are looking for.

Are you using //# sourceURL directive your dynamically evaluated scripts?
 

It also seems like some of the results correspond to evals but not to real files. 

Not sure what is this, I need a reproducible test case to more further and fix it.

Can I access your page?

Honza

[Raul Marzo]

On Wednesday, July 2, 2014 9:49:33 AM UTC+1, Jan Honza Odvarko wrote:

On Wednesday, July 2, 2014 10:44:57 AM UTC+2, Raul Marzo wrote:

I just tested the build, and I now get the full list of scripts,

Good, that's a progress
 

but the original name of the scripts is not displayed as it was before, which makes it really difficult to browse the scripts or find the ones you are looking for.

Are you using //# sourceURL directive your dynamically evaluated scripts?

I wasn't. I've tried and it seems to work (it doesn't work exactly as it used to). Thing is, I'm OK about doing this to our source code (although is a bit of a pain), but I'd prefer not to change any files from external libs (most of these scripts are part of dojo)

 

It also seems like some of the results correspond to evals but not to real files. 

Not sure what is this, I need a reproducible test case to more further and fix it.

Can I access your page?

You can try at http://app.fieldaware.com, I've just tested the login page and you'll see both cases: files with no filename and evals that doesn't correspond to files.

Honza

Thanks for the hard work. 

[Jan Honza Odvarko]

> You can try at http://app.fieldaware.com, I've just tested the login page and you'll see both cases: > files with no filename and evals that doesn't correspond to files.

OK, great

So, I loaded the page, I am seeing bunch of script files and evals (evals under e.g.: app.fieldware.com/dojoroot/dojo)

What exactly should I look at? What is "a file with no filename"?

Honza

[Eugene Choi]

I am having same problem with any version of FF 30+ && Firebug 2.0+.

i reverted back to FF 29 && Firebug 1.12.

i turned off FF's autoupdate so that it doesn't push me to FF 30.

this is very disappointing to see problems with Firebug 2.0 when previous releases haven't had a major flaw like this. I almost gave up on FF+FB for Chrome!

[Ivan Gomes]

I seem to be having some success with the latest FF and FireBug 2.0b8. You can easily install at the Firefox Addons version history page, and it doesn't require a browser restart. Has anyone found problems with this approach?

[Jan Honza Odvarko]

On Wednesday, July 2, 2014 4:49:44 PM UTC+2, Ivan Gomes wrote:

I seem to be having some success with the latest FF and FireBug 2.0b8. You can easily install at the Firefox Addons version history page, and it doesn't require a browser restart. Has anyone found problems with this approach?

@Ivan: did you also try a test Firebug build available here:
https://code.google.com/p/fbug/issues/detail?id=7521#c13

Does it solve the problem for you?

Honza
 

[Eugene Choi]

when you say some success, do you mean you can reliably use that version of the plugin, or is it hit and miss? at this point, i am content w/ rolling back to a prior version, bc i can't afford this hangup at work... i might be willing to switch if it's 100% reliable with viewing all javascript and debugging

[Ivan Gomes]

@Honza: Works wonderfully! Thank you.
@Eugene: I meant that dynamically loaded scripts were showing, but the display was different so I wasn't sure. But as of Honza's last post, I would recommend downloading the latest .XPI provided and installing it.

[Jan Honza Odvarko]

Excellent, thanks for the update!

Note that the patch will be included in the next (minor) release: Firebug 2.0.2

Honza

[Eugene Choi]

do you have an estimate when 2.0.2 will be released?

[Jan Honza Odvarko]

> do you have an estimate when 2.0.2 will be released?

Next week

Honza

[Sebastian Zartner]

I attached screenshots of what I see in the different versions of Firebug when accessing Raul's test page (https://app.fieldaware.com/login).

The first screenshot shows Firebug 1.12 on Firefox 29.0.1, the second Firebug 2.0.1 on Firefox 30.0 and the third Firebug from master branch on Firefox 31.0 Beta.

So obviously the patch in issue 7521 fixes the problem. They are just displayed differently at the moment, because parsing of sourceURLs needs to be reimplemented.

Sebastian

[Raul Marzo]

Any idea of if/when sourceURL parser reimplementation might be done? 

[Sebastian Zartner]

There's currently no time estimation, though you may want to follow issue 7201 and the related issues.

Sebastian

[ed]

I was just updated to Firefox 31.0 ESR and Firebug 2.0.3 and all the script dynamically loaded by dojo appear in the Scripts drop-down list as
dojo.js.uncompressed.js...line 16557 > eval (156)
or something similar. To make matters worse, if I manage to find the file I'm looking for I cannot set a breakpoint on any of the source lines.  The files all have
////@ sourceURL=/path/to/the/file.js
at the bottom.

Is there anything I can do? I'm dead in the water.
--ed

On Friday, June 13, 2014 9:22:50 AM UTC-4, Raul Marzo wrote:

[Eugene Choi]

Use Chrome at this point. I've pretty much given up on FF+Firebug until they play nicely. I've seen much inconsistent behavior that it's more hassle than help to live thru the problems, and just use chrome until FF+FB are good again. Who knows if it's a FF or FB problem at this point.  I'm surprised the FB developers don't see the stuff we are seeing as users, it's not that hard to reproduce

[Sebastian Zartner]

Remove two of the slashes at the beginning and you should be good to go. Source URLs generally look like this:

//@ sourceURL=/path/to/the/file.js

or

//# sourceURL=/path/to/the/file.js

Source URLs within new Function() constructs are not recognized yet, though that shouldn't affect your Dojo code.

Sebastian

[Sebastian Zartner]

Firebug is maintained by a handful of people, which simply can't check every possible configuration and therefore need your help when you stumble over a problem. If it's not hard to reproduce, then please file a bug and attach a simple test case to it, so it can be fixed.

Sebastian

[ed]

I'd love to, but it's dojo adding the ////@ sourceURL, not me.

[Sebastian Zartner]

We are using a Firefox API, which is broken for source URL definitions with four slashes. I reported that in bug 1065259.
Additionally I created issue 7656 for this in our tracker and created a patch for it (and two other issues) in issue 7201 fixing this on the Firebug side.

Sebastian

[Sebastian Zartner]

More good news, the dojo team fixed their source URL syntax a few days ago:

https://github.com/dojo/dojo/commit/06f4b6f2e4b6a57944251f7d242b6751520de937

So this problem should be gone with the next release of dojo.

Sebastian

[ed]

I hand patched my copy of dojo.js.uncompressed.js with the upcoming dojo change, replacing "////@" with "//#". There are 2 remaining issues. 

1. The source files show up in the scripts list now, but not organized by directory structure like they used to be. All the dojo loaded files show up as /path/to/dojo.js.uncompressed.js?cacheBust=11111111//path/to/my/source.js.  While not ideal, I can cope with this, since I can still search for files by name.

2. I cannot set a breakpoint an any dojo loaded file. This is a deal breaker.

[mike.er...@gmail.com]

In many scenarios (including my own), we don't have control over the version of dojo being used since it is being provided by the container that we're embedded within. Upgrading/patching dojo is not an option. 

Does this mean we simply need to wait for the next build of Firebug or is there still a dependency on FireFox and/or Dojo?  

[mike.er...@gmail.com]

Any updates on what the expected fix will include?