76541 - XPI Installer Refuses to Install Themes

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Scott Tran (Wildcard)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.8.1+)
Gecko/20010417
BuildID:    2001041704

GrayModern at mozilla.themes.org couldnt install
http://www.kramm.org/graymodern/test/ was created and it seems Modern cant
install in XPI format either. 

Reproducible: Always
Steps to Reproduce:
1.Goto http://www.kramm.org/graymodern/test/
2.Click on Modern 2.0 Link
3.Notice theme appear to download 
4. Theme download window freezes

Actual Results:  Theme down window freezes 
Hangs the browser with a -207 "XPI package cannot be read" error in install.log


Expected Results:  XPI Installer works and Theme gets installed

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is that install script trying to install to the global chrome dir?  Is that dir
writable on your machine?  worksforme with linux build 2001-04-17-08, but I have
write permissions to all of the Moz install.

Comment 2

[Scott Tran (Wildcard)]

Boris: can u check if the GrayModern .083b theme at mozilla.themes.org installs 
as well ?

Comment 3

[Boris Zbarsky [:bzbarsky]]

I get a crash trying to install that...

Comment 4

[Keyser Sose]

Confirmed
Platform: PC
OS: Windows 98
Mozilla Build: 2001041804

Adding keywords and status board info. this is critical for 0.9

Comment 5

[Boris Zbarsky [:bzbarsky]]

ccing Asa to evaluate the 0.9 status of this.

Comment 6

[Asa Dotzler [:asa]]

anyone have any idea why this is failing.  Unless someone has a fix pretty ready
in the next coupld of days I don't think this'll make 0.9

Comment 7

[Scott Tran (Wildcard)]

I have a feeling the fix for Bug 53670 broke this, but I cant be sure

Comment 8

[Sean Su]

My JS foo isn't strong.  Any help is appreciated.  Here's some info.  I'm 
getting a lot of assertions when attempting to read Modern.xpi (I downloaded the 
file manually and simply clicked on the .xpi file on my local machine), but 
prior to the crash:

###!!! ASSERTION: nsPromptService not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsPromptService not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsPromptService not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsPromptService not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsPromptService not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsPromptService not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsPromptService not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsPromptService not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: GlobalWindowImpl not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsJSContext not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsJSContext not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsJSContext not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: nsJSContext not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524
###!!! ASSERTION: GlobalWindowImpl not thread-safe: 'owningThread == 
NS_CurrentThread()', file d:\trees\seamonkey\mozilla\xpcom\base\nsDebug.cpp, 
line 524

Here's a stack trace of the my crash:

