306108 - Content frame empty in chatzilla extension

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Bill Gianopoulos [:WG9s]]

The chatzilla extension does not work correctly in this:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050826
Firefox/1.6a1

and later builds.

It worked fine in this build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050825
Firefox/1.6a1


It launches correctly, does not show any errors in the JavaScript console.
The main content portion of the chatzilla window is blank.  Otherwise it appears
to function normally.

Comment 1

[Bill Gianopoulos [:WG9s]]

This appears to be a regression from the checkin for bug 302276.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This probably needs to be fixed inside chatzilla (by turning off
xpcnativewrappers or by not doing whatever it is that it's doing that's not
supported with xpcnativewrappers).  Though if we can figure out just _what_ that
is, that would be helpful for determining whether we also need a bug on wrappers.

Comment 3

[James Ross]

I worked out what it was yesterday. It's anything inside the content window, is
just invisible.

Basically, *anything* that goes near contentWindow (or presumably
contentDocument) will need to use whatever-the-heck-the-special-property-is to
get at the real contents, and even then I wouldn't be surprised if a few other
bits still fail.

Comment 4

[James Ross]

wrappedJSObject seems to be the magical property. Good luck to whoever is stupid
enough to try and fix this.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> It's anything inside the content window, is just invisible.

Yes, but _why_?  All that stuff has display:none, so apparently an error
somewhere caused us to not set the display properly; the question is where that
error was.

> Basically, *anything* that goes near contentWindow (or presumably
> contentDocument)

Or you can turn xpcnativewrapper of completely for chatzilla. But I'm a little
surprised anything at all fails.  Does chatzilla do any of the things listed at
http://developer.mozilla.org/en/docs/XPCNativeWrapper#Limitations_of_XPCNativeWrapper
?

James, I need a bit of help here because you do know the chatzilla code and I
don't.  If something in XPCNativeWrapper is broken, I'd really like to fix it. 
If it's just a matter of chatzilla wanting to use things in that "limitations"
list, it can either use wrappedJSObject as you suggested or make the one-line
change to disable XPCNativeWrappers, as I understand things....

Comment 6

[Boris Zbarsky [:bzbarsky]]

Until we have an idea of why this is breaking with XPCNativeWrapper, requesting
blocking; we really don't want to ship bugs in XPCNativeWrapper itself if we can
avoid it.

Comment 7

[James Ross]

Ok, I can't see anything on that list that is related to use, but the list is
not very clear. I'll explain exactly what ChatZilla is doing, and see if that helps.

