573382 - No chrome package registered for chrome://inspector/content/tasksOverlay.xul

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Karsten Düsterloh]

When starting SeaMonkey trunk¹ with builtin DOMI, the DOMI entry in Tools->Web Development is missing. 

Error console says:
-------------------------------------------------------------------------
Warning: Warning: Unrecognized chrome registration modifier 'xpcnativewrappers=no'.
Source File: file:///home/kd/projekte/mozilla/mozilla.org/obj/sr/mozilla/dist/bin/extensions/[e-mail]/chrome.manifest
Line: 19

No chrome package registered for chrome://inspector/content/tasksOverlay.xul

Warning: Failed to load overlay from chrome://inspector/content/tasksOverlay.xul.
Source File: chrome://messenger/content/messenger.xul
Line: 0
-------------------------------------------------------------------------

DOMI won't work even if started manually, since chrome://inspector/content/inspector.xul isn't registered either.



¹ Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a6pre) Gecko/20100620 SeaMonkey/2.1a2pre

Comment 1

[Boris Zbarsky [:bzbarsky]]

OK, so is there _any_ way to have an xpcnativewrappers=no package on trunk (with the modifier just ignored) and on branches?  If not, it sounds like we need two separate inspector XPIs....

Comment 2

[Philip Chee]

Since on trunk xpcnativewrappers is always on, why can't trunk just totally ignore this flag i.e. treat it as a NOOP?

Comment 3

[Boris Zbarsky [:bzbarsky]]

That's my question, yes.

Comment 4

[Justin Wood (:Callek)]

SeaMonkey test_idcheck.xul was failing due to this; (couldn't open the window, therefore was not understanding that the window closed);

Disabled that part of the test in http://hg.mozilla.org/comm-central/rev/3a70e023b8a3

Comment 5

[Justin Wood (:Callek)]

(In reply to comment #4)
> Disabled that part of the test in
> http://hg.mozilla.org/comm-central/rev/3a70e023b8a3

and correctly in: http://hg.mozilla.org/comm-central/rev/24bcb8811f93

Comment 6

[Justin Wood (:Callek)]

Attachment: Allow xpcnativewrappers to not fail-out on trunk

I decided to keep a warning message for this, though modified to actually indicate the truth. (Its not technically "unrecognized" anymore)

Comment 7

[Justin Wood (:Callek)]

Attachment: Allow xpcnativewrappers to not fail-out on trunk

...and qref before attaching.

Comment 8

[Justin Wood (:Callek)]

Attachment: Allow xpcnativewrappers to not fail-out on trunk (v2)

bz, I'd love if this could land before SeaMonkey's official freeze later today. So a faster review is VERY appreciated.

Comment 9

[Justin Wood (:Callek)]

Marking blocking; assuming my testing goes good we can avoid this holding up the release even if its not reviewed by landing on relbranch, even with that being a PITA.

Comment 10

[Robert Kaiser]

I landed attachment 453021 [details] [diff] [review] as http://hg.mozilla.org/mozilla-central/rev/f6cf82daa5bd on COMM193a5_20100623_RELBRANCH so we could spin the SeaMonkey 2.1a2 with a working DOM inspector.

This means it's now "only" blocking DOMI usage on trunk, but not the 2.1a2 release.

Comment 11

[Benjamin Smedberg]

I'm fine with this in principle, but I don't want to take it until bug 568691 lands to avoid merge conflicts.

Comment 12

[Boris Zbarsky [:bzbarsky]]

That landed.  Can we get this reviewed and in so Inspector works again on trunk?

Comment 13

[Justin Wood (:Callek)]

Comment on attachment 453021 [details] [diff] [review]
Allow xpcnativewrappers to not fail-out on trunk (v2)

...needs updating since e10s and the ChromeRegistration changes that just landed, I'll tackle it tomorrow.

Comment 14

[Justin Wood (:Callek)]

Attachment: Allow xpcnativewrappers to not fail-out on trunk (v3)

This is basically the same patch, but it moved files and is adjusted for bitrot; I did correct a few whitespace nits of my own in the area where I am patching as well.

Comment 15

[Justin Wood (:Callek)]

Attachment: Allow xpcnativewrappers to not fail-out on trunk (v4) [Checked in: Comment 17]

Choosing Mossop as a reviewer since he said he could tackle this during his trip on tuesday, if ben didn't beat him to it.

Comment 16

[Dave Townsend [:mossop]]

Comment on attachment 456132 [details] [diff] [review]
Allow xpcnativewrappers to not fail-out on trunk (v4) [Checked in: Comment 17]

Looks good

Comment 17

[Ian Neal]

Comment on attachment 456132 [details] [diff] [review]
Allow xpcnativewrappers to not fail-out on trunk (v4) [Checked in: Comment 17]

http://hg.mozilla.org/mozilla-central/rev/735cd721df02

Comment 18

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)
> (In reply to comment #4)
> > Disabled that part of the test in
> > http://hg.mozilla.org/comm-central/rev/3a70e023b8a3
> 
> and correctly in: http://hg.mozilla.org/comm-central/rev/24bcb8811f93

Then, can the test be reenabled now ?

Comment 19

[Justin Wood (:Callek)]

(In reply to comment #18)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Disabled that part of the test in
> > > http://hg.mozilla.org/comm-central/rev/3a70e023b8a3
> > 
> > and correctly in: http://hg.mozilla.org/comm-central/rev/24bcb8811f93
> Then, can the test be reenabled now ?

rs+=me if anyone wants to push a test re-enable for this.

Comment 20

[Robert Kaiser]

(In reply to comment #19)
> > Then, can the test be reenabled now ?
> 
> rs+=me if anyone wants to push a test re-enable for this.

Pushed as http://hg.mozilla.org/comm-central/rev/0315482debe4