Closed Bug 56851 Opened 24 years ago Closed 24 years ago

Triggering from trigger page fails

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jimmykenlee, Assigned: security-bugs)

References

Details

(Whiteboard: [rtm++])

Attachments

(2 files)

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
Ccing Sean, Samir, and Don. :-(
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
The SmartUpdate site and Theme Park are dead without this fix.
Priority: P3 → P1
Whiteboard: [rtm+ need info]
*** Bug 56729 has been marked as a duplicate of this bug. ***
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.
*** Bug 56960 has been marked as a duplicate of this bug. ***
*** Bug 56996 has been marked as a duplicate of this bug. ***
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
ccing vidur and jst for review
Looks good to me, r=jst
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.
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+]
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.
*** Bug 57099 has been marked as a duplicate of this bug. ***
Bruce Whitaker says this is critical for Netcenter.
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.
alert/confirm/prompt are not broken, I've tested this. We're good to go.
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.
Jimmy,
  How do I do that?
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!
*** Bug 56823 has been marked as a duplicate of this bug. ***
This patch works fine for me here on unix.

Anyone know when it is going to be checked into the truck?

--pete
The alert/confirm test works.
rtm++
Whiteboard: [rtm+] → [rtm++]
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.  
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
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.

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.
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?
CC'ing self.
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
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.
I was able to install PSM today on Linux x86 Build ID: 2000102008
I was just able to install both the URLs I mentioned earlier using the 
latest nightly:  2000102004

OS is Win NT 4.001381

-  Ben
confirm as fixed in 2000102004 in win98.  progress bar still broken, but that's
a whole other bug.
I can confirm this works also. I am running a FreeBSD debug build off of the
branch.
works fine.

--pete
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. :-)
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?
Fixed. 
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Wasn't there some concern about the fix compromising security? What was it?
Build: 2000-10-20-09-MN6(WIN), 2000-10-20-09-MN6(LINUX), 2000-10-20-08-MN6(MAC)

Verified for BRANCH.
Keywords: vtrunk
target, see the patch (should be readable for non-programmers. "!" means "not").
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: