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

RESOLVED FIXED in mozilla2.0b7

Status

()

Core
Build Config
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: wolfiR, Assigned: khuey)

Tracking

({regression})

Trunk
mozilla2.0b7
All
Linux
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(blocking2.0 beta7+)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

Updated

7 years ago
Duplicate of this bug: 601907

Updated

7 years ago
Blocks: 594225
The solution here is to build toolkit/components/console/hudservice (going off of memory here) in tier_app and change the hudservice loading location.

Comment 3

7 years ago
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.
Yup, bug 579909.
Depends on: 579909

Comment 7

7 years ago
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+
Created attachment 481361 [details] [diff] [review]
Move toolkit/components/console/hudservice to tier_app, move files from toolkit.jar to browser.jar
Attachment #481361 - Flags: review?(mitchell.field)
Attachment #481361 - Flags: feedback?
Attachment #481361 - Flags: review?(mitchell.field) → review+
Attachment #481361 - Flags: feedback?

Comment 9

7 years ago
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
Last Resolved: 7 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.

Comment 13

7 years ago
(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.
You need to log in before you can comment on or make changes to this bug.