74151 - Move webclient and dependents to MOZILLA_0_8_1 branch

Status: VERIFIED WONTFIX

(Core Graveyard :: Java APIs to WebShell, defect)

Description

[edburns]

This is a tracking bug for moving webclient and dependents to the MOZILLA_0_8_1 
branch.

Comment 1

[edburns]

I have javadom compiling with 0_8_1_BRANCH.  Changes:

// replace nsString::Recycle with nsMemory::Free
java/dom/jni/org_mozilla_dom_events_MouseEventImpl.cpp
java/dom/jni/org_mozilla_dom_events_UIEventImpl.cpp
java/dom/jni/org_mozilla_dom_events_EventImpl.cpp
java/dom/jni/org_mozilla_dom_ProcessingInstructionImpl.cpp
java/dom/jni/org_mozilla_dom_NodeImpl.cpp
java/dom/jni/org_mozilla_dom_NamedNodeMapImpl.cpp
java/dom/jni/org_mozilla_dom_ElementImpl.cpp
java/dom/jni/org_mozilla_dom_DOMImplementationImpl.cpp
java/dom/jni/org_mozilla_dom_DocumentImpl.cpp
java/dom/jni/org_mozilla_dom_CharacterDataImpl.cpp
java/dom/jni/org_mozilla_dom_AttrImpl.cpp
java/dom/jni/javaDOMEventsGlobals.cpp

// On*DocumentLoad() now takes an nsIRequest instead of an nsIChannel.
// nsIChannel extends nsIRequest.
java/dom/src/nsJavaDOMImpl.cpp
java/dom/src/nsJavaDOMImpl.h
java/dom/src/nsIJavaDOM.h

Attachments forthcoming.

Comment 2

[edburns]

Attachment: cvs diff -u of files in javadom portion of fix for this bug.

Comment 3

[edburns]

Attachment: tar.gz of files in javadom portion of fix for this bug.

Comment 4

[edburns]

I'm about to attach diffs and files for getting webclient to compile with 0.8.1.
 It doesn't run, however.  That's the next step.

// nsIChannel instances replaced with nsIRequest. Removed ShowModal(),
// ExitModalLoop(), FindNamedBrowserItem().  Parameter changes for
// {Set,Get}Persistence().  Add DestroyBrowserWindow(), IsWindowModal().
java/webclient/src_moz/CBrowserContainer.cpp

// GetProfileList now returns an array of profile names.  Need to use
// nsIProfileInternal instead of nsIProfile for StartupWithArgs.
java/webclient/src_moz/NativeEventThread.cpp

// Remove -lxpfelocation_s
java/webclient/src_moz/Makefile.in

Comment 5

[edburns]

Attachment: cvs diff -u of webclient part of fix for this bug.

Comment 6

[edburns]

Attachment: tar.gz of files in webclient portion of fix for this bug.

Comment 7

[edburns]

As it turns out, applying the attachments to a win32 tree causes webclient to 
work with MOZILLA_0_8_1_BRANCH on win32, with some assertions.

Comment 8

[edburns]

The following stuff doesn't work any more:

Find in page
SetCurrentHistoryIndex
Back/Forward
AddBookmark
AddBookmarkInNewFolder
LoadStreamFromFile
LoadRandomHTMLStream

Comment 9

[edburns]

The following modifications make webclient work with 0.8.1.  DOM is untested.

Assertions:

- Logging assertion: posted to n.p.m.embedding.
  Message-ID: <[e-mail]>

- re-entrant call to service manager created service twice!: appears in
  WinEmbed, ignoring.

// supports weak references
java/webclient/src_moz/CBrowserContainer.cpp
java/webclient/src_moz/CBrowserContainer.h
// Don't assert thread safe, cause we are thread safe
java/webclient/src_moz/InputStreamShim.cpp
// Don't include libxpfelocation_s
java/webclient/src_moz/Makefile.in
// Don't include appfilelocprovider_s
java/webclient/src_moz/Makefile.win
// Include nsIProfileInternal.h
java/webclient/src_moz/NativeEventThread.cpp

