417355 - Need DOM Inspector extensions enabled in the Mochitest profile

Status: RESOLVED DUPLICATE of bug 504480

(Testing :: Mochitest, defect)

Description

[Martijn Wargers (dead)]

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
"

Comment 1

[Martijn Wargers (dead)]

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.

Comment 2

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

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.

Comment 3

[Martijn Wargers (dead)]

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.

Comment 4

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

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

Comment 5

[Jeff Walden [:Waldo]]

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.

Comment 6

[Martijn Wargers (dead)]

Ok, optimistically reassigning it to you then ;)

Comment 7

[Boris Zbarsky [:bzbarsky]]

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?

Comment 8

[Jeff Walden [:Waldo]]

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?

Comment 9

[Shawn Wilsher :sdwilsh]

(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.

Comment 10

[Jeff Walden [:Waldo]]

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.

Comment 11

[Alex Vincent [:WeirdAl]]

(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.

Comment 12

[Alex Vincent [:WeirdAl]]

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.

Comment 13

[Alex Vincent [:WeirdAl]]

[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

Comment 14

[(not currently active) Ted Mielczarek]

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

Comment 15

[Alex Vincent [:WeirdAl]]

Attachment: patch, v1

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.

Comment 16

[Serge Gautherie (:sgautherie)]

(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) ;-)