Jacob Kjome Reporter
	Description • 23 years ago

Using build 2001083109 on Win2k (SP2)

Going to the URL in the URL bar causes Mozilla to crash.

Steps to reproduce:
1. load URL: 
jar:http://www.visi.com/~hoju/assets/resources/resources_test.jar!/images/apache
_pb.gif

2. Watch Mozilla crash

Actual results: crash

Expected results:  see Apache Web Server image

Note: other bugs related to the :jar protocol are:

bug 26496
bug 36102

Jake

	Jacob Kjome Reporter
	Comment 1 • 23 years ago

Woops, forgot to add the talkback ID

Talkback ID:  TB34824314Y

Actually, this one was obtained by going to:

http://www.visi.com/~hoju/resources_test.html

which contains an <img> tag that looks like:

<img
src="jar:http://www.visi.com/~hoju/assets/resources/resources_test.jar!/images/a
pache_pb.gif"
alt="Image loaded from jar file" />

I think the crash is the same whether loaded from the <img> tag or loaded 
directly from Mozilla's URL bar.

Jake

	Matthias Versen [:Matti]
	Comment 2 • 23 years ago

wfm with win2k build 20010901..
CC stephend for the Talkback...

	Jacob Kjome Reporter
	Comment 3 • 23 years ago

ummm... maybe I'm missing something, but how can you have tested this with a 
build that doesn't exist?...or did you build it yourself?  The last official 
win32 builds were done 8/31 at 10:54.  No win32 builds were done on 9/1.

Also, when you say "WFM", are you saying that you saw the apache web server 
image???

Jake

	Matthias Versen [:Matti]
	Comment 5 • 23 years ago

I build myself and therefore i added the 2 ".." at the end of my build ID.
I saw the apache image without a crash. I tested the .HTML page and the direct 
Jar link.

And too bad that the stack trace from the Talkback is useless..

	Jacob Kjome Reporter
	Comment 6 • 23 years ago

Just tested in today's builds.  Crashed just like before.

Matthias, you must be doing something different when you build.  Both yours and 
the official builds come from the same source, I presume?  What the heck???

New Talkback:  TB34955748Y

Hopefully that one isn't useless.

Jake

	Jacob Kjome Reporter
	Comment 8 • 23 years ago

This is still crashing in build 2001090703 on Win2k (SP2)

I would think this should be fixed for the 0.94 milestone since it worked in
previous milestones. 

Can this get some more priority???

Jake

	Jacob Kjome Reporter
	Comment 9 • 23 years ago

Using build 2001091815 on Win2k (SP2)

Ok, I don't mean to be a pest, but this is a CRASHER that got released with 
0.94 where previous milestones did NOT crash on the jar protocol.  What if some 
company bases a production product on 0.94?  At that point, I couldn't be 
certain that I could even use URL's that point to jar archives because I 
couldn't guarantee that it would work or, at the very least, do no harm to the 
user's browser.  What a shame for such a useful protocol!!!

I figured that with this since this is a much newer build, I'd post another 
talkback.
Talkback ID: TB35589955E

crashed on page:  http://www.visi.com/~hoju/resources_test.html

So, what's the deal?  I'm not going to be an ass and up severity to "critical" 
since I'm not going to be the one to actually fix it, but at least lets set a 
priority, target, and maybe up the severity so this doesn't end up in the next 
milestone.

Jake

	benc
	Comment 10 • 23 years ago

+crash.

Next time, mark it up. We have a lot of bugs. If you don't do the right thing
when you have the chance, who will?

+relnote - I'll make text once this is isolated.

	Jacob Kjome Reporter
	Comment 12 • 23 years ago

Any work being done on this?

Just adding another Talkback to keep up with the new builds:

Talkback Id:  TB37050193M

Again, crashed after attempting to load:
http://www.visi.com/~hoju/resources_test.html

Jake

	/\/\arcio Galli
	Comment 13 • 23 years ago

Tested with Arun and really crashes with win98 and win2K. Adding Mitchell Stoltz
to the cc since this affects signed scripts. 

	Arun Ranganathan
	Comment 14 • 23 years ago

