54461 - Assertion: no components in scope (nsFilePicker.js) on Save

Status: RESOLVED WORKSFORME

(Firefox :: File Handling, defect, P4)

Description

[Randell Jesup [:jesup] (needinfo me)]

FreeBSD 4.1 20000927xx

Clicked on an octet-stream (see URL - bugzilla attachment to bug 54338).
requester comes up, asks if I want to Save File, etc.  I hit the More Info
button that makes it send the mozilla window to the plugin finder.  Then I hit
the Save File button and get this assertion.

It's trying to load @mozilla.org:filepicker;1 which resolves to rel:nsFilePicker.js.

###!!! ASSERTION: No 'Components' in scope!: '0', file
xpcwrappednativescope.cpp, line 156

Attaching backtrace/structure dump

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: gdb backtrace/structure dump

Comment 2

[John Morrison]

Okay, I can't reproduce this on a linux build, although I do get a series
of JS exceptions when I actually download the file. 

The 'No Components in scope.' refers to the Components object that (should be)
in scope for any JS running in the browser. This came up once before, and 
it was related to the hand-offs going on with stream transfers, etc. (sorry
for the poor explanation/hand-waving). 

At any rate, law knows more about this I'm sure (I think nsFilePicker.js is 
just a victim in not getting the Components object in scope). 

Comment 3

[Peter "jag" Annema]

I've seen this recently while playing with nsIFindComponent from
viewsource.js... Shall I file a new bug on it or can we make this one generic?

Comment 4

[Paul Chen]

nav triage team:

Probably should at least look at this. Marking nsbeta1, p4, mozilla0.9

Comment 5

[Peter "jag" Annema]

smfr reported seeing this problem (No components in scope) in a recent
viewsource window:

View a page's source, open the find dialog (accel+f), close it, open the dialog
again: it won't open and you'll get the exception in your console.

I originally saw it after completely removing appCore from viewsource.js, smfr
is seeing it with appCore still in there. The change I'm suspecting is causing
this is:

   try {
-      if (window.arguments && window.arguments[1]) {
-          if (window.arguments[1].indexOf('charset=') != -1) {
-              var arrayArgComponents = window.arguments[1].split('=');
-              if (arrayArgComponents) {
-                appCore.SetDocumentCharset(arrayArgComponents[1]);
-              } 
-          }
+    if ("arguments" in window && window.arguments.length >= 2) {
+      if (window.arguments[1].indexOf('charset=') != -1) {
+        var arrayArgComponents = window.arguments[1].split('=');
+        if (arrayArgComponents) {
+          docShellElement.markupDocumentViewer.defaultCharacterSet =
arrayArgComponents[1];
+        } 
       }
   }

Undoing that change (or simply commenting it out) seemed to "fix" (or trigger
less often, I forgot) this problem for me in my whacked version of
viewsource.js.

jband: we discussed this a couple of months ago. Now that the "trigger find"
related JS is taken out of the picture (since that's still done through appCore
like it always was), any idea what else might be causing this?

Comment 6

[Bill Law]

I can't get to https://mail.ple.org/horde/imp for some reason.

If I go there with IE, I can't login as "testuser."

I'm going to minus this one.

Comment 7

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar.

Comment 8

[sairuh (rarely reading bugmail)]

spam: over to File Handling.