Closed Bug 211549 Opened 21 years ago Closed 21 years ago

Webclient broken in Mozilla 1.4. xpcom.dll is missing

Categories

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

Product:
Core Graveyard
Component:
Java APIs to WebShell
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: robert, Assigned: joe.chou)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

In Mozilla 1.3.1 the xpcom.dll was still there, but now in Mozilla 1.4 it's
gone. Unfortunately Webclient was not updated to use the new dlls that replace
xpcom.dll - if there are any at all. So the Webclient complains about not
finding xpcom.dll.
Is there some workaround for this? Can I use xpcom.dll from Mozilla 1.3.1? Or
will Webclient be updated any time soon.

Reproducible: Always

Steps to Reproduce:
1. Download windows Webclient api
2. Run example


Actual Results:  
Popup states that the app could not be run because xpcom.dll could not be found.
Console contains UnsatisfiedLinkError

Expected Results:  
No popup
No exception
Running application
Yeah, sure.
xpcom.dll is still there. It's in the GRE directory (under c:\documents and
settings\.. )

isn't this a dupe of bug 195600 : installation of 1.4 on top of 1.3+add-ons w/o
clearing the Mozilla.org folder first?

See http://bugzilla.mozilla.org/show_bug.cgi?id=200623#c4 for cause and resolution. 

If this is a dupe, please mark as such.
all bugs reporting 1.4[final] not starting under win32 seem to be burried and
marked as "resolved duplicate" and having the comments removed. Must have
touched a raw nerve with moz team.
what is the real bug number?

PS same problem here, no start, clean directory, no xpcom.dll


Galen : just fyi, please don't vent silly conspiracy theories here. 

Also note that no comments are removed from bugs. I've seen that happen only
once since someone accidentaly posted privacy-sensitive logon information, being
unaware that this is an open system.

What "real bug number" are you referring to?

Also read the README file, especially the last lines
http://www.mozilla.org/releases/mozilla1.4/README.html

*** This bug has been marked as a duplicate of 195600 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Dear people!

You didn't read the bug report attentively. I did not say that the Browser
crashes. And actually I installed 1.4 in a fresh directory after completely
removing 1.3.1, because after an install of 1.4 on top of 1.3.1, Mozilla had
some problems with the Java Plugin and could not find jvm.dll. Now Mozilla 1.4
runs without problems. So comments #4, #5, #6 are wrong here. This bug report
isn't a duplicate of 195600 either.
To #3: This one gets into the right direction. I have compared the installation
of 1.3.1 on my notebook with the 1.4 installation on my main computer and found
out that you have separated the GRE stuff into an own folder in the "common
files" folder on the system drive in the 1.4 version. Why? As far as I know
Microsoft has dropped the concept of common files and dlls and more and more
vendors are delivering their software in a way that installs all dlls in one
folder without this separation. What's the reason for the separation in 1.4?
This bug is about Java API to WebShell as stated under "Component". This is
about the Webclient that allows a Java programm to embed Mozilla. Since I now
know where xpcom.dll is now I changed my java.library.path to contain this new
directory. Unfortunately it doesn't work this way. It seems that webclient.dll
needs xpcom.dll in the same directory it is located itself. Ok, I could copy the
whole GRE stuff into my Mozilla folder, but wouldn't that make Mozilla - now as
a browser on its own - unstable.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Patrick: know your facts

Fact. Reports on 1.4 not starting have been censored heavily. Anyone following
bugzilla will run into a RESOLVED DUPLICATE dead end. There does not appear to
be a solution.

Update success.

I managed to install and RUN 1.4 by adding it to a sub folder of 1.3.1 [eg
d:/mozilla/1.3.1/1.4
a clean install would not work. Strange I know.

Going back to the issue of *this* bug:

As a workaround, try installing a zipped install of Mozilla instead of an
installer version.  The zipped version maintains xpcom.dll in its original
location in program files/mozilla.org/etc.
galen@flightsimhq.org: Your comment #8 is silly, wrong, doesn't belong in a bug
(because it's useless SPAM) and you also missed that this is not about an
installing 1.4 issue. 
This is a bug database and no support databse and you get no solutions here.
(only sometimes)


not impressed with the snipers, but I will still report my findings despite the
a-holes.
I reported my findings here because it was the ONLY bug still open at the time.
There was MANY bugs reported on 1.4 but they were showing RESOLVED DUPLICATE and
CLOSED. I followed MANY bug reports and even went back to one's I added info to,
they were locked and reduced to one entry per bug.
So no it was not silly to post in a similar bug. So no I don't expect support
here. I do expect professionalism.
I get browser crashes that report the XPCOM.DLL quite often.  The latest
happened just as I clicked on the Home icon to return to my home page.  The
following error message was generated:

MOZILLA caused an invalid page fault in
module XPCOM.DLL at 0167:610f093b.
Registers:
EAX=01198d00 CS=0167 EIP=610f093b EFLGS=00010206
EBX=01ade358 SS=016f ESP=00657efc EBP=00657f14
ECX=61d7eff0 DS=016f ESI=0000003c FS=13b7
EDX=00000020 ES=016f EDI=0193ce0c GS=0000
Bytes at CS:EIP:
ff 51 08 c3 56 57 8b 7c 24 0c 8b f1 85 ff 74 06 
Stack dump:
01198d00 60334f85 0193ce0c 00000020 00000005 01ade358 00657f44 602fd5bd 01198d00
0193afc0 01925f1c 01925f1c 0193ce38 01925f1c 00000000 01925f1c 

robert: are you still seeing this?
No, it wasn't going anywhere. So I left. The comments were mostly not to the
point complaining about other issues that had only little in common with this
bug. I think most of the commentators didn't get it. Maybe it's because they are
users and don't develop any apps themeselves. So they don't know what the
webclient api is and what it's for.

I have worked around the problem so I don't need the api anymore for the app I
work on.

I have put it inside-out now. Now it's a web-app running in Mozilla and not a
desktop-app embedding Mozilla.

But nevertheless I think this bug should be fixed someday since the webclient
api was a great thing to have.
reporter: do you still want to pursue your idea or can this bug be resolved?

Updating severity. Moz is at 1.7a now, this was filed for 1.4 so obviously it
wasn't a "blocker" :)
Severity: blocker → normal
Well, it depends!

It was a stopper for the WebClient API - not for the browser itself - since it
didn't work anymore. I had an application in development that used this API.
After this bug appeared I had to rewrite it to avoid using it.

I have never again tried to use the API since no new releases were posted to the
API.

It seems that new work is going on in this field. I'll test WebClient API 2.0
when it comes out for Windows.

So I'm resolving this with WONTFIX and will come back when the new API is available.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.