The output area is set up as a <xul:browser> element, which by default is told
to load "chrome://chatzilla/content/output-window.html" (I expect it starts off
with about:blank, but we then use loadURI on it IIRC). It can also load any
other page, and some people use a file: page as a replacement (this doesn't
affect the problem, as we're failing with the chrome one).

The output window has some JS of its own, found here:
http://lxr.mozilla.org/mozilla/source/extensions/irc/xul/content/output-window.js

This JS is what links up the window to ChatZilla itself, and the way this is
done is by "importing" functions from the output area to the ChatZilla objects.
All this really means is that importFromFrame is called.
http://lxr.mozilla.org/mozilla/source/extensions/irc/xul/content/static.js#464

That does nothing more than make the functions available by using
contentWindow.funcName.

In builds with XPCNativeWrappers enabled by default, the contentWindow object
has basically no properties (when I checked, it has a few - document,
innerHeight, pageYOffset and scrollTo - which are simply the IDL-defined stuff
already accessed by ChatZilla's code, but certainly nothing like what it
'really' has). ChatZilla handles missing imports by using an empty function,
which is why there is no errors involved - it silently makes the functions no-ops.

Comment 8

[James Ross]

I would also point out that when this auto-wrapper stuff was started, I did ask
for a document clarifying EXACTLY what and when it got used (not just the
"chrome and content" shit people kept mentioning), and no such information ever
materialised. Without it, I cannot say whether this wrapper existing is right or
not.

Comment 9

[Brendan Eich [:brendan]]

More links:

http://developer.mozilla.org/en/docs/Safely_accessing_content_DOM_from_chrome
http://developer.mozilla.org/en/docs/Chrome_Registration#xpcnativewrappers

If a doc isn't clear enough, let's try Q&A here and feed that into wiki revisions.

Does setting xpcnativewrappers=no for Chatzilla work around or fix this bug?

Cc'ing bsmedberg, perhaps he can review Chatzilla's chrome manifest and see
whether the output-window is not subject to auto-wrappers for some reason.

/be

Comment 10

[James Ross]

Those documents are useless for this, they don't define when a wrapper is used,
or when it allows/blocks access to custom defined stuff.

Setting xpcnativewrappers=no on ChatZilla's content package does indeed 'fix'
it, but we knew the problem already.

There is no 'chrome manifest' to review, it is auto-generated by Firefox. Builds
prior to the switch, as well as those after, all define the contentWindow as
[object XPCNativeWrapper [object Window]]. It's getting wrapped alright, that's
half the problem.

Comment 11

[Bill Gianopoulos [:WG9s]]

(In reply to comment #10)

> There is no 'chrome manifest' to review, it is auto-generated by Firefox. Builds
> prior to the switch, as well as those after, all define the contentWindow as
> [object XPCNativeWrapper [object Window]]. It's getting wrapped alright, that's
> half the problem.

If the chatzilla extension were repackaged in the current format for Firefox
extensions instead of being packaged the old way, there would be a chrome
manifest, and I believe it is possible to override the default setting on a per
extension basis by modifying the chrome manifest for the extension.

Comment 12

[Bill Gianopoulos [:WG9s]]

I verified that altering the chrome.manifset file to look as follows results in
a working chatzilla:


overlay	chrome://editor/content/editorTasksOverlay.xul
chrome://chatzilla/content/chatzillaOverlay.xul
overlay	chrome://browser/content/browser.xul
chrome://chatzilla/content/browserOverlay.xul
overlay	chrome://communicator/content/pref/preftree.xul
chrome://chatzilla/content/prefsOverlay.xul
content	chatzilla	jar:chrome/chatzilla.jar!/content/chatzilla/ xpcnativewrappers=no

overlay	chrome://chatzilla/content/chatzilla.xul
chrome://chatzilla/content/ff/overlay.xul
content	chatzilla-ff	jar:chrome/chatzilla.jar!/content/chatzilla/ff/
xpcnativewrappers=no

skin	chatzilla	modern/1.0	jar:chrome/chatzilla.jar!/skin/modern/chatzilla/
style	chrome://browser/content/browser.xul
chrome://chatzilla/skin/browserOverlay.css
style	chrome://global/content/customizeToolbar.xul
chrome://chatzilla/skin/browserOverlay.css

locale	chatzilla	en-US	jar:chrome/chatzilla.jar!/locale/en-US/chatzilla/

Comment 13

[Brendan Eich [:brendan]]

(In reply to comment #10)
> Those documents are useless for this, they don't define when a wrapper is 
> used,

See
http://developer.mozilla.org/en/docs/XPCNativeWrapper#xpcnativewrappers.3Dyes
and yeah, "content object" is not well-defined.  That should be fixed in the docs.

> or when it allows/blocks access to custom defined stuff.

It always hides ad-hoc properties, showing only the DOM properties that reflect
DOM IDL-defined attributes, methods, etc., and anything else found via XPCOM.

> There is no 'chrome manifest' to review, it is auto-generated by Firefox. Builds
> prior to the switch, as well as those after, all define the contentWindow as
> [object XPCNativeWrapper [object Window]]. It's getting wrapped alright, that's
> half the problem.

The wrapping only happens when script loaded from URIs whose prefix is flagged
in the chrome manifest with xpcnativewrappers=yes access objects created by
scripts not flagged that way, or for DOM objects created based on markup from
URIs not flagged that way.

So what URI loads in the contentWindow?

/be

Comment 14

[James Ross]

Brendan, regarding that document, I assume (but it doesn't say!) that it applies
only when the caller is chrome? (Does it have anything to do with XPC
priviledges? Is it literally just "chrome" URIs?)

Bill, comment 10 did actually say specifically that the flag 'fixed' it. I know
perfectly well what Firefox does, and how to set the flag. ChatZilla is not
getting repackaged - it is unrelated to this bug.

Brendan, comment 7 said that it loads
chrome://chatzilla/content/output-window.html into the browser element. I would
hope that gets the same treatment as the rest of chrome://chatzilla/content/ or
there's something seriously wrong.

Does anyone else get the feeling I'm repeating myself yet?

Comment 15

[Bill Gianopoulos [:WG9s]]

(In reply to comment #12)

> content	chatzilla-ff	jar:chrome/chatzilla.jar!/content/chatzilla/ff/
> xpcnativewrappers=no

Unfortunate line wrapping.  That all belongs on one line.

Comment 16

[Brendan Eich [:brendan]]

(In reply to comment #14)
> Brendan, regarding that document, I assume (but it doesn't say!) that it
> applies only when the caller is chrome? (Does it have anything to do with XPC
> priviledges? Is it literally just "chrome" URIs?)

It's whatever URIs are flagged to the JS engine as "system", and XPConnect is
told to flag that way only based on the chrome registry code's defaults for and
reading of the xpcnativewrappers option.

> Brendan, comment 7 said that it loads
> chrome://chatzilla/content/output-window.html 

Sorry, I wanted to confirm in case some other URI gets loaded in place, somehow.
 It's hard to understand why things aren't just working; a SYSTEM-flagged script
observing SYSTEM objects should not see implicit wrappers.  This means someone
(bsmedberg?) will have to get into a debugger and see what's going wrong.

/be

Comment 17

[James Ross]

The chrome registry clearly needs some documentation explaining what it flags
either way by default, then (along with how DOM elements get bound to URIs, and
so on).

The only thing that occurs to me about the output area is that no URI is
specified when the xul:browser element is created, which probably leaves it to
load about:blank momentarily, before loadURI is thrust upon it.

I'd add some printfs in my tree to watch the wrappers, but I seriously doubt the
tree builds currently (FF didn't a couple of days ago). :(

Comment 18

[Brendan Eich [:brendan]]

(In reply to comment #17)
> The chrome registry clearly needs some documentation explaining what it flags
> either way by default,

This actually is documented at the cited link:
http://developer.mozilla.org/en/docs/Chrome_Registration#xpcnativewrappers --
you may have missed it in all the links and named anchors :-/.

Devmo is supposed to have a non-wiki, hierarchical, MSDN-like way of parachuting
to the right docs, but it doesn't yet (at least not for XPCNativeWrappers).

Plus, it's easy to see that those of us who have been hacking on these wiki docs
are too close to the problem.  We haven't defined our terms and told our story
in a complete, more-or-less linear, and intelligible way.  We will fix that, though.

> then (along with how DOM elements get bound to URIs, and so on).

That's a good point -- the relationship of subject script to object DOM is not
spelled out clearly.  My last comment tried to sum it up by talking about DOM
objects being either created by scripts (in which case the scripts' filename's
prefix being flagged SYSTEM, or not, determines half of the two bits deciding
whether to create implicit wrappers), or induced by markup (in which case the
source URI's prefix being flagged SYSTEM, or not, gives the other bit).

SYSTEM chrome scripts observing non-SYSTEM chrome or content get implicit, deep
XPCNativeWrappers by default now, and you need xpcnativewrappers=no in your
chrome manifest to restore the way things used to be, before yesterday.

SYSTEM observing SYSTEM should not trigger wrapper automation, you might think!
 This bug makes me worry we've broken this case, but it could be that somehow
the contentWindow is losing its SYSTEM-ness, or never gaining it.

Non-SYSTEM observing SYSTEM should be impossible: chrome objects should not be
reachable by content scripts (XBL muddies the waters here).

Non-SYSTEM observing non-SYSTEM of course must not do any wrapping.

The SYSTEM flag is a JS-engine level detail I've used here to try to remember
things more clearly.  You could think of it as "chrome" and non-system as
"content" if you like.  I picked SYSTEM because other embeddings of JS may use
chrome in confusingly different ways, but most OSes and other kernel-like things
use "the system" for the trusted computing base -- which our chrome is part of.

Hope this helps; the docs definitely could use more work.

/be

Comment 19

[Boris Zbarsky [:bzbarsky]]

> Ok, I can't see anything on that list that is related to use, but the list is
> not very clear.

I'd really appreciate any specific feedback on what's not clear.  In email would
be great if you want, since it's not directly related to this bug...

> The output area is set up as a <xul:browser> element

With type="content", right?  More on this below...

> In builds with XPCNativeWrappers enabled by default, the contentWindow object
> has basically no properties

Right.  Again, more on this below.

Now I just tried debugging with dump() and here's what I see.  importFromFrame()
is called, as expected.  import_wrapper() is never called...  So while it's true
that import_wrapper won't work as-is with XPCNativeWrapper, something else is
breaking too, I think.

> Those documents are useless for this, they don't define when a wrapper is
> used

That's because the only people who've looked at the documents are the ones who
wrote the code.  :(  Here comes an attempt at documenting; let me know whether
it makes sense and if it does I'll wiki it.

An implicit wrapper is used any time code from a package which has
xpcnativewrappers=yes (this is the URI substring match thing Brendan mentioned;
bsmedberg might be able to document this better than I) accesses an object which
is not a "system" object.

An object is a "system" object if any of the following conditions hold:

1)  Its __parent__ is a system object
2)  It's a global scope for a JS component
3)  It's a "system" window object (definition below).

Given that all DOM objects in a window have it on their __parent__ chain, this
means that conditions 1 and 3 uniquely determine when DOM objects are "system"
objects.

A window is "chrome" if either of the following holds:

1)  It's a toplevel window (corresponding to a <xul:window> or <xul:dialog> or
    some URI passed to the -chrome command-line flag).
2)  Its parent is "chrome" and one of the following three options holds:
    A) It's not loaded in a <xul:iframe> or <xul:browser>
    B) The <xul:iframe> or <xul:browser> loading it doesn't have a "type"
       attribute
    C) The value of the "type" attribute of the <xul:iframe> or <xul:browser>
       loading it is not "content" and does not start with "content-"

Note that whether a window is "chrome" does _not_ depend on the URI loaded in
the window.  So for example, the following would create "chrome" windows when
used inside a document whose window is already a "chrome" window:

<xul:browser>, <xul:browser type="chrome">, <xul:browser type="rabid_dog">,
<xul:iframe type="foofy">, <html:iframe>, <html:iframe type="content">

while the following would not create a "chrome" window:

<xul:browser type="content">, <xul:iframe type="content-primary">

Further note that any subframe of a non-"chrome" window is automatically
non-"chrome".

In chatzilla's case, since the display window is a <browser type="content"> it
is not a "chrome" window and hence access to it leads to XPCNativeWrapper
creation.  The last part of comment 16 is a little confused....  ;)  Simply
removing the "type" attribute there fixes things over here.

> or when it allows/blocks access to custom defined stuff.

It always blocks custom defined stuff.  The only things that XPCNativeWrapper
exposes are properties defined in IDL and all the DOM0 properties except those
explicitly listed at
http://developer.mozilla.org/en/docs/XPCNativeWrapper#Limitations_of_XPCNativeWrapper

Comment 20

[Brendan Eich [:brendan]]

> In chatzilla's case, since the display window is a <browser type="content"> it
> is not a "chrome" window and hence access to it leads to XPCNativeWrapper
> creation.  The last part of comment 16 is a little confused....  ;)

