Closed
Bug 601890
Opened 14 years ago
Closed 14 years ago
toolkit/components/console is not packaged for firefox on xulrunner
Categories
(Firefox Build System :: General, defect)
Tracking
(blocking2.0 beta7+)
RESOLVED
FIXED
mozilla2.0b7
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta7+ |
People
(Reporter: wolfiR, Assigned: khuey)
References
Details
(Keywords: regression)
Attachments
(1 file)
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.
Updated•14 years ago
|
Blocks: devtools4b8
Assignee | ||
Comment 2•14 years ago
|
||
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•14 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.
Assignee | ||
Comment 4•14 years ago
|
||
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: --- → ?
Comment 5•14 years ago
|
||
(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.
Comment 6•14 years ago
|
||
Yup, bug 579909.
Comment 7•14 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+
Assignee | ||
Comment 8•14 years ago
|
||
Attachment #481361 -
Flags: review?(mitchell.field)
Attachment #481361 -
Flags: feedback?
Updated•14 years ago
|
Attachment #481361 -
Flags: review?(mitchell.field) → review+
Assignee | ||
Updated•14 years ago
|
Attachment #481361 -
Flags: feedback?
Comment 9•14 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+
Assignee | ||
Comment 10•14 years ago
|
||
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: 14 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
Comment 11•14 years ago
|
||
we *really* could have used a little warning before this landed.
Assignee | ||
Comment 12•14 years ago
|
||
My apologies, I thought everyone working on this stuff was CCd.
Comment 13•14 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.
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•