Closed
Bug 56851
Opened 24 years ago
Closed 24 years ago
Triggering from trigger page fails
Categories
(Core Graveyard :: Installer: XPInstall Engine, defect, P1)
Core Graveyard
Installer: XPInstall Engine
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: jimmykenlee, Assigned: security-bugs)
References
Details
(Whiteboard: [rtm++])
Attachments
(2 files)
5.47 KB,
text/plain
|
Details | |
2.40 KB,
patch
|
Details | Diff | Splinter Review |
Build: 2000-10-16-09-MN6(WIN), 2000-10-16-08-MN6(MAC), 2000-10-16-09-MN6(MAC) 1. From http://jimbob/trigger3.html, attempt to trigger any xpi package RESULT: Nothing happens. We are able to trigger xpis via mimetype support. EXPECTED RESULT: Confirm dialog appears indicating which xpi package will be downloaded and installed. NOTE: This broke during the weekend. 10/13/00 was working.
Nominating for rtm. This needs to be fixed. All websites will not be able to install any packages. Netscape 6 will not be able to upgraded.
Keywords: rtm
Comment 3•24 years ago
|
||
Investigating on Windows.
Looks like the problem might be in nsScriptSecurityManager.cpp's CheckLoadURI(). According to mstolz it's failing because we're using a chrom url for our style sheet which should be ok. Adding him to the CC list and pasting the stack trace up to that point.
A little more information. The problem shows up when we try to create our confirm dialog. The .xul file is in xpinstall/res/content/institems.xul.
Reassigning to mstoltz. Per discussion with him. (Thanks for looking at this so quickly Mitch!)
Assignee: dveditz → mstoltz
Comment 8•24 years ago
|
||
The SmartUpdate site and Theme Park are dead without this fix.
Priority: P3 → P1
Whiteboard: [rtm+ need info]
Comment 10•24 years ago
|
||
Since this started happening on the 14th, I went back and tested win32 builds from that day. 2000-10-14-09-MN6 is the last "healthy" win32 build. This bug takes hold in the 2000-10-14-09-Mtrunk win32 build and persists through to today's nightly (2000101609). Hopefully this helps track down the misbehaving code.
Comment 11•24 years ago
|
||
*** Bug 56960 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
*** Bug 56996 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 13•24 years ago
|
||
I have a fix, but I'm a little worried about what the fix will do to our security, so I'm exploring alternatives.
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•24 years ago
|
||
Assignee | ||
Comment 15•24 years ago
|
||
ccing vidur and jst for review
Comment 16•24 years ago
|
||
Looks good to me, r=jst
Comment 17•24 years ago
|
||
Not knowing all the security issues I don't know what my review is worth but I applied the patch to my local tree and XPInstall's confirm dialog is showing up correctly when using triggers. i.e. looks like the patch works.
Comment 18•24 years ago
|
||
Need a super-review, but I'll mark rtm+ in anticipation of getting it. This patch fixes the XPInstall problem and we desperately need it.
Whiteboard: [rtm+ need info] → [rtm+]
Comment 19•24 years ago
|
||
This bug also happens to fix the crasher bug: http://bugzilla.mozilla.org/show_bug.cgi?id=54896 They are not the same bugs, but are somehow related.
Comment 20•24 years ago
|
||
*** Bug 57099 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
Bruce Whitaker says this is critical for Netcenter.
Comment 22•24 years ago
|
||
sr=vidur. As I mentioned to Mitch yesterday, I'm not as concerned about the mechanism of enforcement (i.e. the pref that prevents scripts from calling openDialog). The security prefs as a whole are an important part of our enforcement and modification of any of them will open us to exploits. Assuming window.alert/confirm/prompt are not broken (as they were by a prior security fix in openDialog), this is good to go.
Assignee | ||
Comment 23•24 years ago
|
||
alert/confirm/prompt are not broken, I've tested this. We're good to go.
Reporter | ||
Comment 24•24 years ago
|
||
Mitch...Can you kindly check alerts/confirms called from an xpi package? One of my regular tests is to run this package: http://jimbob/jars/f_alertconfirm.xpi I'm going to check this test anyway, but there can be differences. Bug 55974 is evidence of one difference. Thanks.
Assignee | ||
Comment 25•24 years ago
|
||
Jimmy, How do I do that?
Reporter | ||
Comment 26•24 years ago
|
||
From your seamonkey browser, just open http://jimbob/jars/f_alertconfirm.xpi. When you accept the warning of XPInstall confirm dialog, instead of installing a file, directory, etc, an alert and then a confirm dialog should appear. That's it. It's just a test to verify that alerts/confirms can be generated from an xpi package. Thanks!
Comment 27•24 years ago
|
||
*** Bug 56823 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
This patch works fine for me here on unix. Anyone know when it is going to be checked into the truck? --pete
Assignee | ||
Comment 29•24 years ago
|
||
The alert/confirm test works.
Comment 31•24 years ago
|
||
Win NT 4.001381 using build 2000101904 downloaded this morning. It still doesn't work, but action is actually worse than yesterday from a user standpoint. The browser freezes and I had to use taskmanager to cancell it after trying each of the following URLs: http://docs.iplanet.com/docs/manuals/psm/psm-mozilla/index.html after "pressing/clicking" the button, it launched a second browser with the same content as the first. yesterday this second browser had the 210 error message. browser locked, cancelled via taskmanager http://sites.netscape.net/dinoproject/patches.html after press/click the error 210 small popup window appeared, just as yesterday. however, again the browser froze & I was forced to use taskmanager to cancell it. see: http://bugzilla.mozilla.org/show_bug.cgi?id=56996 for details from yesterdays build.
Comment 32•24 years ago
|
||
W/out building w/ the provided patch, i have the exact same thing on unix. link doesn't do anything, then she crashes upon any subsequent page load. Looks like no change to me. --pete
Comment 33•24 years ago
|
||
confirm ben's results on mtrunk 101904 for win98. however, an interesting complication: xpinstalling a new skin from x.themes.org works just fine, both download and quick methods. i don't believe it did on earlier builds.
Comment 34•24 years ago
|
||
Another interesing addition to ben's comment: (PC/Linux 2000101908 here) When it hangs, one of the threads is eating all the CPU. Probably an infinite loop somewhere. Also, I saw no popup. It hangs as soon as I click the 'Install' button in the page (for both PSM and Java). I'll try to use gdb to generate a stack trace.
Comment 35•24 years ago
|
||
OK, here it is. ~/mozilla$ gdb mozilla-bin 1739 GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found)... /home/cesarb/mozilla/1739: No such file or directory. Attaching to program: /home/cesarb/mozilla/mozilla-bin, Pid 1739 [...lots of spam removed...] [New Thread 1024 (runnable)] [New Thread 2049 (runnable)] [New Thread 1026 (runnable)] [New Thread 4101 (runnable)] [...more spam removed...] 0x4012090c in js_MarkGCThing () from /home/cesarb/mozilla/libmozjs.so (gdb) where #0 0x4012090c in js_MarkGCThing () from /home/cesarb/mozilla/libmozjs.so #1 0x40121064 in js_GC () from /home/cesarb/mozilla/libmozjs.so #2 0x40120a43 in js_ForceGC () from /home/cesarb/mozilla/libmozjs.so #3 0x4010694d in JS_GC () from /home/cesarb/mozilla/libmozjs.so #4 0x40106993 in JS_MaybeGC () from /home/cesarb/mozilla/libmozjs.so #5 0x40387915 in nsJSContext::ScriptEvaluated () from /home/cesarb/mozilla/libjsdom.so #6 0x403868f4 in nsJSContext::ExecuteScript () from /home/cesarb/mozilla/libjsdom.so #7 0x4080b6f8 in NSGetModule () from /home/cesarb/mozilla/components/librdf.so #8 0x4080b3a6 in NSGetModule () from /home/cesarb/mozilla/components/librdf.so #9 0x4080ab7e in NSGetModule () from /home/cesarb/mozilla/components/librdf.so #10 0x4080e1ab in NSGetModule () from /home/cesarb/mozilla/components/librdf.so #11 0x409558e1 in NSGetModule () from /home/cesarb/mozilla/components/liburiloader.so #12 0x40aa4a07 in NSGetModule () from /home/cesarb/mozilla/components/libchrome.so #13 0x400c2983 in PL_HandleEvent () from /home/cesarb/mozilla/libxpcom.so #14 0x400c28a6 in PL_ProcessPendingEvents () from /home/cesarb/mozilla/libxpcom.so #15 0x400c35fd in nsEventQueueImpl::ProcessPendingEvents () from /home/cesarb/mozilla/libxpcom.so #16 0x40486ccf in NSGetModule () ---Type <return> to continue, or q <return> to quit--- from /home/cesarb/mozilla/components/libwidget_gtk.so #17 0x40486a8d in NSGetModule () from /home/cesarb/mozilla/components/libwidget_gtk.so #18 0x4062ac10 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0 #19 0x4062c2d9 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 #20 0x4062c8e3 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 #21 0x4062c995 in g_main_iteration () from /usr/lib/libglib-1.2.so.0 #22 0x4048722c in NSGetModule () from /home/cesarb/mozilla/components/libwidget_gtk.so #23 0x40432d8f in inflate_mask () from /home/cesarb/mozilla/components/libnsappshell.so #24 0x4043259a in inflate_mask () from /home/cesarb/mozilla/components/libnsappshell.so #25 0x4042ebfc in inflate_mask () from /home/cesarb/mozilla/components/libnsappshell.so #26 0x4039b287 in GlobalWindowImpl::OpenInternal () from /home/cesarb/mozilla/libjsdom.so #27 0x403982f5 in GlobalWindowImpl::Open () from /home/cesarb/mozilla/libjsdom.so #28 0x4038f120 in NS_CreateScriptContext () from /home/cesarb/mozilla/libjsdom.so #29 0x401224fc in js_Invoke () from /home/cesarb/mozilla/libmozjs.so #30 0x40128d64 in js_Interpret () from /home/cesarb/mozilla/libmozjs.so ---Type <return> to continue, or q <return> to quit--- #31 0x40122544 in js_Invoke () from /home/cesarb/mozilla/libmozjs.so #32 0x4012273c in js_InternalInvoke () from /home/cesarb/mozilla/libmozjs.so #33 0x4010906f in JS_CallFunctionValue () from /home/cesarb/mozilla/libmozjs.so #34 0x40340ab7 in NSGetModule () from /home/cesarb/mozilla/components/libxpinstall.so #35 0x400c2983 in PL_HandleEvent () from /home/cesarb/mozilla/libxpcom.so #36 0x400c28a6 in PL_ProcessPendingEvents () from /home/cesarb/mozilla/libxpcom.so #37 0x400c35fd in nsEventQueueImpl::ProcessPendingEvents () from /home/cesarb/mozilla/libxpcom.so #38 0x40486ccf in NSGetModule () from /home/cesarb/mozilla/components/libwidget_gtk.so #39 0x40486a8d in NSGetModule () from /home/cesarb/mozilla/components/libwidget_gtk.so #40 0x4062ac10 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0 #41 0x4062c2d9 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 #42 0x4062c8e3 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 #43 0x4062ca7c in g_main_run () from /usr/lib/libglib-1.2.so.0 #44 0x405521e7 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #45 0x404871bc in NSGetModule () from /home/cesarb/mozilla/components/libwidget_gtk.so #46 0x4043496a in inflate_mask () from /home/cesarb/mozilla/components/libnsappshell.so ---Type <return> to continue, or q <return> to quit--- #47 0x804e1b5 in JS_PushArguments () #48 0x804e5d6 in JS_PushArguments () #49 0x4025da42 in __libc_start_main () from /lib/libc.so.6 (gdb) detach Detaching from program: /home/cesarb/mozilla/mozilla-bin, process 1739 (gdb) q Did that help? Or should I try to download something which showed the parameters too?
Comment 36•24 years ago
|
||
CC'ing self.
Comment 37•24 years ago
|
||
Although this bug got the rtm-double-plus, I would suspect that the patch has not yet been checked in (trunk or branch)... and that is why it is still broken. Mitch: Any ETA for the anxious onlookers?... or has this landed? Thanks, Jim
Comment 38•24 years ago
|
||
ratman@medmail.com: >however, an interesting complication: xpinstalling a new skin from x.themes.org >works just fine, both download and quick methods. i don't believe it did on >earlier builds. I've installed skins from themes.org prior to the 1019 nightly on Win98se.
Comment 39•24 years ago
|
||
I was able to install PSM today on Linux x86 Build ID: 2000102008
Comment 40•24 years ago
|
||
I was just able to install both the URLs I mentioned earlier using the latest nightly: 2000102004 OS is Win NT 4.001381 - Ben
Comment 41•24 years ago
|
||
confirm as fixed in 2000102004 in win98. progress bar still broken, but that's a whole other bug.
Comment 42•24 years ago
|
||
I can confirm this works also. I am running a FreeBSD debug build off of the branch. works fine. --pete
Reporter | ||
Comment 43•24 years ago
|
||
I can confirm that triggering now behaves as expected from the BRANCH. It seems that this bug reports status needs to be marked FIXED unless there is still some unfinished business. You fix'em, I verify'em. :-)
Comment 44•24 years ago
|
||
I applied the patch earlier today and got no errors -> it was not checked in. I am using the trunk. Mitch, did you check this into the branch only, but not the trunk?
Assignee | ||
Comment 45•24 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 46•24 years ago
|
||
Wasn't there some concern about the fix compromising security? What was it?
Reporter | ||
Comment 47•24 years ago
|
||
Build: 2000-10-20-09-MN6(WIN), 2000-10-20-09-MN6(LINUX), 2000-10-20-08-MN6(MAC) Verified for BRANCH.
Keywords: vtrunk
Comment 48•24 years ago
|
||
target, see the patch (should be readable for non-programmers. "!" means "not").
Reporter | ||
Comment 49•24 years ago
|
||
Build: 2000-11-07-08-Mtrunk(WIN), 2000-11-07-08-Mtrunk(MAC), 2000-11-07-08-Mtrunk(LINUX) Works fine from the TRUNK. Marking Verified. Removing vtrunk from Keywords.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•