I'm about to attach a non-patchable patch and a tar.gz of these files.

Comment 10

[edburns]

Attachment: non-patchable cvs diff -u of files in webclient portion of fix for this bug. Obsoletes previous webclient patch.

Comment 11

[edburns]

Attachment: OOps, this is the real diff.

Comment 12

[edburns]

Attachment: tar.gz of files in webclient portion of fix for this bug. Obsoletes previous webclient patch.

Comment 13

[edburns]

I have webclient working with 0.8.1 on Win32, but I can't get it working
on Linux or Solaris.  For some reason the following components can't load:

After debugging in the excellent gdb 5.0 with RH 7.0, I have determined
the cause to be:

    return module->GetClassObject(mCompMgr, aCID, NS_GET_IID(nsIFactory),
                                  (void **)aFactory);

is failing.

This is called here:

#0  nsNativeComponentLoader::GetFactoryFromModule (this=0x81cc230, 
    aDll=0x80f5aa0, aCID=@0x80c5e78, aFactory=0xbe5ff3d4)
    at nsNativeComponentLoader.cpp:1185
#1  0x490c3c5d in nsNativeComponentLoader::GetFactory (this=0x81cc230, 
    aCID=@0x80c5e78, aLocation=0x80c5ed8 "rel:libstrres.so", 
    aType=0x80c5eb0 "application/x-mozilla-native", _retval=0xbe5ff3d4)
    at nsNativeComponentLoader.cpp:136
#2  0x49126232 in nsFactoryEntry::GetFactory (this=0x80c5e78, 
    aFactory=0xbe5ff3d4, mgr=0x81c9a88) at nsComponentManager.h:217
#3  0x490bf195 in nsComponentManagerImpl::FindFactory (this=0x81c9a88, 
    aClass=@0xbe5ff4d4, aFactory=0xbe5ff3d4) at nsComponentManager.cpp:1028
#4  0x490bf6e1 in nsComponentManagerImpl::CreateInstance (this=0x81c9a88, 
    aClass=@0xbe5ff4d4, aDelegate=0x0, aIID=@0x48f336e0, aResult=0xbe5ff44c)
    at nsComponentManager.cpp:1196
#5  0x490cadda in nsComponentManager::CreateInstance (aClass=@0xbe5ff4d4, 
    aDelegate=0x0, aIID=@0x48f336e0, aResult=0xbe5ff44c) at nsRepository.cpp:81
#6  0x490cc080 in nsServiceManagerImpl::GetService (this=0x81c95c0, 
    aClass=@0xbe5ff4d4, aIID=@0x48f336e0, result=0xbe5ff594, 
    shutdownListener=0x0) at nsServiceManager.cpp:344
#7  0x490cc607 in nsServiceManagerImpl::GetService (this=0x81c95c0, 
    aContractID=0x48f33560 "@mozilla.org/intl/stringbundle;1", 
    aIID=@0x48f336e0, result=0xbe5ff594, shutdownListener=0x0)
    at nsServiceManager.cpp:491
---Type <return> to continue, or q <return> to quit---
#8  0x48f1c5c9 in NS_InitEmbedding (mozBinDirectory=0x81c91e8, 
    appFileLocProvider=0x0) at nsEmbedAPI.cpp:133
#9  0x48f10a41 in DoMozInitialization (initContext=0x81c87d8)
    at NativeEventThread.cpp:495
#10 0x48f11038 in InitMozillaStuff (initContext=0x81c87d8)
    at NativeEventThread.cpp:579
#11 0x48f10333 in
Java_org_mozilla_webclient_wrapper_1native_NativeEventThread_nativeInitialize
(env=0x81cc53c, obj=0xbe5ff81c, webShellPtr=136087512)
    at NativeEventThread.cpp:205