NTDLL! 77f762e8()
js_Lock(JSThinLock * 0x00c56f18, long 9775552) line 934 + 40 bytes
js_AtomizeString(JSContext * 0x05fc18d0, JSString * 0x061ae8d0, unsigned int 
128) line 558 + 24 bytes
js_Atomize(JSContext * 0x05fc18d0, const char * 0x01405aa8, unsigned int 10, 
unsigned int 0) line 633 + 19 bytes
LookupProperty(JSContext * 0x05fc18d0, JSObject * 0x01f24ee8, const char * 
0x01405aa8, JSObject * * 0x061ae918, JSProperty * * 0x061ae910) line 2145 + 28 
bytes
JS_LookupProperty(JSContext * 0x05fc18d0, JSObject * 0x01f24ee8, const char * 
0x01405aa8, long * 0x061ae934) line 2303 + 25 bytes
nsXPCWrappedNativeScope::FindInJSObjectScope(XPCContext * 0x05b63b80, JSObject * 
0x01f24ee8) line 200 + 22 bytes
XPCConvert::NativeInterface2JSObject(JSContext * 0x05fc18d0, 
nsIXPConnectJSObjectHolder * * 0x061aea54, nsISupports * 0x06006130, const nsID 
* 0x01008020 iid, JSObject * 0x01f24ee8, unsigned int * 0x061ae9f0) line 886 + 
36 bytes
nsXPConnect::WrapNative(nsXPConnect * const 0x01478090, JSContext * 0x05fc18d0, 
JSObject * 0x01f24ee8, nsISupports * 0x06006130, const nsID & {...}, 
nsIXPConnectJSObjectHolder * * 0x061aea54) line 517 + 29 bytes
nsWindowWatcher::AddInterfaceTojsvals(nsISupports * 0x06006130, JSContext * 
0x05fc18d0, long * 0x06002320) line 1499 + 75 bytes
nsWindowWatcher::AddSupportsTojsvals(nsISupports * 0x06006130, JSContext * 
0x05fc18d0, long * 0x06002320) line 1521 + 17 bytes
nsWindowWatcher::ConvertSupportsTojsvals(nsIDOMWindow * 0x05fc1e14, nsISupports 
* 0x06006130, unsigned int * 0x061aed34, long * * 0x061aed2c) line 1476 + 17 
bytes
nsWindowWatcher::OpenWindow(nsWindowWatcher * const 0x00a30050, nsIDOMWindow * 
0x05fc1e14, const char * 0x01009878, const char * 0x01009ff8, const char * 
0x01009fd4, nsISupports * 0x06006130, nsIDOMWindow * * 0x061aed84) line 386 + 21 
bytes
nsPromptService::DoDialog(nsPromptService * const 0x04c055a4, nsIDOMWindow * 
0x05fc1e14, nsIDialogParamBlock * 0x06006130, const char * 0x01009878) line 513 
+ 77 bytes
nsPromptService::Confirm(nsPromptService * const 0x04c055a0, nsIDOMWindow * 
0x05fc1e14, const unsigned short * 0x06006cd0, const unsigned short * 
0x060023f0, int * 0x061af024) line 162 + 39 bytes
nsInstall::Confirm(nsString & {...}, int * 0x061af024) line 2535 + 60 bytes
InstallConfirm(JSContext * 0x05ca6e70, JSObject * 0x01fd6708, unsigned int 1, 
long * 0x04cf514c, long * 0x061af108) line 1670
js_Invoke(JSContext * 0x05ca6e70, unsigned int 1, unsigned int 0) line 813 + 23 
bytes
js_Interpret(JSContext * 0x05ca6e70, long * 0x061aff20) line 2706 + 15 bytes
js_Execute(JSContext * 0x05ca6e70, JSObject * 0x01fd6708, JSScript * 0x06000960, 
JSStackFrame * 0x00000000, unsigned int 0, long * 0x061aff20) line 992 + 13 
bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x05ca6e70, JSObject * 0x01fd6708, 
JSPrincipals * 0x00000000, const unsigned short * 0x0200df20, unsigned int 3439, 
const char * 0x00000000, unsigned int 0, long * 0x061aff20) line 3287 + 25 bytes
JS_EvaluateUCScript(JSContext * 0x05ca6e70, JSObject * 0x01fd6708, const 
unsigned short * 0x0200df20, unsigned int 3439, const char * 0x00000000, 
unsigned int 0, long * 0x061aff20) line 3269 + 35 bytes
JS_EvaluateScript(JSContext * 0x05ca6e70, JSObject * 0x01fd6708, const char * 
0x01fe8028, unsigned int 3439, const char * 0x00000000, unsigned int 0, long * 
0x061aff20) line 3236 + 33 bytes
RunInstallOnThread(void * 0x05fce4e0) line 438 + 30 bytes
_PR_NativeRunThread(void * 0x05fce2b0) line 399 + 13 bytes
_threadstartex(void * 0x05fce1b0) line 212 + 13 bytes
KERNEL32! 7

Comment 9

[Sean Su]

I did a quick test by having the native installer install modern.xpi, and it 
installed modern.jar fine to the mozilla/chrome dir, so it's not a 
problem with xpinstall itself.

fyi: When triggering the install of modern.xpi via the browser, the install.log 
created is 0 bytes for me, meaning that I didn't get error -207.

It looks like it might be a problem with the download dialog.  dbragg, can you 
help?

Comment 10

[Scott Tran (Wildcard)]

ssu: what OS are you on ? Boris said he got in running in Linux, maybe its only
a windows thing. BTW downloading the xpi to my hard drive and installing from
there also didnt work so I dunno

Comment 11

[dbragg]

Do these .xpi files have Alert or Confirm dialog calls in them?  If so, there's
a change in the way these are created.  Danm made the change from
nsICommonDialogs to nsIPromptService.  I've alerted him to this problem.  He's
going to look at it as soon as he can.

Please confirm if calls to these dialogs are in the themes .xpi files.  If so we
should re-assign the bug to danm.

Comment 12

[Sean Su]

yes, there is a call to confirm() in the install.js file.  I'll attach the file 
and reassign this bug danm.

BTW: I performed my crash test on NT4.0.

Comment 13

[Sean Su]

Attachment: install.js script from mordern.xpi

Comment 14

[Jimmy Lee]

Ccing myself.  I have some xpi test cases that also crash at alert/confirm 
dialogs.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Scott, I crash too now that I've updated my build