Yes, sorry to all about my mistake there -- I was mixing up how window objects
get marked SYSTEM or not with how the prefix matching works for script filename
URIs.

So is there a reason chatzilla used type="content"?  Might be we have to make
that work yet keep the default-secure auto-wrapping feature, somehow.

/be

Comment 21

[James Ross]

(In reply to comment #18)
> This actually is documented at the cited link:
> http://developer.mozilla.org/en/docs/Chrome_Registration#xpcnativewrappers --
> you may have missed it in all the links and named anchors :-/.

Actually, it doesn't say, but I'll leave that for another day [1].

> SYSTEM chrome scripts observing non-SYSTEM chrome or content get implicit, deep
> XPCNativeWrappers by default now, and you need xpcnativewrappers=no in your
> chrome manifest to restore the way things used to be, before yesterday.

Before you start writing any documentation like this, let me just say that using
the word "observing" there makes absolutely no sense to me. "Accessing" is what
I'd use. Also, you're using the word "chrome" again, when it is not even
relevant (only the SYSTEM flag matters, right?).


(In reply to comment #19)
Thank you bz, that explanation really helped. :)

And explained something I have never EVER seen documented - and yet is critical
the whole wrapper system!

> Now I just tried debugging with dump() and here's what I see.  importFromFrame()
> is called, as expected.  import_wrapper() is never called...  So while it's true
> that import_wrapper won't work as-is with XPCNativeWrapper, something else is
> breaking too, I think.

import_wrapper is not called as part of importFromFrame, it is called by code like:
http://lxr.mozilla.org/mozilla/source/extensions/irc/xul/content/static.js#2708

I am pretty sure it will be called at the right moments, it just can't *see* the
function it is meant to be wrapping. Anyway, that would be something to worry
about if nessessary after removing the type="content".

> Given that all DOM objects in a window have it on their __parent__ chain, this

What is "it" at this point?

> A window is "chrome" if either of the following holds:

This is probably THE single most important point. :)

