Closed
Bug 54461
Opened 24 years ago
Closed 2 years ago
Assertion: no components in scope (nsFilePicker.js) on Save
Categories
(Firefox :: File Handling, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jesup, Unassigned)
References
()
Details
Attachments
(1 file)
11.91 KB,
text/plain
|
Details |
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
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 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•24 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?
nav triage team: Probably should at least look at this. Marking nsbeta1, p4, mozilla0.9
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla1.0
Comment 5•24 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 = 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?
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.
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
Comment 8•23 years ago
|
||
spam: over to File Handling.
Component: XP Apps → File Handling
QA Contact: jrgm → sairuh
Updated•22 years ago
|
QA Contact: sairuh → petersen
Updated•15 years ago
|
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Updated•8 years ago
|
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
Reporter | ||
Updated•2 years ago
|
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•