Comment 16

[Scott Tran (Wildcard)]

I'm changing OS to All since it looks like not everyone experiencing this is
using Windows 2000

Comment 17

[Benjamin Kramm]

modern.xpi with alert/confirm calls stripped from install.js doesn't crash for
me on W2K. Looks fine so far. But this workaround is not a viable option!
There are some new test xpi's @ http://www.kramm.org/graymodern/test/

Comment 18

[Benjamin Kramm]

Attachment: install.js without alert/confirm calls from modern_plain.xpi @ www.kramm.org/graymodern/test

Comment 19

[Frederic Crozat]

It seems XPI installer is no longer able to failback to user chrome directory
if it doesn't have write permission on system chrome directory.

This problem has appeared since Mozilla 0.8 and can be seen by
using Christopher Blizzard's rpm for Linux..

Comment 20

[Brian Teague]

cc'ing self.

confirming
Platform: PC
OS: Linux 
Build 2001042206 (this morning's builds).

however, the behaviour is somewhat different than that being reported
here. i've been playing with SkyPilot (from
http://www.netscape.com/themes/index.html), and the file skypilot.jar *is*
installed in my user's chrome directory. however, if i select "Use this   
theme" in the installation dialog, the theme isn't applied. seleting
SkyPilot from the "Apply Theme" menu doesn't help matters either: it seems
to reset all the visual elements, but i end up with "Classic" instead of  
the theme i want. visiting the Preferences dialog to try to apply the
theme from there crashes the browser.

subsequently, mozilla crashes on startup.  the output is:
Registering plugin 0 for: "*","All types",".*"
/usr/local/mozilla/run-mozilla.sh: line 72:  2708 Segmentation fault
$prog ${1+"$@"}

i can unjar the skypilot jar file just fine, and i assume jar is doing CRC
checking, so the file hasn't been corrupted.  (right?)

Comment 21

[dbragg]

Posting patch.  The problem was that the theme installers have alert or confirm
dialogs in them.  These are "blocking" calls in JS so we need to suspend the
request while they are executing, then resume the request when done.  Also, per
danm's request I made the change to nsInstall.cpp where the Confirm dialog was
not being created using the proxied dialog.

Comment 22

[dbragg]

Attachment: Path with JS_SuspendRequest and JS_ResumeRequest around Alert/Confirm code.

Comment 23

[Brian Teague]

is this gonna happen for 0.9?  or does "tree freeze in effect" mean what i think
it does?

Comment 24

[Scott Tran (Wildcard)]

Since this is marked critical for 0.9, I hope it makes it in

Comment 25

[Dan M]

0.9 isn't done just yet. it'll get into 0.9. r=danm.

Comment 26

[Brendan Eich [:brendan]]

Some day, fix the control flow to cast out the argc != 1 case with the early
false return and let the "main" code live at the same level as the final true
return, for both confirm and alert cases.  Also, why not initialize saveDepth
when it's declared?

Anyway, for 0.9, sr=[e-mail].

/be

Comment 27

[dbragg]

Good point Brendan.  I'll initialize saveDepth at it's declaration.  I assume I
don't have to post a new patch for something this small, right?

Comment 28

[Brendan Eich [:brendan]]

No, and I don't insist on a new patch even for transposing the argc == 1 and !=
1 cases and eliminating what would then be a useless else after return and
over-indented == 1 case that would lie right above the true return, but neither
of those is necessary for 0.9.  Your call -- don't break anything!

/be

Comment 29

[dbragg]

a=dbragg.  I'm on the xpinstall team and I'll be checking in the fix. Plus the
module owner (dveditz) is out on vacation.

Comment 30

[Brendan Eich [:brendan]]

dbragg: You mean r=, I think (some use moa= for module owner approval); drivers
use a= during freezes.  FYI.

asa, do it!

/be

Comment 31

[dbragg]

My bad.  I thought they wanted module owner approval because the bug is assigned
to Danm but it's in the xpinstall module.  I await the appropriate a=.

Comment 32

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to Mozilla 0.9  

Comment 33

[Dan M]

dbragg has checked in the patches.

Comment 34

[Keyser Sose]

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

Comment 35

[Grace Bush]

This is working but more than once- I installed, via steps on bug
went to view/apply themes and chose modern and I was asked to install again
is this supposed to happen?

used branch 2001060713 mozilla build

Comment 36

[Grace Bush]

verified on mozilla builds
2001072006 Win
2001072004 Linux
2001072003 Mac