292659 - No scrollbars, non-functional submit in libXUL/XULRunner app

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, defect)

Description

[jhp (no longer active)]

I am using a libXUL build to embed Mozilla in a Java app using Javaconnect. 
When I bring up a web page, though, there are no scrollbars, and submits don't
work.  Darin mentioned he saw the same problems with TestGtkEmbed.

Comment 1

[jhp (no longer active)]

I get the following errors:

WARNING: Cannot create startup observer :
service,@mozilla.org/extensions/manager;1, file
/home/javier/builds/libxul/mozilla/embedding/components/appstartup/src/nsAppStartupNotifier.cpp,
line 112
###!!! ASSERTION: EnableGlobalHistory() failed: 'NS_SUCCEEDED(rv)', file
/home/javier/builds/libxul/mozilla/embedding/browser/webBrowser/nsWebBrowser.cpp,
line 1208
Break: at file
/home/javier/builds/libxul/mozilla/embedding/browser/webBrowser/nsWebBrowser.cpp,
line 1208
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/home/javier/builds/libxul/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/home/javier/builds/libxul/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/home/javier/builds/libxul/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/home/javier/builds/libxul/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/home/javier/builds/libxul/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/home/javier/builds/libxul/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/home/javier/builds/libxul/mozilla/intl/strres/src/nsStringBundle.cpp, line 273
###!!! ASSERTION: Could not load scrollbars.css.:
'gStyleCache->mScrollbarsSheet', file
/home/javier/builds/libxul/mozilla/layout/style/nsLayoutStylesheetCache.cpp, line 88
Break: at file
/home/javier/builds/libxul/mozilla/layout/style/nsLayoutStylesheetCache.cpp, line 88

Not sure how many of these are related to my special situation of using
Javaconnect, but I don't remember any of these errors when embedding the Mozilla
Suite (also with Javaconnect).

Comment 2

[Darin Fisher]

I spent some time investigating the history assertion.  It seems that LibXUL was
not linking in most of the code under toolkit/components because of some missing
#ifdefs in nsToolkitCompsModule.cpp.  So, there is no history implementation
unless the embedder provides one.  That's probably OK.

When I use mfcembed to test, I actually end up crashing inside box layout.  I'm
guessing that it has something to do with the assertion about not being able to
load scrollbars.css.  It looks like that is part of the 'global' chrome package.
 Upon further investigation, it appears that the chrome registry simply isn't
getting initialized properly (I noticed that nsChromeRegistry::mPackagesHash was
empty), yet mInitialized was true.  I'm not sure what to make of this, but I
suspect that this bug would be solved by figuring out how to ensure that the
chrome registry actually works ;-)

Comment 3

[Darin Fisher]

Ah, more info:

This is actually a regression from the recent chrome registry changes that
introduced the directory service key: NS_CHROME_MANIFESTS_FILE_LIST.  The
new chrome registry expects that key to be defined and it fails miserably
if it is not defined, which is the case for traditional embedding apps.
The solution is probably to make that code failover to inspecting the
app-chrome.manifest created in the previous steps.

Here's a pointer to the problematic code:
http://lxr.mozilla.org/seamonkey/source/chrome/src/nsChromeRegistry.cpp#1084

Comment 4

[Darin Fisher]

Attachment: v1 patch

This patch seems to do the trick for mfcembed.	I see scrollbars, and I can
submit forms.

Benjamin: I almost think that we should make nsXREDirProvider not add
$appdir/chrome to the chrome manifest list, and instead have the chrome
registry unconditionally load .manifest files from the app chrome directory. 
Any thoughts on that?

Comment 5

[Benjamin Smedberg]

Comment on attachment 182477 [details] [diff] [review]
v1 patch

I'm willing to imagine a situation where loading manifests from appdir/chrome
isn't right... let's stick with this patch.

Comment 6

[Darin Fisher]

benjamin: i just thought it odd that this function converts installed-chrome.txt
to app-chrome.manifest, but then doesn't necessarily read app-chrome.manifest. 
it seems like if it is going to know about app-chrome.manifest in one context it
should know about it in this other context as well.  what are the embedding
cases where someone might want zero chrome?

Comment 7

[Benjamin Smedberg]

If the embedding app wishes to provide all of its own chrome, not using any of
the pre-provided chrome from xulrunner (seamonkey may well need this options for
a time while it converts over).

Comment 8

[Darin Fisher]

Ah, I see... so the current patch supports such a system.  OK.

Comment 9

[Asa Dotzler [:asa]]

Comment on attachment 182477 [details] [diff] [review]
v1 patch

a=asa

Comment 10

[Darin Fisher]

fixed-on-trunk