Firstly, this bug occurs on Windows only, and Mac and Linux aren't affected.  I
consistently crashed Win2000 and Win98 builds of Moz'.
Secondly, since our signed script policy no longer uses ARCHIVE and ID
attributes and now makes the jar: protocol an *integral* part of the signed
script recommendations (see
http://www.mozilla.org/projects/security/components/signed-scripts.html),
effectively this means signed scripts on Windows are completely broken because
of this bug.
It really ought to get nominated.

	Doug Turner (:dougt)
	Comment 15 • 23 years ago

wierd.  I am not crashing on the trunk nor a old moz094 build.  Let me update
the branch, to see if I can reproduce this.  

I will hold onto this bug for now.

	Jacob Kjome Reporter
	Comment 16 • 23 years ago

Ok, here is another talkback to prove it.  I was using build 2001111410 on 
Win2k (SP2) and visiting the url in the URL field above.

Talkback:  TB38060178G

I also tried this in KMeleon 0.5 and it crashed too.  I think 0.4 delbt with it 
just fine (can't be sure, though).

So, it is definitely crashing.

jake

	Doug Turner (:dougt)
	Comment 17 • 23 years ago

I believe you.  I am just not seeing it in my debug 0.9.4 or trunk build.   I do
see it in a opt Netscape 6.2.

	Jacob Kjome Reporter
	Comment 18 • 23 years ago

On which OS are you testing?

Jake

	Doug Turner (:dougt)
	Comment 19 • 23 years ago

darin is looking at it.

	Darin Fisher Assignee
	Comment 20 • 23 years ago

dbaron and i investigated this for a bit... after going crazy stepping through
assembly code, we discovered that the nsWriteSegmentFun in nsDownloader.cpp was
not declared properly.	nsWriteSegmentFun is declared NS_METHOD, which on win32
maps to |nsresult __stdcall|, but nsDownloader::ConsumeData was declared
without NS_METHOD, so the calling convention didn't match, resulting in all
kinds of chaos and effectively the corruption of the stack pointer.

	Darin Fisher Assignee
	Comment 21 • 23 years ago

Comment on attachment 58037 [details] [diff] [review]
v1.0 patch

got r=dbaron on this.

	Doug Turner (:dougt)
	Comment 22 • 23 years ago

Comment on attachment 58037 [details] [diff] [review]
v1.0 patch

remove that cast..line 147

	Darin Fisher Assignee
	Comment 24 • 23 years ago

Comment on attachment 58039 [details] [diff] [review]
v1.1 revised per dougt's comments

r=dbaron, sr=dougt

	Darin Fisher Assignee
	Comment 25 • 23 years ago

*** Bug 95179 has been marked as a duplicate of this bug. ***

	Darin Fisher Assignee
	Comment 26 • 23 years ago

fixed-on-trunk

	Arun Ranganathan
	Comment 27 • 23 years ago

CC'ing Bindu Sharma for QA of signed JS on trunk.

	Jay Patel [:jay]
	Comment 28 • 23 years ago

Adding M094 [@ ntdll.dll - nsInputStreamTee::TeeSegment] 

	Jay Patel [:jay]
	Comment 29 • 23 years ago

Darin thought Bug 95179 might be dup of this, so I added the stacksignature from
that bug here and adding topcrash keyword too for tracking, since this has been
a topcrasher for a while (for N610 and M094).

	Darin Fisher Assignee
	Comment 30 • 23 years ago

blizzard fixed this on the 0.9.6 branch... retargeting for the 0.9.4 branch.

	Judson Valeski
	Comment 31 • 23 years ago

please checkin to 0.9.4 branch when you have a chance, and add "fixed0.9.4"
keyword to the keyword field when it lands.

	Darin Fisher Assignee
	Comment 32 • 23 years ago

fixed0.9.4

	Jaime Rodriguez, Jr.
	Comment 33 • 23 years ago

Adding PDT for tracking and review purposes.

	Dave
	Comment 34 • 23 years ago

The example test page still crashes my N 6.2.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 
Netscape6/6.2 

	Jacob Kjome Reporter
	Comment 35 • 23 years ago

Dave,

Unfortunately, the 0.9.4 branch that Netscape used to build Netscape 6.2 
contained this bug.  This is why I was pushing pretty hard early on to get this 
fixed *before* a major vendor released a browser that included this bug.  Now, 
if I am to use the jar protocol to link to resources such as images, css, or 
javascript, I will have to check to make sure the browser isn't Netscape 6.2 or 
K-Meleon .05 and .06, otherwise, I'll cause their browsers to crash and they 
probably won't want to visit my site anymore.

I don't want to come down too hard on the overworked developers of Mozilla, but 
stuff like this creates bad backward compatibility issues!  Granted, no other 
major browser out there supports the jar protocol (that I know of), so it is 
unlikely to cause a major problem, but making even one release of a browser 
with a crasher bug like this sets back the regular use of such a feature by a 
long time.  I just wish this bug received the attention it has gotten of late 
much earlier so I wouldn't have to say this.

Anyway, despite this, Mozilla still rules and I don't want that point to get 
lost during its criticism.

Jake 

	Jaime Rodriguez, Jr.
	Comment 36 • 23 years ago

If the test case(s) look good, pls check this one into the 6.2 branch before 9
am PST = PDT+

	Darin Fisher Assignee
	Comment 37 • 23 years ago

fixed on 6.2 branch, resolving fixed.

	Tom Everingham
	Comment 38 • 23 years ago

not seeing crash at the url listed

verified:  Win2000 branch 2001-11-26-18

	bsharma
	Comment 39 • 23 years ago

Verified on 2001-11-26-6.2.1 build on WinNT, Win98, Linux (7.2), Mac OS X, Mac
OS 9.1.

All the basic signed script test case passes. Following is the link to the suite
http://voodoolady.mcom.com/security/signedscripts

	benc
	Comment 40 • 23 years ago

Reporter: are you satisfied this is fixed?

	Jacob Kjome Reporter
	Comment 41 • 23 years ago

Yes, very much so!

I just re-verified that things work in the current build and everything checks 
out.  Thanks for getting this in :-)

Jake

	benc
	Comment 42 • 23 years ago

VERIFIED (094):
clicked on link, no crash, saw image.