54013 - embedding widget broken because chrome never finishes loading

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: GTK Widget, defect, P3)

Description

[Christopher Blizzard (:blizzard)]

There's a small chunk of chrome that is loaded in the gtk embedding widget so
that we can scroll using the mozilla key bindings and can hook up to key events.
 However, some time in the last couple of weeks it's been broken by some random
checkin.

Here is the file in question:

http://lxr.mozilla.org/seamonkey/source/embedding/browser/chrome/content/simple-shell.xul

It's pretty simple as far as XUL goes.  I added some debugging code to the
embedding widget to track state changes when it is loading chrome and related
documents and here's what I found:

[blizzard@totally-bodacious bin]$ ./TestGtkEmbed
new_gtk_browser
        menu bar
        tool bar
        location bar
        status bar
Type Manifest File: /home/blizzard/src/mozilla0.9/build/dist/bin/components/xpti
.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=16
WEBSHELL+ = 1
WARNING: chrome: failed to get base url for chrome://embedding/browser/content/s
imple-shell.xul -- using wacky default, file ../../../../mozilla/rdf/chrome/src/
nsChromeRegistry.cpp, line 515
chrome://embedding/browser/content/simple-shell.xul start request doc network
chrome://communicator/content/directory/directory.xul start request
Note: verifyreflow is disabled
chrome://communicator/skin/communicator.css start request
chrome://communicator/content/directory/directory.xul stop request
chrome://global/skin/global.css start request
chrome://communicator/skin/box.css start request
chrome://communicator/skin/button.css start request
chrome://communicator/skin/brand.css start request
chrome://communicator/skin/menubutton.css start request
chrome://communicator/skin/formatting.css start request
chrome://communicator/skin/toolbar.css start request
chrome://communicator/skin/search-widgets.css start request
chrome://communicator/skin/communicator.css stop request
chrome://global/locale/intl.css start request
chrome://global/skin/box.css start request
chrome://global/skin/button.css start request
chrome://global/skin/checkbox.css start request
chrome://global/skin/radio.css start request
chrome://global/skin/tree.css start request
chrome://global/skin/splitter.css start request
chrome://global/skin/menubutton.css start request
chrome://global/skin/menulist.css start request
chrome://global/skin/menu.css start request
chrome://global/skin/formatting.css start request
chrome://global/skin/textfield.css start request
chrome://global/skin/tabcontrol.css start request
chrome://global/skin/toolbar.css start request
chrome://global/skin/colorpicker.css start request
chrome://global/skin/global.css stop request
chrome://communicator/skin/box.css stop request
chrome://communicator/skin/button.css stop request
chrome://communicator/skin/brand.css stop request
chrome://communicator/skin/menubutton.css stop request
chrome://communicator/skin/formatting.css stop request
chrome://communicator/skin/toolbar.css stop request
chrome://communicator/skin/search-widgets.css stop request
chrome://global/locale/intl.css stop request
chrome://global/skin/box.css stop request
chrome://global/skin/button.css stop request
chrome://global/skin/checkbox.css stop request
chrome://global/skin/radio.css stop request
chrome://global/skin/tree.css stop request
chrome://global/skin/splitter.css stop request
chrome://global/skin/menubutton.css stop request
chrome://global/skin/menulist.css stop request
chrome://global/skin/menu.css stop request
chrome://global/skin/formatting.css stop request
chrome://global/skin/textfield.css stop request
chrome://global/skin/tabcontrol.css stop request
chrome://global/skin/toolbar.css stop request
Note: styleverifytree is disabled
chrome://communicator/skin/directory/directory.css start request
chrome://global/skin/colorpicker.css stop request
about:xul-master-placeholder start request
chrome://communicator/content/directory/directory.js start request
chrome://communicator/skin/directory/directory.css stop request
WARNING: waaah!, file ../../../../mozilla/rdf/content/src/nsXULPrototypeDocument
.cpp, line 523
JavaScript strict warning:
chrome://communicator/content/directory/directory.js line 261: function OnClick
does not always return a value

JavaScript error:
chrome://communicator/content/directory/directory.js line 65: window._content ha
s no properties

chrome://global/content/treeBindings.xml start request
Note: frameverifytree is disabled
about:xul-master-placeholder stop request
chrome://communicator/content/directory/directory.js stop request
chrome://global/skin/treeBindings.xml start request
chrome://global/content/treeBindings.xml stop request
chrome://global/skin/sortAscending.gif start request
chrome://global/skin/treeBindings.xml stop request
chrome://global/skin/sortAscending.gif stop request

