Exception... "'JavaScript component does not have a method named: "open"' when calling method: [nsIFilePicker::open]"

RESOLVED FIXED in Firefox 17

Status

()

defect
--
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: mats, Assigned: bbondy)

Tracking

({regression})

Trunk
Firefox 17
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

7 years ago
This bug only occurs in my default profile, it works fine
in a fresh profile... but still, it seems something broke
in the past few days...

STEPS TO REPRODUCE
1. go to a bug in Bugzilla, such as this one
2. click "Add an attachment"
3. click "Browse"

ACTUAL RESULTS
Error: [Exception... "'JavaScript component does not have a method named: "open"' when calling method: [nsIFilePicker::open]"  nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no]

PLATFORMS AND BUILDS TESTED
Bug occurs in Nightly 2012-08-22 on Linux64
Reporter

Comment 1

7 years ago
2012-08-17-03-05-55 works
2012-08-18-03-06-04 broken

Brian, bug 731307 seems to be in that range?
Keywords: regression
Reporter

Comment 2

7 years ago
Resetting ui.allow_platform_file_picker to false fixes it.
I had it set to true because I don't like the GTK file picker.

Comment 3

7 years ago
AFAIK, many Linux distros set this pref that way by default.
Reporter

Comment 4

7 years ago
Oops, I mixed up true/false in comment 2.  Hopefully it's clear what
I meant anyway.
Reporter

Updated

7 years ago
Blocks: 731307
Assignee

Comment 5

7 years ago
Didn't know that existed :) I'll fix that shortly.
Assignee: nobody → netzen
Assignee

Comment 6

7 years ago
Posted patch Patch v1 (obsolete) — Splinter Review
Assignee

Comment 7

7 years ago
Comment on attachment 654489 [details] [diff] [review]
Patch v1

Tested on linux
Attachment #654489 - Attachment description: WIP - untested → Patch v1
Attachment #654489 - Flags: review?(roc)
You can pass a JS function object directly to dispatch (no need for the object with the "run" property), since nsIRunnable is a [function]-annotated interface.
Assignee

Comment 9

7 years ago
Oh cool, thanks for the info, I'll update it a bit later today.
Assignee

Comment 10

7 years ago
Posted patch Patch v2Splinter Review
Assignee

Comment 11

7 years ago
Comment on attachment 654887 [details] [diff] [review]
Patch v2

Updated patch to not use an object with a run property and instead use a function directly.  Tested on linux with the perf set and it's working.
Attachment #654887 - Flags: review?(gavin.sharp)
Assignee

Updated

7 years ago
Attachment #654489 - Flags: review+
Assignee

Updated

7 years ago
Attachment #654489 - Attachment is obsolete: true
Assignee

Updated

7 years ago
Attachment #654887 - Attachment description: Patch v2 - WIP - untested → Patch v2
Comment on attachment 654887 [details] [diff] [review]
Patch v2

That specific part looks fine, haven't reviewed the rest of the patch (I don't think you need re-review for this nit :)
Attachment #654887 - Flags: review?(gavin.sharp) → feedback+
Assignee

Comment 13

7 years ago
Comment on attachment 654887 [details] [diff] [review]
Patch v2

OK thanks, carrying forward roc's r+.  There is no other part to this patch by the way.  The async filepicker method has already landed.
Attachment #654887 - Flags: review+
I know, but I'm on a phone and am not able to look up interface details or otherwise look into this enough to grant r+.
Assignee

Comment 15

7 years ago
np thanks for the feedback and suggestion.
Comment on attachment 654887 [details] [diff] [review]
Patch v2

>+      try {
>+        let result = this.show();
>+        aFilePickerShownCallback.done(result);
>+      } catch(ex) {
>+        aFilePickerShownCallback.done(this.returnCancel);
>+      }
I'm not convinced that show() can actually throw; it's certainly got enough try/catch blocks of its own. On the other hand, the callback could throw, and in that case you would attempt to call the callback again. Now you try to pass returnCancel, but JavaScript doesn't inherit interfaces in the same way C++ does, so you needed to use nsIFilePicker.returnCancel, instead you end up passing undefined; I can't remember whether XPConnect throws or casts it to zero.
https://hg.mozilla.org/mozilla-central/rev/730c4f0ec3ae
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Assignee

Comment 19

7 years ago
(In reply to neil@parkwaycc.co.uk from comment #17)
> Comment on attachment 654887 [details] [diff] [review]
> Patch v2
> 
> >+      try {
> >+        let result = this.show();
> >+        aFilePickerShownCallback.done(result);
> >+      } catch(ex) {
> >+        aFilePickerShownCallback.done(this.returnCancel);
> >+      }
> I'm not convinced that show() can actually throw; it's certainly got enough
> try/catch blocks of its own. On the other hand, the callback could throw,
> and in that case you would attempt to call the callback again. 

Good point I'll fix that along with your previous mention of NS_ENSURE_ARG_POINTER in a new bug since I already pushed this to m-i.

> Now you try
> to pass returnCancel, but JavaScript doesn't inherit interfaces in the same
> way C++ does, so you needed to use nsIFilePicker.returnCancel, instead you
> end up passing undefined; I can't remember whether XPConnect throws or casts
> it to zero.

Doh ya, this code was the same as the mockfilepicker, but it has this at the top which makes it work correctly: returnCancel: Ci.nsIFilePicker.returnCancel,
Assignee

Comment 20

7 years ago
Comment 17 fixed in Bug 785744
You need to log in before you can comment on or make changes to this bug.