More importantly to this bug, I want to know why we are setting the
type="content" attribute in the first place. I'd guess rginda would be the best
person to answer that.

[1] How about *I* try and write up how the heck these wrappers interact with
everything - since I have no part in the code itself - and then people can
correct anything that isn't right?

Comment 22

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #21)
> import_wrapper is not called as part of importFromFrame, it is called by code
like:

Right.  I'm just saying that we never got to whatever code was going to call it;
things died before then...

> Anyway, that would be something to worry about if nessessary after removing
> the type="content".

For what it's worth, I tested that and things seemed to work correctly (I
attached moznet, joined a channel, saw the nick list, saw the motd, etc, etc).

> > Given that all DOM objects in a window have it on their __parent__ chain, this
> 
> What is "it" at this point?

The window.

> This is probably THE single most important point. :)

Yeah, I can't believe we never documented that.  :(

> More importantly to this bug, I want to know why we are setting the
> type="content" attribute in the first place.

My money is on "that's what every other place does" copy-paste...

> [1] How about *I* try and write up how the heck these wrappers interact with
> everything - since I have no part in the code itself - and then people can
> correct anything that isn't right?

If you would be willing to do that, that would be very very much appreciated! 
Of course please ask any questions that come up as you go, either here or in
email to me.

Comment 23