If you look at this you can see that it never finishes loading the embedding XUL
file.  Also, directory.js requires appCores.  Yay.

I need help with this.

Comment 1

[Pete Collins (MDG)]

Didn't you know?? Any non jar external package is horked.

SNAFU . . .

I have been trying to load external packages since friday.
With some direct rdf hacking I can actually load the xul but not the css.

I thought it was just me.  ;-)

--pete

Comment 2

[Pete Collins (MDG)]

Failure begins here:

WARNING: chrome: failed to get base url for chrome://embedding/browser/content/s
imple-shell.xul

It's not getting the baseURL which is defined in all-packages.rdf

If you manually edit the rdf file you will probably be able to get it going. 

adding myself to cc

Comment 3

[Pete Collins (MDG)]

Ok, i got a window to launch.

I edited all-packages.rdf

 <RDF:Description about="urn:mozilla:package:embed">
    <NS623:baseURL>resource:/chrome/embed/content/browser/</NS623:baseURL>
    <NS623:locType>install</NS623:locType>
    <NS623:displayName>Embed</NS623:displayName>
    <NS623:author>mozilla.org</NS623:author>
    <NS623:name>embed</NS623:name>
  </RDF:Description>
  <RDF:Seq about="urn:mozilla:package:root">
    <RDF:li resource="urn:mozilla:package:editor"/>
    <RDF:li resource="urn:mozilla:package:navigator"/>
    <RDF:li resource="urn:mozilla:package:communicator"/>
    <RDF:li resource="urn:mozilla:package:global"/>
    <RDF:li resource="urn:mozilla:package:messenger"/>
    <RDF:li resource="urn:mozilla:package:chatzilla"/>
    <RDF:li resource="urn:mozilla:package:theme_builder"/>
    <RDF:li resource="urn:mozilla:package:embed"/>
  </RDF:Seq>

and then i commented out the reference in mini-nav.xul

<!--
<?xml-stylesheet href="chrome://embedding/browser/skin/embedding.css"
type="text/css"?>
-->

and i get a small window to launch by doing this:

./mozilla -chrome chrome://embed/content/mini-nav.xul

--pete

Comment 4

[Christopher Blizzard (:blizzard)]

Ok, I've been playing with my jar.mn file and trying to add a contents.rdf file
to the embedding code with little success.  The first thing that I did was add a
contents.rdf that adds the right namespace for the embed package and that seems
to work, at least somewhat.  I also had to add the simple-shell.xul and css file
to the jar.mn file since that was left out.

I don't seem to have the paths quite right for everything yet since it doesn't
ever load.  Help.

Comment 5

[Christopher Blizzard (:blizzard)]

OK, trying to follow warren's jar packaging 101 I added the following things:

a contents.rdf:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:chrome="http://www.mozilla.org/rdf/chrome#">

  <!-- list all the packages being supplied by this jar -->
  <RDF:Seq about="urn:mozilla:package:root">
    <RDF:li resource="urn:mozilla:package:embed"/>
  </RDF:Seq>

  <!-- package information -->
  <RDF:Description about="urn:mozilla:package:embed"
        chrome:displayName="Embed"
        chrome:author="mozilla.org"
        chrome:name="embed">
  </RDF:Description>

</RDF:RDF>

added the following to the jar.mn file:

content/embed/simple-shell.xul (content/simple-shell.xul)
content/contents.rdf (content/contents.rdf)
skin/modern/embed/simple-shell.xul (skin/simple-shell.css)

but it still doesn't work.  I still get:

WARNING: chrome: failed to get base url for
chrome://embed/content/simple-shell.xul -- using wacky default, file
../../../../mozilla/rdf/chrome/src/nsChromeRegistry.cpp, line 515

the url I try to load is:

chrome://embed/content/simple-shell.xul

any ideas, warren?

Comment 6

[R. Saravanan]

I ran into the same kind of problem with XMLterm on Friday. The error message
was "window._content has no properties" etc, and mozilla would just hang. In my
case, all of the errors could be traced back to misplaced CSS files in the new
chrome directory structure. I followed the chatzilla example, and fixed up my
jar.mn and content.rdf files and finally everything was working again. I had to
insert some code in rdf/chrome/src/nsChromeProtocolHandler::NewChannel to print
out exactly how chrome: URLs were being resolved to jar: URLs to sort this out.

