Need DOM Inspector extensions enabled in the Mochitest profile

RESOLVED DUPLICATE of bug 504480

Status

RESOLVED DUPLICATE of bug 504480
11 years ago
9 years ago

People

(Reporter: martijn.martijn, Assigned: WeirdAl)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

11 years ago
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
"
(Reporter)

Updated

11 years ago
No longer blocks: 416896
(Reporter)

Comment 1

11 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 3

11 years ago
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. :)

Comment 5

11 years ago
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Reporter)

Comment 6

11 years ago
Ok, optimistically reassigning it to you then ;)
Assignee: nobody → jwalden+bmo
Status: REOPENED → NEW
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

11 years ago
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.

Comment 10

10 years ago
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.
Component: Testing → Mochitest
Product: Core → Testing
QA Contact: testing → mochitest
Version: Trunk → unspecified
(Assignee)

Comment 11

10 years ago
(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.
(Assignee)

Comment 12

10 years ago
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.
(Assignee)

Comment 13

10 years ago
[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.
(Assignee)

Comment 15

10 years ago
Created attachment 383886 [details] [diff] [review]
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.
Attachment #383886 - Flags: review?
(Assignee)

Updated

10 years ago
Attachment #383886 - Flags: review? → review?(jwalden+bmo)
(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) ;-)
Assignee: jwalden+bmo → ajvincent
Status: NEW → RESOLVED
Last Resolved: 11 years ago9 years ago
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → DUPLICATE
Version: unspecified → Trunk
Duplicate of bug: 504480
Attachment #383886 - Attachment is obsolete: true
Attachment #383886 - Flags: review?(jwalden+bmo)
You need to log in before you can comment on or make changes to this bug.