[Brendan Eich [:brendan]]

(In reply to comment #21)

Sure, help with docs -- we clearly need it.

> Before you start writing any documentation like this,

I wasn't writing docs here, just hurried bug comments.  Thanks for the tips.

/be

Comment 24

[James Ross]

Ok, initial draft is at http://wiki.mozilla.org/User:JamesRoss - I'm currently
confused about the stuff in comment 18 re the creation of new objects, but I
think the rest is (hopefully!) right. I would like to know what happens if an
untrusted script *does* get hold of a trusted object, though. ;)

It also seems rather fluffy, but I think that is ok so long as it contains all
the important details about the 'trust', as I called it, to save all the
confusing (and slightly misleading in some cases) 'chrome' and 'system' terminology.

Comment 25

[Robert Ginda]

(In reply to comment #22)
> (In reply to comment #21)
> > More importantly to this bug, I want to know why we are setting the
> > type="content" attribute in the first place.
> 
> My money is on "that's what every other place does" copy-paste...
> 

Ouch!  Actually, the checkin comment for chatzilla.xul r1.9 says "type=content
in xul window to allow mouse selections".  Score one for XPFE, which assumed
that anything that wasn't content was chrome, and so you shouldn't be able to
select it.

Back in those days the output window was an <iframe>, not a <browser>.  The
change to <browser> was another silly change required to make XPFE happy.  I
think we needed the <browser> for DnD, or something.

So, maybe type="content" is not required now that the window is a <browser>.

Comment 26

[James Ross]

Sounds like it is time for me to brush the dust off my Mozilla 1.0, 1.4 and 1.7
installs. :)

Comment 27

[James Ross]

               Selecting  DnD
Mozilla 1.0.2  FAIL       FAIL
Mozilla 1.4.2  FAIL       pass
Mozilla 1.7.8  Refused to even acknowledge XPI file

So all-in-all, rather bad.

Comment 28

[Robert Ginda]

If we had something to test for, we could only apply the type="contet" attribute
to recent builds... unless we need it for selection even in the latest builds.

Comment 29

[James Ross]

It seems we do indeed need type="content" for selection in current builds (of
Firefox at least). That makes things... interesting (telling if we were on a new
build would be no less interesting, mind).

Comment 30

[Bill Gianopoulos [:WG9s]]

(In reply to comment #27)
>                Selecting  DnD
> Mozilla 1.0.2  FAIL       FAIL
> Mozilla 1.4.2  FAIL       pass
> Mozilla 1.7.8  Refused to even acknowledge XPI file
> 
> So all-in-all, rather bad.

Might be nice to have baseline conditions for what happens with each version
with the unadulterated chatilla.xpi.  We need of need to know what used to work
to figure out what will be regressed.  I suspect that DnD may never have worked
with 1.0.2.

Comment 31

[James Ross]

Yeah, DnD doesn't work with 1.0.2, but everything else works in all versions.

It's a moot point, however, since the suggested change does not adequately work
on current versions anyway.

Comment 32

[Robert Ginda]

ChatZilla added DnD of HTML links in version 0.8.1a on 3/21/2001, according to
http://www.hacksrus.com/~ginda/chatzilla/revs.html#0.8.1a.  It looks like tab
DnD was added in 0.8.4, on 8/23/2001.  Mozilla 1.0 didn't come out until
6/5/2002.  So it *should* work in all 1x versions of mozilla, unless we
regressed it for some other reason.

Comment 33

[James Ross]

Error: transferUtils is not defined
Source File: chrome://chatzilla/content/static.js
Line: 2920

http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/global/resources/content/nsTransferable.js&rev=1.8#1.10

So no, it does not work in 1.0.2, due to missing utils. :)

Comment 34

[Bill Gianopoulos [:WG9s]]

(In reply to comment #31)
> Yeah, DnD doesn't work with 1.0.2, but everything else works in all versions.
> 
> It's a moot point, however, since the suggested change does not adequately work
> on current versions anyway.

Well actaully it is good to know becuase it is now known that DnD is irrelevent
and testing in old versions is problbly not required until a good fix is found
because the mouse selection regression fails with current builds.  I don't quite
understand the 1.7.8 does not rcognize the .xpi file because I see no way that
having the type=content or omitting it could possilbly have any affect on that.

So the currently known state is:

1.  If you don't specify type=content then selection with the mouse does not work.

2.  If you do specify type=content, then it does not work with xpcnativewrappers
enabled.

3.  There is something weird going on with Mozilla 1.7.8.

So it appears the chices are:

1.  Find a different way around the mosue selection issue that works with
current and back versions that does not have issues with xpcnativewrappers.

2.  Make chatzilla work correclty with type=content and xpcnativewrappers enabled.

3.  Figure out some way to disable xpcnativewrappers for chatzilla.

Additionally probably need to figure out what the Mozilla 1.7.8 issue is.

Comment 35

[James Ross]

The 1.7.8 issue has nothing to do with the contents of the XPI, it was simply
not even pretending it had been given an XPI (whatever I fed it, it just sat
there like a broken lemon). It's something I don't really care about, anyway.

Comment 36

[Boris Zbarsky [:bzbarsky]]

> Ok, initial draft is at http://wiki.mozilla.org/User:JamesRoss

That seems like a much clearer explanation..  Should we try to merge this into
the main XPCNativeWrapper document as the first section, perhaps?  Or keep the
two separate and add extensive cross-linking?

> I'm currently confused about the stuff in comment 18 re the creation of new
> objects

Me too, actually.  ;)  I think the only relevant DOM objects that can just be
created are DOM nodes; for those what matters is the window of their ownerDocument.

> would like to know what happens if an untrusted script *does* get hold of a
> trusted object, though. ;)