You can look at extensions/chatzilla or extensions/xmlterm for a working set of
chrome files for components. I also found that I had to provide CSS files for
both skin/modern and skin/classic separately. Finally, I ended up moving all my
CSS files to the chrome content directory, as a temporary workaround. I'll
revisit this once my understanding of skin switching improves!

Comment 7

[Warren Harris]

Don't you want your path to be content/embed/contents.rdf, not 
content/contents.rdf?

Comment 8

[Christopher Blizzard (:blizzard)]

Ok, after looking at svn's checkins ( thanks! ) I've got this now:

[blizzard@totally-bodacious bin]$ unzip -l chrome/embed.jar
Archive:  chrome/embed.jar
  Length     Date   Time    Name
 --------    ----   ----    ----
      543  09-25-00 17:43   content/embed/contents.rdf
     4738  09-13-00 19:50   content/embed/mini-nav.js
     1708  09-25-00 17:45   content/embed/simple-shell.xul
      845  06-30-00 08:25   content/embed/back.gif
      845  06-30-00 08:25   content/embed/forward.gif
      844  06-30-00 08:25   content/embed/reload.gif
      843  06-30-00 08:25   content/embed/stop.gif
      811  08-18-00 10:44   locale/en-US/embed/embedding.dtd
      786  09-25-00 17:56   locale/en-US/embed/contents.rdf
     1459  06-30-00 08:25   content/embed/embedding.css
     1005  09-25-00 16:32   content/embed/simple-shell.css
      744  09-25-00 17:44   skin/modern/embed/contents.rdf

however, it still can't find the .xul file.

WARNING: chrome: failed to get base url for
chrome://embed/content/simple-shell.xul -- using wacky default, file
../../../../mozilla/rdf/chrome/src/nsChromeRegistry.cpp, line 515

Here's my contents.rdf for the the content directory:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:chrome="http://www.mozilla.org/rdf/chrome#">

  <!-- list all the packages being supplied by this jar -->
  <RDF:Seq about="urn:mozilla:package:root">
    <RDF:li resource="urn:mozilla:package:embed"/>
  </RDF:Seq>

  <!-- xmlterm package information -->
  <RDF:Description about="urn:mozilla:package:embed"
        chrome:displayName="Embed"
        chrome:author="mozilla.org"
        chrome:name="embed">
  </RDF:Description>

</RDF:RDF>

Is there possibly some cruft in the Makefile.in that's causing this or something?

Comment 9

[Christopher Blizzard (:blizzard)]

Ok, I think I have this working again now.  I'll post patches and extra needed
files in a few mins.

Comment 10

[R. Saravanan]

Looking at the last few lines of embedding/browser/chrome/Makefile.in,  you
don't seem to registering the chrome for the embed package. Shouldn't the last
three lines be 
         @$(REGCHROME) content embed embed.jar; \
         $(REGCHROME) skin modern/embed embed.jar; \
         $(REGCHROME) locale en-US/embed embed.jar

You can also look at the last few lines of dist/bin/chrome/installed-chrome.txt
to check if your chrome actually got registered when you do "make chrome"

Looks like you are putting your CSS files in the content area, like I did, in
which case make sure you change the CSS URL in the XUL file to
//embed/content/...
I don't know whether this is a good idea, but I did it because mozilla was
looking for skin/classic and kept hanging when I compiled the Sep. 22 tarball.
When mozilla doesn't find a skin for a particular package, it should default to
skin/modern or something like that. It doesn't seem to be happening right now.

Comment 11

[Christopher Blizzard (:blizzard)]

Attachment: patch

Comment 12

[Christopher Blizzard (:blizzard)]

Attachment: tar of contents.rdf

Comment 13

[Christopher Blizzard (:blizzard)]

Yeah, after adding checks to the chrome loader I saw that it was still trying to
load it from the wrong place.  I found the bad commands in the makefile that
were adding it to the wrong package.  Can I get someone to review these changes?
 I'd like to get it into both the stable branch and the tip.

Comment 14

[R. Saravanan]

In your patch, the gif files are in content/embed and the css files are in
skin/modern/embed. If skin/modern works for you, I would say put all the skin
stuff (gif+css) in skin/modern/embed directory of the jar. Changing mozilla
skins shouldn't affect the embedding stuf (like it did xmlterm). With this
change, I'd be willing to review your code as a casual hacker, but not as a
chrome expert.

Comment 15

[Christopher Blizzard (:blizzard)]

