Custom XPI (will attach shortly; it's an en-GB language pack). If I click on a link to it over HTTP (e.g. http://my-apache-server/langengb.xpi), Moz crashes (and my win98 box becomes *very* unstable :-( ). If I right-click on the HTTP link, and save-as to local hard disk, then file=>open, select the XPI file, the installer kicks off as normal. IIRC this happens on W2K also.

D'oh, couldn't attach, sorry, didn't realise. XPI file available here: http://rudolf.org.uk/bug-161336-langengb.xpi

Can you provide a talkback ID from that crash ?

I'm not sure that I got an opportunity to send talkback, I can't quite remember. I did say it made my machine *very* unstable :-( If I make it crash again, and I get to do talkback, how do I know what talkback ID it is?

a) what is the windows crash message ? b) run mozilla/components/talkback.exe to get the ID after Talkback submitted the crash.

Windows message is: invalid page fault in GKLayout.dll Talkback ID is: TB9036853G, 6 Aug 19:55hrs, comment "Click on custom XPI". Talkback incident list could do with a "copy to clipboard" feature ;-)

URL with MIME type application/x-xpinstall so that Mozilla will try to download it: http://www.epita.fr:8000/~cahagn_o/mozbug/161336/langengb.xpi I didn't acheive to crash build 20020805 on Linux (trunk), no outstanding warnings, just a JavaScript popup with err=0 at the end of the installation.

The URL with the right content-type works OK (it popped up the "install?" question at least, I didn't bother actually doing the install). So it looks like the bug is activated by the fact that it's trying to render the XPI file as text/plain. Let me know if you need any more talkback data from other platforms or whatever, e.g. Win2K box at work.

TB9036853G gives the following stack: ArabicShaping [c:/builds/seamonkey/mozilla/content/shared/src/nsBidiUtils.cpp, line 341] XPCOM.DLL + 0x4d2c4 (0x60ecd2c4) 0xc3c2c1c0 seems kinda out of place....

Dave, if you really are crashing at ArabicShaping, you should try a build later than 7/25 (this crash was with the 07-22 build). Bug 158796 - fixed 7/25. Try it out. Though Boris is right, this stack seems out of place.

Okay, tried latest build (2002081209). It no longer crashes. But: The page did take an extraordinarily long time to load, during which time Moz was unresponsive (no window redraw, etc). Eventually, the page *did* render, and everything went back to normal. Watching with Ethereal (having seen the problem first without), the total duration of the HTTP transaction was approx 235 seconds: downloading the same URL using "save as" was nearer 14 seconds, which is rather more like the expected value for my connection. My wild stab in the dark at an explanation would be that somehow the effort of trying to lay out a binary file as text/plain is slowing down the network side of things. But that's a *really* uninformed guess. ;-)

it probably interpreted the binary as international multi-byte characters and then banged through all of the available fonts looking for glyphs (which would be rather futile). That would explain the slow performance and the crash in Arabic-land.

So, the problem was that the content-type was not appropriate for the actual content (i.e. you can't sensibly display a "zip" file as text/plain). Given that so far this has produced two different types of unwanted behaviour (crash, slowdown), is the answer: (a) don't do that (i.e. if the web server feeds us rubbish, what do you expect?); or (b) try to detect the presumed "error" and do something about it? I suppose (a) is probably the only sensible answer. Fortuitously, it's also the easiest to implement ;-)

*** This bug has been marked as a duplicate of 158796 ***

Verified as dupe.