Closed
Bug 54013
Opened 24 years ago
Closed 24 years ago
embedding widget broken because chrome never finishes loading
Categories
(Core Graveyard :: Embedding: GTK Widget, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: blizzard, Assigned: blizzard)
Details
Attachments
(7 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/x-tar
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/x-tar
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•24 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•24 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•24 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•24 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•24 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•24 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•24 years ago
|
||
Don't you want your path to be content/embed/contents.rdf, not
content/contents.rdf?
Assignee | ||
Comment 8•24 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•24 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•24 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 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
Assignee | ||
Comment 13•24 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•24 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•24 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 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
have an r=dougt
Assignee | ||
Comment 18•24 years ago
|
||
Assignee | ||
Comment 19•24 years ago
|
||
Assignee | ||
Comment 20•24 years ago
|
||
Assignee | ||
Comment 21•24 years ago
|
||
Ok, the last two uploads are my most recent changes. Anyone want to review them?
Comment 22•24 years ago
|
||
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•24 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•24 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•24 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•24 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•24 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•24 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•24 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•24 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.
Assignee | ||
Comment 31•24 years ago
|
||
Comment 32•24 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•24 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•24 years ago
|
||
Yes, Ive tried the latest patch and it works for me. Please check it in!
Comment 35•24 years ago
|
||
It looks right to me, too, Chris. a=scc, if that's what you need.
Assignee | ||
Comment 36•24 years ago
|
||
Thanks, scc. Fix checked in ( finally! )
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•