In order to be able to create a usable testcase for bug 416896, the Mochitest profile needs the DOM Inspector installed, because the mochitest would need to make use of DOM Inspector code. From robcee on IRC: " mw22: we might have to either tweak some buildoptions and/or profile settings mozconfigs are checked into mozilla/tools/buildbot-configs/testing/unittest "

Sorry, never mind, the testcase in bug 416896 doesn't need to have DOM Inspector installed, so this bug is at least no high priority, as there is no use case for it yet.

from the irc, 07:17 < gavin|> DOMi's useful bits are all in layout know afaik marking WONTFIX until a suitable reason comes up to include DOMi in the builds.

Yeah, it doesn't seem like it was on branch builds, but it is now on trunk. Maybe it would still be useful for chrome tests or something.

it's possible, but until you come up with one, I'm going to leave this off. :)

I'd certainly find it useful for examining DOMs in tests while writing/debugging them; next time I hit this problem (I have before but assumed it was a mozconfig problem, not a test-harness thing) I'll fix this, I guess.

Ok, optimistically reassigning it to you then ;)

I think sdwilsh just made it impossible, since DOM Inspector no longer ships by default and installing it in the mochitest profile is impossible since that profile is generated on the fly... unless I'm missing something?

Sigh; if so, that's not helpful for debugging Mochitests since there's that whole restart thing needed to install the extension. Do we respect --enable-extensions=inspector, and if so in that case could it be installable?

(In reply to comment #7) > I think sdwilsh just made it impossible, since DOM Inspector no longer ships by > default and installing it in the mochitest profile is impossible since that > profile is generated on the fly... unless I'm missing something? Hey - I wasn't the one who disabled it! (In reply to comment #8) > Sigh; if so, that's not helpful for debugging Mochitests since there's that > whole restart thing needed to install the extension. Do we respect > --enable-extensions=inspector, and if so in that case could it be installable? That should still work.

Moving a bunch of Core :: Testing bugs to Testing :: Mochitest to clear out the former, which is obsolete now that we have more specialized categories for such bugs; filter on the string "MochitestMmMm" to delete all these notifications.

(In reply to comment #9) > (In reply to comment #8) > > Sigh; if so, that's not helpful for debugging Mochitests since there's that > > whole restart thing needed to install the extension. Do we respect > > --enable-extensions=inspector, and if so in that case could it be installable? > That should still work. Bad news, folks. I'm working with a chrome mochitest, with a patch for bug 496681 and Inspector built by default. I'm seeing DOM-I enabled in the Add-ons Manager, but the extension's chrome.manifest is apparently not in effect: the Tools menu isn't showing the DOM Inspector menu item (from tasksOverlay-ff.xul), and window.open("chrome://inspector/content/", "_blank", "chrome"); gives me the following error: No chrome package registered for chrome://inspector/content/inspector.xul I'm testing with Shiretoko 3.5 beta 4 code.

My use case, by the way, is in something similar: writing a chrome mochitest for a XBL binding I'm crafting in an extension. I can't get chrome.manifest registration for that either.

[12:28] <WeirdAl> normally, extensions get registered, and then the app restarts to pick up on those new extensions... [12:28] <WeirdAl> we have a bypass path that says "Don't restart" - but it also means new extensions don't apply on that pass [12:29] <WeirdAl> what if we had a command-line argument, --update-and-shutdown, that did only the registration part, and then shut itself down? This could mean extensions are available for mochitests, that gdb can attach to the right process, etc. [12:30] <WeirdAl> we'd start the app twice (once with --update-and-shutdown for registration, once normally for whatever purpose we're trying to test / debug). [12:33] <Mossop> See bug 378422, also just use the -silent argument [12:38] <WeirdAl> ah :) [12:39] <WeirdAl> how might I apply that scenario to bug 417355? [12:40] <WeirdAl> (chrome mochitest for extensions) [12:41] <Mossop> ... by doing exactly what you described already [12:42] <WeirdAl> I was thinking along the lines of modifying runtests.py [12:42] <WeirdAl> (Mochitests have their own profiles, don't they?) [12:43] <Mossop> automation.py would probably be better, but whichever [12:43] <WeirdAl> well, I don't know Python, so it's kinda moot

runreftest.py does exactly this, since it installs the reftest bits as an extension.

This is a shot-in-the-dark patch, basically copying code from runreftest.py as Ted suggested. I have confirmed it works by writing a test file for an extension (not DOM Inspector, unfortunately). If you want a test for an extension, we'll need an extension to test with that's already in the tree and built by default.

(In reply to comment #15) > This is a shot-in-the-dark patch, basically copying code from runreftest.py as > Ted suggested. This is the idea, yes. Though I did not know about this report and filed bug 504480, which has a more complete patch. > I have confirmed it works by writing a test file for an extension (not DOM > Inspector, unfortunately). If you want a test for an extension, we'll need an > extension to test with that's already in the tree and built by default. In SeaMonkey, it works for CZ, DOMi and Venkman (at least) ;-)