255016 - Nvu landing tracking bug

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Composer, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

This is a bug to track all issues related to the landing of Nvu into
cvs.mozilla.org.

Comment 1

[Gérard Talbot]

If bug 240459 affects Nvu 0.5, does that mean I can indicate/add its dependency
here? So far, this meta bug looks more like a features-to-implement list than a
bugs list.

Comment 2

[steve.swanson]

I was able to compile NVU 0.7 from the tarball.

However, I've been unable to get a runnable program compiling against the 1.8b 
trunk.
 a. there was a simple change in nsXREAppData ... fixed
 b. in xre_main(), chromeObserver->Observe() is called with "command-line-
startup" but nsChromeRegistry::Observe() doesn't understand ... removed

Now, everything compiles and starts up OK, but nvu.exe just shuts down w/o 
showing a window.

Anyone have any ideas on where to look for problems? 

Comment 3

[Benjamin Smedberg]

steve, are you sure you're using an up-to-date tree and have MOZ_XUL_APP set (it
should be set by --enable-application=composer)? The toolkit chrome registry
does recognize command-line-startup, see
http://lxr.mozilla.org/mozilla/source/chrome/src/nsChromeRegistry.cpp#2938).

And NVU will need at least the pref "toolkit.defaultChromeURI" set, and/or a
specialized nsICommandLineHandler implementation.

Comment 4

[steve.swanson]

Thanks for the help.

> steve, are you sure you're using an up-to-date tree
I thought so, but CVS update in chrome caused some new stuff to come down.  I 
guess that's not updated when building the suite.

>and have MOZ_XUL_APP set (it should be set by --enable-application=composer)?
This was OK.

> The toolkit chrome registry does recognize command-line-startup, see
> http://lxr.mozilla.org/mozilla/source/chrome/src/nsChromeRegistry.cpp#2938).
I see that now.

> And NVU will need at least the pref "toolkit.defaultChromeURI" set, and/or a
> specialized nsICommandLineHandler implementation.
OK.  Will track this down if needed.

Comment 5

[steve.swanson]

Sorry, stuck again.  I tried adding pref("toolkit.defaultChromeURI", true) to 
composer/app/profile/all.js but that didn't seem to make a difference.  How 
can I tell whether this is working correctly?

Below is the log I get in the console, in case that helps.

WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file 
c:/Mozilla/mozilla/toolki
t/profile/src/nsINIParser.cpp, line 51
Type Manifest File: C:\Documents and Settings\Steve.*********\Application 
Data\N
vu Vendor\Nvu\Profiles\rqnybsug.default\xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nsNativeComponentLoader: registering deferred (0)
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file 
c:/Mozilla/mozilla/toolki
t/profile/src/nsINIParser.cpp, line 51
++WEBSHELL == 1
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file 
c:/Mozilla/mozilla/extens
ions/cookie/nsPermissionManager.cpp, line 624
++DOMWINDOW == 1
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x8000ffff 
(NS_ERROR_UNEXPECTED)
 [nsIPrefBranch.getCharPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  
loc
ation: "JS frame :: file:///C:/Mozilla/mozilla/obj-
Composer/dist/bin/components/
nsDefaultCLH.js :: clh_handle :: line 81"  data: no]
************************************************************
WARNING: nsExceptionService ignoring thread destruction after shutdown, file 
c:/
Mozilla/mozilla/xpcom/base/nsExceptionService.cpp, line 191
--WEBSHELL == 0
###!!! ASSERTION: Main thread being held past XPCOM shutdown.: 'cnt == 0', file
c:/Mozilla/mozilla/xpcom/threads/nsThread.cpp, line 450
Break: at file c:/Mozilla/mozilla/xpcom/threads/nsThread.cpp, line 450

Comment 6

[Benjamin Smedberg]

It's a char pref, and it's supposed to be the URI of the chrome page to open on
app-launch, presumably chrome://editor/content/ or something like that.

Comment 7

[steve.swanson]

Bingo.  Now seems to start up OK.  Missing a menu bar and ASSERTs often fire, 
but I can work with this.

Comment 8

[steve.swanson]

Something changed in the last few days, but I'm still missing a menu.

After I delete the profile, on the second startup, the first WARNING is
 WARNING: Creation of "{47049e42-1d87-482a-984d-56ae185e367a}" in progress
 (Reentrant GS - see bug 194568), file :/Mozilla/mozilla/xpcom/components/
 nsComponentManager.cpp, line 1813

The second WARNING is
 WARNING: NS_ENSURE_TRUE(reg) failed, file
 c:/Mozilla/mozilla/chrome/src/nsChromeProtocolHandler.cpp, line 560

Then I get some warnings about failed stringbundle lookups:
"intl.charset.default", "intl.charset.detector","XMLParsingError"

I don't understand why these aren't found.  The .properties files are in 
the .jar.  Some problem with locale?
 
Eventually, I get an ASSERTION
       <xul:hbox align="center" class="menu-right" chromedir="&locale.dir;"
 ------^
 ###!!! ASSERTION: Unable to locate an XBL binding.: 'protoBinding', file
 c:/Mozilla/mozilla/content/xbl/src/nsXBLService.cpp, line 892

This is what's new.

Then, after stepping through some more ASSERTIONS, I get a running NVU with no 
menu.


My trunk is pretty clean.  I changed nsAppShellService.cpp and 
nsNativeAppSupportWin.cpp as per the NVU patch.  I'm using NVU 0.81.

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614