A security exploit.  ;)

Comment 37

[Boris Zbarsky [:bzbarsky]]

So I tried stopping on extensions in venkman to see whether I could figure out
what breaks in chatzilla with xpcnativewrappers on, but there were so many
exceptions from getting strings from bundles that I never managed to get
anywhere... :(

Comment 38

[Boris Zbarsky [:bzbarsky]]

I filed bug 306262 on the issue with chrome docshells and selection.

Comment 39

[Asa Dotzler [:asa]]

not going to block for an extension. we should investigate fixing bug 306262 though.

Comment 40

[Jim Jeffery not reading bug-mail 1/2/11]

The change listed in comment #12 does allow CZ to start, but the content window
is still blank.  I can user list..just nothing in right pane.  Is there another
change to make in CZ to make it work without the wrapper-stuff?

Comment 41

[:Gijs (he/him)]

(In reply to comment #40)
> The change listed in comment #12 does allow CZ to start, but the content window
> is still blank.  I can user list..just nothing in right pane.  Is there another
> change to make in CZ to make it work without the wrapper-stuff?


(comment #0)
> It launches correctly, does not show any errors in the JavaScript console.
> The main content portion of the chatzilla window is blank.

From what I can tell, ChatZilla should start even without changes mentioned in
comment #12. If it doesn't, file new bugs. If the window stays blank after
disabling xpcnativewrappers then something else is wrong, too.

Comment 42

[Bill Gianopoulos [:WG9s]]

(In reply to comment #40)
> The change listed in comment #12 does allow CZ to start, but the content window
> is still blank.  I can user list..just nothing in right pane.  Is there another
> change to make in CZ to make it work without the wrapper-stuff?

The change in comment #12 is specifically to fix the blank content window part.
 Note that I mentioned in comment #15 that the fis I posted ended up with lines
being too long and word wrapping.  The "xpcnativewrappers=no" belong at the end
of both of the lines that begin with the word comment, and should be all on one
line, not 2 lines as it looks in comment #12.

Comment 43

[Bill Gianopoulos [:WG9s]]

(In reply to comment #42)

> being too long and word wrapping.  The "xpcnativewrappers=no" belong at the end
> of both of the lines that begin with the word comment, and should be all on one
                                                ^^^^^^^

Ooops.  That was supposed to say content.  Sorry for all the bugspam. :-(

Comment 44

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #43)
> (In reply to comment #42)
> 
> > being too long and word wrapping.  The "xpcnativewrappers=no" belong at the end
> > of both of the lines that begin with the word comment, and should be all on one
>                                                 ^^^^^^^
> 
> Ooops.  That was supposed to say content.  Sorry for all the bugspam. :-(
> 
> 

Yes, thank you..I understood that, but the content window is still blank....
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050830
Firefox/1.0+ ID:2005083016

Comment 45

[Boris Zbarsky [:bzbarsky]]

James, I've updated the documentation at
http://developer.mozilla.org/docs/XPCNativeWrapper based on the discussion here
and on http://wiki.mozilla.org/User:JamesRoss (shamelessly lifted some of this
last, truth to say).  Could you take a look and let me know what you think?

Comment 46

[James Ross]

Yes, looks good enough to me (defining trust/protected properly and having the
table are the important bits).

Comment 47

[Boris Zbarsky [:bzbarsky]]

OK, non-content docshells are selectable on branch now.

Comment 48

[:Gijs (he/him)]

Attachment: Patch using type="chrome" in appropriate cases

Patch doing the following:

- Up our maximum version requirements so we can actually install normally on Firefox 1.5 and trunk.
- Check the host app using nsIXULAppInfo if at all possible.
- Add a hostCompat object to the client, to keep track of issues like this and whether or not we can do stuff like this.
- Add the typeChromeBrowser property to check if we can use type="chrome" on the browser. This is the preferred method, but not supported in each and every case.

Requesting review from James.

Comment 49

[James Ross]

Comment on attachment 204129 [details] [diff] [review]
Patch using type="chrome" in appropriate cases

r=silver

Comment 50

[James Ross]

Checked in --> FIXED.

Comment 51

[[e-mail]]

So, you'll be wanting XPC native wrappers in SeaMonkey then?

Comment 52

[James Ross]

Why would *we* want a silly thing like that? We never deal with untrusted remote content or scripts.

Comment 53

[:Gijs (he/him)]

blocking1.9a1 is requested for this bug, which got me thinking:

Iff the seamonkey people enable xpcnativewrappers (like comment #52 says, we don't want them...), then the current version of ChatZilla shipped from branch may break. I think it will break, anyway - hopefully I am wrong. Either way, if I'm not wrong, I think that would that mean we want this patch on branch?

Seamonkey people/council: will there be xpcnativewrappers in the releases from the 1.8 branch?

Comment 54

[[e-mail]]

(In reply to comment #53)
>will there be xpcnativewrappers in the releases from the 1.8 branch?
On the 1.8 branch, xpcnativewrappers will be opt-in only.
On the trunk it will depend on if and when we use the toolkit chrome registry.

Comment 55

[[e-mail]]

(In reply to comment #52, which amazingly arrived after comment #54)
>Why would *we* want a silly thing like that? We never deal with untrusted
>remote content or scripts.
Ah, so all this does is prevent Firefox's xpcnativewrappers from breaking you.

Comment 56

[James Ross]

(In reply to comment #55)
> Ah, so all this does is prevent Firefox's xpcnativewrappers from breaking you.

Yes, it just changes the security level of the output area from content (untrusted) to chrome (trusted). There are a bunch of Gecko bugs I need to file about the effect, though...

Comment 57

[:Gijs (he/him)]

Removing the blocking1.9a1 request to clear up queues for people - this is now fixed. Though it would be good if some of the new problems that arose from this solution would be fixed for 1.9a1, which is something we'll have to poke the relevant bugs themselves for, I guess.

If this is not the 'right' thing to do, I apologize, feel free to correct me.

Comment 58

[Boris Zbarsky [:bzbarsky]]

> Though it would be good if some of the new problems

I don't see any.  If there are some, those bugs should be blocking this bug.

Comment 59

[:Gijs (he/him)]

Fair enough.

There was also something about links not being coloured properly, but we fixed that for ChatZilla only (added some additional CSS), and I'm not sure there is a general bug on file for it (or whether there should be). James would probably know about that one.

Comment 60

[James Ross]

No specific bug for the link colour issue, but the marked block in Bonsai is the code necessary to fix it:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/irc/xul/content/output-base.css&rev=1.13&mark=173-181#166

Comment 61

[[e-mail]]

(In reply to comment #59)
>There was also something about links not being coloured properly, but we fixed
>that for ChatZilla only (added some additional CSS), and I'm not sure there is
>a general bug on file for it (or whether there should be). James would probably
>know about that one.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/nsPresShell.cpp&rev=3.897&mark=2108#2086

Given bugs such as these, wouldn't it be a better idea to hold off on typeChromeBrowser for SeaMonkey, since you don't actually need it?