Triggering from trigger page fails

VERIFIED FIXED

Status

Core Graveyard
Installer: XPInstall Engine
P1
blocker
VERIFIED FIXED
18 years ago
2 years ago

People

(Reporter: Jimmy Lee, Assigned: Mitchell Stoltz (not reading bugmail))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm++])

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
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
(Reporter)

Comment 2

18 years ago
Ccing Sean, Samir, and Don. :-(

Comment 3

18 years ago
Investigating on Windows.

Comment 4

18 years ago
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.

Comment 5

18 years ago
Created attachment 17289 [details]
Stack trace up to CheckLoadURI

Comment 6

18 years ago
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.

Comment 7

18 years ago
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. ***

Comment 10

18 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

18 years ago
*** Bug 56960 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
*** Bug 56996 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

18 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

18 years ago
Created attachment 17378 [details] [diff] [review]
Patch - please review
(Assignee)

Comment 15

18 years ago
ccing vidur and jst for review
Looks good to me, r=jst

Comment 17

18 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.
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

18 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

18 years ago
*** Bug 57099 has been marked as a duplicate of this bug. ***

Comment 21

18 years ago
Bruce Whitaker says this is critical for Netcenter.

Comment 22

18 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

18 years ago
alert/confirm/prompt are not broken, I've tested this. We're good to go.
(Reporter)

Comment 24

18 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

18 years ago
Jimmy,
  How do I do that?
(Reporter)

Comment 26

18 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

18 years ago
*** Bug 56823 has been marked as a duplicate of this bug. ***

Comment 28

18 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

18 years ago
The alert/confirm test works.

Comment 30

18 years ago
rtm++
Whiteboard: [rtm+] → [rtm++]

Comment 31

18 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

18 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

18 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

18 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

18 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

18 years ago
CC'ing self.

Comment 37

18 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

18 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

18 years ago
I was able to install PSM today on Linux x86 Build ID: 2000102008

Comment 40

18 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

18 years ago
confirm as fixed in 2000102004 in win98.  progress bar still broken, but that's
a whole other bug.

Comment 42

18 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

18 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

18 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

18 years ago
Fixed. 
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 46

18 years ago
Wasn't there some concern about the fix compromising security? What was it?
(Reporter)

Comment 47

18 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

18 years ago
target, see the patch (should be readable for non-programmers. "!" means "not").
(Reporter)

Comment 49

18 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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.