Actually, I just moved it to the content directory since it really isn't skin
dependent in any way.  It's just a window with a content area.  I'll attach a
new patch here.

Comment 16

[Christopher Blizzard (:blizzard)]

Attachment: patch2

Comment 17

[Christopher Blizzard (:blizzard)]

have an r=dougt

Comment 18

[Christopher Blizzard (:blizzard)]

Attachment: patch3

Comment 19

[Christopher Blizzard (:blizzard)]

Attachment: patch4

Comment 20

[Christopher Blizzard (:blizzard)]

Attachment: contents.rdf files

Comment 21

[Christopher Blizzard (:blizzard)]

Ok, the last two uploads are my most recent changes.  Anyone want to review them?

Comment 22

[Brendan Eich [:brendan]]

I'm not up on $(REGCHROME) usage, so someone else (hyatt? warren?) will have to
review that.

In the patch4 attachment, [e-mail] should comment on
 
-mChromeLocation.AssignWithConversion("chrome://embedding/browser/content/simple-shell.xul");
+mChromeLocation.AssignWithConversion("chrome://embed/content/simple-shell.xul");

Wouldn't NS_LITERAL_STRING be better here?

/be

Comment 23

[Adam Lock]

Hi, the patches look reasonable to me. Can you just ensure that you have fixed 
up mini-nav so that it works too, such as from the command line, e.g.

mozilla -chrome chrome://embed/content/mini-nav.xul

Comment 24

[Christopher Blizzard (:blizzard)]

Ok, I've got changes in my local tree that get mini-nav.xul at least to load.
It doesn't work on the tip, by the way.

However, it gets tons + tons of errors when I try and use the text area:

WEBSHELL+ = 3
Enabling Quirk StyleSheet
JavaScript strict warning:
 line 84: reference to undefined property me.noDirectMatch

JavaScript strict warning:
 line 154: reference to undefined property me.ignoreInputEvent

JavaScript strict warning:
 line 79: reference to undefined property me.menuOpen

etc...

am I missing the include of a JS file somewhere?

Comment 25

[Christopher Blizzard (:blizzard)]

Ok, I think I've got this pretty much working except for the fact that the
onload handler isn't being fired.  This looks like a bug somewhere else, though...

Comment 26

[Pete Collins (MDG)]

Blizzard, these js warnings are ok.

We are running in strict mode these days to clean up sloppy js.

--pete

Comment 27

[Christopher Blizzard (:blizzard)]

pete, have you seen other places where the onload handler isn't being fired when
you have chrome loaded from the command line?

Comment 28

[Pete Collins (MDG)]

Nope, all my packagesuse an onload hanldler on startup w/ no probs.

What happens when you put a dump in there?

onload="dump('testing onload handler\n\n');"

What errors are you getting?

--pete

Comment 29

[Adam Lock]

Hi Chris, I'm not too concerned if mini-nav.xul is giving JS warnings as long as
it is working with the updated chrome paths. Thanks.

Comment 30

[Christopher Blizzard (:blizzard)]

This is really strange.  I've narrowed the onload handler not being called
because of the inclusion of this in the embedding.css style sheet:

@import url(chrome://navigator/skin/);

if I remove that and put this directive in the mini-nav.xul file:

<?xml-stylesheet href="chrome://embed/content/embedding.css" type="text/css"?>
<?xml-stylesheet href="chrome://navigator/skin/" type="text/css"?>

then it loads but with the navigator buttons ( which it shouldn't. )  Also, I've
discovered that if I put the navigator/skin style sheet before the embedding.css
that the onload handler doesn't fire.

Help me obi-hyatt-wan.  You're my only hope.

Comment 31

[Christopher Blizzard (:blizzard)]

Attachment: patch5

Comment 32

[Pete Collins (MDG)]

This is exactly the same problem i am having right now!

Your skin path is not being registered.

Vote on this bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=54904

--pete

Comment 33

[Christopher Blizzard (:blizzard)]

The latest patch works.  It doesn't use the embedding.css list items but it does
browse.  I also fixed the warnings I could find and brought the onStatus crap up
to date.  Can I check this in now?

Comment 34

[Ramiro Estrugo]

Yes, Ive tried the latest patch and it works for me.  Please check it in!

Comment 35

[Scott Collins]

It looks right to me, too, Chris.  a=scc, if that's what you need.

Comment 36

[Christopher Blizzard (:blizzard)]

Thanks, scc.  Fix checked in ( finally! )