embedding widget broken because chrome never finishes loading

RESOLVED FIXED

Status

Core Graveyard
Embedding: GTK Widget
P3
critical
RESOLVED FIXED
18 years ago
6 years ago

People

(Reporter: blizzard, Assigned: blizzard)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments)

(Assignee)

Description

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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
(Assignee)

Comment 4

18 years ago
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.
(Assignee)

Comment 5

18 years ago
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

18 years ago
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

18 years ago
Don't you want your path to be content/embed/contents.rdf, not 
content/contents.rdf?
(Assignee)

Comment 8

18 years ago
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?
(Assignee)

Comment 9

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

Comment 10

18 years ago
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.
(Assignee)

Comment 12

18 years ago
Created attachment 15472 [details]
tar of contents.rdf
(Assignee)

Comment 13

18 years ago
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.
Status: NEW → ASSIGNED

Comment 14

18 years ago
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.
(Assignee)

Comment 15

18 years ago
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.
(Assignee)

Comment 17

18 years ago
have an r=dougt
(Assignee)

Updated

18 years ago
Keywords: nsbeta3
(Assignee)

Comment 20

18 years ago
Created attachment 15858 [details]
contents.rdf files
(Assignee)

Comment 21

18 years ago
Ok, the last two uploads are my most recent changes.  Anyone want to review them?
I'm not up on $(REGCHROME) usage, so someone else (hyatt? warren?) will have to
review that.

In the patch4 attachment, scc@mozilla.org 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

18 years ago
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
(Assignee)

Comment 24

18 years ago
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?
(Assignee)

Comment 25

18 years ago
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

18 years ago
Blizzard, these js warnings are ok.

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

--pete
(Assignee)

Comment 27

18 years ago
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

18 years ago
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

18 years ago
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.
(Assignee)

Comment 30

18 years ago
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 32

18 years ago
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
(Assignee)

Comment 33

18 years ago
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

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

Comment 35

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

(Assignee)

Comment 36

18 years ago
Thanks, scc.  Fix checked in ( finally! )
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.