toolkit/components/console is not packaged for firefox on xulrunner

RESOLVED FIXED in mozilla2.0b7

Status

defect
RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: wolfiR, Assigned: khuey)

Tracking

({regression})

Trunk
mozilla2.0b7
All
Linux
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 beta7+)

Details

Attachments

(1 attachment)

This is a regression caused by bug 593328.

+ifeq (browser,$(MOZ_BUILD_APP))
 PARALLEL_DIRS = hudservice \
 	$(NULL)
+endif

If hudservice is Firefox specific it should live in browser.
Otherwise it needs to be enabled and shipped in xulrunner to provide everything needed by Firefox.
Duplicate of this bug: 601907
Blocks: devtools4b8
The solution here is to build toolkit/components/console/hudservice (going off of memory here) in tier_app and change the hudservice loading location.
Ideally, we'd either have a web console that works as a real toolkit component (ideally), or move it into browser/ (not so good but still clean), but I think doing any of those is a post-FF4 target only, as we need to get a release done.

For now, I guess the slightly hacky solution of Kyle is probably the best thing we can do there.
AIUI the eventual goal is to make the webconsole a toolkit component.  If that's not true, perhaps we should bite the bullet and move it to browser/ now.

Regardless, this needs to block at least final.
blocking2.0: --- → ?
(In reply to comment #4)
> AIUI the eventual goal is to make the webconsole a toolkit component.  If
> that's not true, perhaps we should bite the bullet and move it to browser/ now.
> 
> Regardless, this needs to block at least final.

Actually, I believe that the console has been slated to be moved to browser/ for some time now. Following up in #devtools to make sure.
At this point in the cycle, we are not going to move the code in the source tree. But I don't see any reason we shouldn't move the code into tier_app right now. Is there a reason I'm missing?
blocking2.0: ? → betaN+
Attachment #481361 - Flags: review?(mitchell.field) → review+
The new location of HUDService.jsm makes this an extension-visible change, needs to block beta7 and land on the relbranch.
blocking2.0: betaN+ → beta7+
Landed on default
http://hg.mozilla.org/mozilla-central/rev/3880abf71fc2
and GECKO_20b7pre_20101006_RELBRANCH
http://hg.mozilla.org/mozilla-central/rev/329afdc371fb
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
we *really* could have used a little warning before this landed.
My apologies, I thought everyone working on this stuff was CCd.
(In reply to comment #12)
> My apologies, I thought everyone working on this stuff was CCd.

The b7 blocker status came up at 6 am PDT. then it was checked in at 9:30. alas, I missed this happening until it landed.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.