#12 0x48cfd975 in
Java_org_mozilla_webclient_wrapper_1native_NativeEventThread_nativeInitialize
(env=0x81cc53c, obj=0xbe5ff81c, webShellPtr=136087512)
    at NativeLoaderStub.cpp:446
#13 0x806a599 in ?? ()
#14 0x8067e81 in ?? ()

The mozBinDirectory passed to NS_InitEmbedding is valid and correct.
This doesn't fail on windows.

Am I missing something really simple?  Some new initialization call?

Please help,

Ed

Comment 14

[edburns]

Oh yes, the components that can't load:

+++ nsGenericModule JS component loader: unable to create factory for
{6bd13476-1dd2-11b2-bbef-f0ccb5fa64b6}
###!!! ASSERTION: Factory creation failed: 'NS_SUCCEEDED(rv)', file
nsNativeComponentLoader.cpp, line 157
###!!! Break: at file nsNativeComponentLoader.cpp, line 157
+++ nsGenericModule nsStringBundleModule: unable to create factory for
{d85a17c1-aa7c-11d2-9b8c-00805f8a16d9}
###!!! ASSERTION: Factory creation failed: 'NS_SUCCEEDED(rv)', file
nsNativeComponentLoader.cpp, line 157
###!!! Break: at file nsNativeComponentLoader.cpp, line 157
+++ nsGenericModule nsChromeModule: unable to create factory for
{d8c7d8a2-e84c-11d2-bf87-00105a1b0627}
###!!! ASSERTION: Factory creation failed: 'NS_SUCCEEDED(rv)', file
nsNativeComponentLoader.cpp, line 157
###!!! Break: at file nsNativeComponentLoader.cpp, line 157
+++ nsGenericModule appshell: unable to create factory for
{e34783f5-ac08-11d2-8d19-00805fc2500c}
###!!! ASSERTION: Factory creation failed: 'NS_SUCCEEDED(rv)', file
nsNativeComponentLoader.cpp, line 157
###!!! Break: at file nsNativeComponentLoader.cpp, line 157
+++ nsGenericModule nsProfileModule: unable to create factory for
{02b0625b-e7f3-11d2-9f5a-006008a6efe9}
###!!! ASSERTION: Factory creation failed: 'NS_SUCCEEDED(rv)', file
nsNativeComponentLoader.cpp, line 157
###!!! Break: at file nsNativeComponentLoader.cpp, line 157
+++ nsGenericModule nsPrefModule: unable to create factory for
{dc26e0e0-ca94-11d1-a9a4-00805f8a7ac4}
###!!! ASSERTION: Factory creation failed: 'NS_SUCCEEDED(rv)', file
nsNativeComponentLoader.cpp, line 157
###!!! Break: at file nsNativeComponentLoader.cpp, line 157

Comment 15

[edburns]

After debugging this further, I find that in 

NS_IMETHODIMP
nsGenericModule::GetClassObject(nsIComponentManager *aCompMgr,
                                const nsCID& aClass,
                                const nsIID& aIID,
                                void** r_classObj)

during the for loop when it's looking for a component whose CID equals
the requested cid, it doesn't find one.  Does this mean that
autoregistration is failing somehow?

#0  nsGenericModule::GetClassObject (this=0x81d3b18, aCompMgr=0x81c9ba8, 
    aClass=@0x809f098, aIID=@0x49137ad0, r_classObj=0xbe5ff3d4)
    at nsGenericFactory.cpp:259
#1  0x490c71e8 in nsNativeComponentLoader::GetFactoryFromModule (
    this=0x81cc350, aDll=0x80f5b90, aCID=@0x809f098, aFactory=0xbe5ff3d4)
    at nsNativeComponentLoader.cpp:1184
#2  0x490c3c5d in nsNativeComponentLoader::GetFactory (this=0x81cc350, 
    aCID=@0x809f098, aLocation=0x809f0f8 "rel:libstrres.so", 
    aType=0x809f0d0 "application/x-mozilla-native", _retval=0xbe5ff3d4)
    at nsNativeComponentLoader.cpp:136
