599292 - Make single pref and commandline flag to enable extension-developer stuff

Status: RESOLVED WONTFIX

(Toolkit Graveyard :: Error Console, enhancement)

Description

[Ben Bucksch (:BenB)]

We have a whole slash of prefs and knobs that need to be turned in a profile to make a Firefox or xulrunner app useful for debugging chrome code (firefox/thunderbird or the xulrunner app or an extension). These are described at
https://developer.mozilla.org/en/Setting_up_extension_development_environment

We even add new ones once in a while, which can be nasty for devs who don't know that, so some constancy would do good.

Worse, for proper testing, it's often necessary to start with a fresh profile. Either to debug install/setup code, or because many errors are only seen in new profiles, or because your dev profile doesn't expose a bug for some reason but everybody else runs into it, something that happens often but you don't want that. So, a single testing cycle often involves creating profiles, I did that dozens of times in 1-2 days.
With that in mind, *anything*, even just clicking a confirmation dialog away, even more so having to set a pref (via about:config or copying a user.js) that needs to be done is a time-waster and highly annoying.

---

That's why a single pref "I'm a dev" would be useful, that enables all these things mentioned there: JS console, chrome error reporting, dump() output on JS console and OS console, disables XUL/JS caches etc.. (I do not think it should start venkman, because that's very slow.)

To help with profiles, a commandline flag would be useful. I have to start my app with "firefox -no-remote -jsconsole -P" anyway, so instead I would use "firefox -no-remote -dev -P" or similar.

mbeltzner asked me to file this bug, on m.d.a.firefox, thread "Replace the Error Console with the Web Console?". Maybe this should be component XULRunner, though.

Comment 1

[Philip Chee]

I think this is extension fodder personally. Teds Extension Developers Extension already does something like this. Some one could take this and update it for trunk.

Comment 2

[Ben Bucksch (:BenB)]

Philip, without wanting to be insulting, but you're missing the point. *Anything* that I need to do is too much. Surely installing an extension is way too much. The whole point here is that it's super-easy and always works in any Mozilla.

Comment 3

[Dave Garrett]

I currently use a master user.js file which I symlink to from my dev profiles:

user_pref("browser.dom.window.dump.enabled", true);
user_pref("devtools.inspector.enabled", true);
user_pref("devtools.errorconsole.enabled", true);
user_pref("dom.report_all_js_exceptions", true);
user_pref("extensions.logging.enabled", true);
user_pref("javascript.options.showInConsole", true);
user_pref("javascript.options.strict", true);
user_pref("nglayout.debug.disable_xul_cache", true);
user_pref("nglayout.debug.disable_xul_fastload", true);

A command switch to flip all but the cache disabling ones might be a good idea. For mucking with the cache, I'd want a separate switch there.

One extra benefit of a switch would be that when the same profile is run again but without the switch you could have those prefs turned off as easily as on.

Comment 4

[Rob Campbell [:rc] (:robcee)]

that's a good starter list, Dave. Thanks.

Ben, do you have any others we're missing here?

Comment 5

[Ben Bucksch (:BenB)]

Nope, that list covers those on the wiki page
https://developer.mozilla.org/en/Setting_up_extension_development_environment
mentioned above and those that I also set myself in my dev profiles.

I'd probably leave out "dom.report_all_js_exceptions" (after reading the relevant page) to not get spammed with expected exceptions, but disabling code cache is critical, because I got burned many times.

Comment 6

[Rob Campbell [:rc] (:robcee)]

moving to Firefox::DeveloperTools. I think it makes more sense there than ErrorConsole.

Comment 7

[Rob Campbell [:rc] (:robcee)]

I'm sorry, scratch that. This should probably be in Toolkit so other projects can make use of it. Moving back.

Comment 8

[Dave Garrett]

(In reply to comment #5)
> I'd probably leave out "dom.report_all_js_exceptions" (after reading the
> relevant page) to not get spammed with expected exceptions

If you want that left out, then JS strict is similar with warnings.

Ok, then I think we're up to 3 switches:

-dev-mode
  browser.dom.window.dump.enabled=true
  devtools.inspector.enabled=true
  devtools.errorconsole.enabled=true
  extensions.logging.enabled=true
  javascript.options.showInConsole=true

-strict-js-errors
  dom.report_all_js_exceptions=true
  javascript.options.strict=true

-disable-xul-cache
  nglayout.debug.disable_xul_cache=true
  nglayout.debug.disable_xul_fastload=true

Seeing as prefs already exist for everything touched here, I don't think adding meta prefs would be that helpful and I'm leaning towards just wanting new command switches.

Comment 9

[Dave Garrett]

(In reply to comment #6 & comment #7)
Maybe Toolkit -> Startup and Profile System? If not, it'll either go under Error Console or General; there's really no perfect place to put this under.

Comment 10

[Rob Campbell [:rc] (:robcee)]

yeah, devtools seemed nice because it's at least appropriate, but too firefoxy. Maybe toolkit general.

I also agree that adding "meta-switches" is just going to further confuse this and add still more preferences that people have to twiddle. The goal is a single pref to turn on that enables the most useful features.

I'm somewhat reluctant to turn on strict-mode, as it can be very verbose and impact performance, though can point you to some errors in code. We can also ignore javascript.options.showInConsole because that was defaulted to true with the patch that turned off the error-console by default in Firefox.

Comment 11

[Dave Garrett]

(In reply to comment #10)
> ignore javascript.options.showInConsole because that was defaulted to true with
> the patch that turned off the error-console by default in Firefox.

Oh, good. I didn't know that. I just added that to the MDC note for Gecko 2.0:
https://developer.mozilla.org/en/Setting_up_extension_development_environment#Development_preferences

Comment 12

[Marc-Aurèle DARCHE]

browser.dom.window.dump.enabled(In reply to comment #2)
>
> *Anything* that I need to do is too much. Surely installing an extension is
> way too much. The whole point here is that it's super-easy and always works
> in any Mozilla.

I would really love to see the proposed switches be added for the same reason.

And hopefully at the same time those switches are added it, wouldn't it be good to have the "browser.dom.window.dump.enabled" preference defined by default? It would save the few seconds it takes to define a new boolean property. Of course the addition of this preference by default is not as interesting as having the proposed new flags, but is in the same spirit and could go in the same commit.

A very respectful thank you for the people who might work on this!

Comment 14

[Brian Grinstead [:bgrins]]

The Error Console has been removed in favor of the Browser Console (see Bug 1278368), and the component is going to be removed.  If this bug is also relevant in the Browser Console, please reopen and move this into Firefox -> Developer Tools: Console.

Comment 15

[Zack Weinberg (:zwol)]

I am mass-reopening and re-componenting every single one of the Toolkit:Error Console bugs that appear to have been closed without anyone even *glancing* at whether they were relevant to the Browser Console.

If you want to close a whole bunch of old bugs -- FOR ANY REASON -- it is YOUR RESPONSIBILITY to check EVERY SINGLE ONE OF THEM and make sure they are no longer valid.  Do not push that work onto the bug reporters.

(It's okay to close bugs that haven't been touched in years when they don't have enough information for you to figure out whether the problem is still relevant to the current software - the reporter probably isn't coming back to clarify.  But that is the ONLY situation where it is okay.)

(I'm going to have to do this in two steps because of the way the "change several bugs at once" form works.  Apologies for the extra bugspam.)

Comment 16

[Brian Grinstead [:bgrins]]

The Error Console feature was removed entirely from the tree in Bug 1278368 and the bugzilla component is now being removed. We’ve migrated bugs that seem to also affect the Browser Console into the devtools component, please move this over if it was missed.