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




File Handling
18 years ago
2 years ago


(Reporter: jesup, Unassigned)


Firefox Tracking Flags

(Not tracked)




(1 attachment)



18 years ago
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;1 which resolves to rel:nsFilePicker.js.

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

Attaching backtrace/structure dump

Comment 1

18 years ago
Created attachment 15689 [details]
gdb backtrace/structure dump

Comment 2

18 years ago
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). 
Assignee: trudelle → law
Component: XP Toolkit/Widgets → XP Apps

Comment 3

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

18 years ago
nav triage team:

Probably should at least look at this. Marking nsbeta1, p4, mozilla0.9
Keywords: nsbeta1
Priority: P3 → P4
Target Milestone: --- → mozilla0.9


18 years ago
Target Milestone: mozilla0.9 → mozilla1.0

Comment 5

18 years ago
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 =
+        } 

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

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

18 years ago
I can't get to for some reason.

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

I'm going to minus this one.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → ---

Comment 7

18 years ago
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
spam: over to File Handling.
Component: XP Apps → File Handling
QA Contact: jrgm → sairuh
QA Contact: sairuh → petersen
Assignee: law → nobody
QA Contact: chrispetersen → file-handling


2 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.