#3  0x49126232 in nsFactoryEntry::GetFactory (this=0x809f098, 
    aFactory=0xbe5ff3d4, mgr=0x81c9ba8) at nsComponentManager.h:217
#4  0x490bf195 in nsComponentManagerImpl::FindFactory (this=0x81c9ba8, 
    aClass=@0xbe5ff4d4, aFactory=0xbe5ff3d4) at nsComponentManager.cpp:1028

Comment 16

[edburns]

I find that the nsGenericModule ctor for "JS component loader" is called
once in the java case, with mComponents is:

debug: edburns: printing argument components for JS component loader
        @mozilla.org/widgets/window/gtk;1
        @mozilla.org/widgets/child_window/gtk;1
        @mozilla.org/widgets/button/gtk;1
        @mozilla.org/widgets/checkbutton/gtk;1
        @mozilla.org/widgets/filewidget/gtk;1
        @mozilla.org/widgets/horizscroll/gtk;1
        @mozilla.org/widgets/vertscroll/gtk;1
        @mozilla.org/widgets/textwidget/gtk;1
        @mozilla.org/widget/appshell/gtk;1
        @mozilla.org/widget/toolkit/gtk;1
        @mozilla.org/widget/lookandfeel/gtk;1
        @mozilla.org/widget/label/gtk;1
        @mozilla.org/sound;1
        @mozilla.org/widget/transferable;1
        @mozilla.org/widget/clipboard;1
        @mozilla.org/widget/htmlformatconverter/gtk;1
        @mozilla.org/widget/fontretrieverservice/gtk;1
        @mozilla.org/widget/dragservice;1
        @mozilla.org/filespecwithui;1

But it's called twice in the mozilla case, with the mComponents the
first time being:

debug: edburns: printing argument components for JS component loader
        @mozilla.org/moz/jsloader;1
        @mozilla.org/moz/jssubscript-loader;1

and the second time being:

debug: edburns: printing argument components for JS component loader
        @mozilla.org/widgets/window/gtk;1
        @mozilla.org/widgets/child_window/gtk;1
        @mozilla.org/widgets/button/gtk;1
        @mozilla.org/widgets/checkbutton/gtk;1
        @mozilla.org/widgets/filewidget/gtk;1
        @mozilla.org/widgets/horizscroll/gtk;1
        @mozilla.org/widgets/vertscroll/gtk;1
        @mozilla.org/widgets/textwidget/gtk;1
        @mozilla.org/widget/appshell/gtk;1
        @mozilla.org/widget/toolkit/gtk;1
        @mozilla.org/widget/lookandfeel/gtk;1
        @mozilla.org/widget/label/gtk;1
        @mozilla.org/sound;1
        @mozilla.org/widget/transferable;1
        @mozilla.org/widget/clipboard;1
        @mozilla.org/widget/htmlformatconverter/gtk;1
        @mozilla.org/widget/fontretrieverservice/gtk;1
        @mozilla.org/widget/dragservice;1
        @mozilla.org/filespecwithui;1

This first time invocation is key to the GetClassObject working.

Comment 17

[edburns]

It turns out the first invocation of the nsGenericModule ctor is called as a
result of action in nsAppRunner.cpp, which doesn't load in the embedding case.

 PRBool needAutoreg = PR_TRUE;
  {
    nsCOMPtr<nsISoftwareUpdate>
su(do_GetService(NS_IXPINSTALLCOMPONENT_CONTRACTID, &rv));
    if (NS_SUCCEEDED(rv))
      su->StartupTasks(&needAutoreg);
  }

Comment 18

[edburns]

It turns out this didn't fix the problem.

Comment 19

[edburns]

We're moving to the trunk.

Comment 20

[Oleg Khokhlov]

Obsolete.
Verified and changed QA contact.