User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 Since v2.0.5, the Javascript Object view pane doesn't show all the properties I was used to see. And even the number of properties is erratic. In comparison with v2.0.4, it likely has to do with those XPCNativeWrappers and the modifications introduced by the bug #533599. Reproducible: Always I was able to regain a correct display by appending a " xpcnativewrappers=no" to line 4: "content..." of the chrome.manifest file. Note: afterwards, I saw there is already the same line, position ln 16, with that option. Probably now redondant, but it works. May be there is another way, cleaner, to switch this wrap mode ?

Adding that would break trunk, no? Blake? Or can we add it back and trunk will ignore it? It looks like the unwrap() stuff never landed on branches, right? Wasn't it supposed to?

Comment on attachment 448037 [details] [diff] [review] mrbkap says this is safe and will just get ignored on trunk r=sdwilsh

> mrbkap says this is safe and will just get ignored on trunk But Boris! I'm getting this error on trunk: Warning: Warning: Unrecognized chrome registration modifier 'xpcnativewrappers=no'. Source file: file:///C:/T1/hg/objdir-sm/mozilla/dist/bin/extensions/inspector@mozilla.org/chrome.manifest Line: 14 Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100610 SeaMonkey/2.1a2pre

(In reply to comment #8) > But Boris! I'm getting this error on trunk: > > Warning: Warning: Unrecognized chrome registration modifier > 'xpcnativewrappers=no'. > Source file: > file:///C:/T1/hg/objdir-sm/mozilla/dist/bin/extensions/inspector@mozilla.org/chrome.manifest > Line: 14 This is going to be expected and will continue to happen as long as DOMi supports older versions of gecko.

> But Boris! I'm getting this error on trunk: Error or warning? Things are still working correctly, no? The fact is that we made an incompatible change on trunk. We can either ship an addon that works on both branches and trunk but warns on trunk, or we need to ship separate addons for branches and trunk.

Perhaps I should mention that I'm getting some follow on errors as well: Error: inspectDOMDocument is not defined Source file: chrome://inspectorwidget/content/inspectthis.js Line: 5 ---------- Warning: Failed to load overlay from chrome://inspector/content/tasksOverlay.xul. Source file: chrome://navigator/content/navigator.xul If I add an extra line to the manifest e.g. content inspector jar:chrome/inspector.jar!/content/inspector/ content inspector jar:chrome/inspector.jar!/content/inspector/ xpcnativewrappers=no The errors go away.

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

Uh... that's really odd. sdwilsh, any idea what's going on here? I did test this on trunk before I pushed and I don't recall seeing any of those issues...

(In reply to comment #11) > Error: inspectDOMDocument is not defined > Source file: chrome://inspectorwidget/content/inspectthis.js > Line: 5 This isn't the DOM Inspector AFAIK, but may be related to the message below. > ---------- > Warning: Failed to load overlay from > chrome://inspector/content/tasksOverlay.xul. > Source file: chrome://navigator/content/navigator.xul > If I add an extra line to the manifest e.g. > content inspector jar:chrome/inspector.jar!/content/inspector/ > content inspector jar:chrome/inspector.jar!/content/inspector/ > xpcnativewrappers=no But this would break non-trunk builds. (In reply to comment #12) > No chrome package registered for chrome://inspector/content/tasksOverlay.xul That is also odd... Did chrome registration change recently on trunk?

ccing Benjamin for that last question. Good catch on the inspectorwidget thing!

We removed support for xpcnativewrappers=no

Yes, but we don't need it supported. We just need its presence to be ignored (on trunk).

FYI, I'm getting a bunch of similar warnings from toolkit.manifest however these don't seem to prevent overlays from toolkit from loading.