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

RESOLVED FIXED in Firefox 17

Status

()

Firefox
General
--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: mats, Assigned: bbondy)

Tracking

({regression})

Trunk
Firefox 17
x86_64
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 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

5 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

5 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

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

Comment 4

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

Updated

5 years ago
Blocks: 731307
(Assignee)

Comment 5

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

Comment 6

5 years ago
Created attachment 654489 [details] [diff] [review]
Patch v1
(Assignee)

Comment 7

5 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)
Attachment #654489 - Flags: review?(roc) → review+
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

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

Comment 10

5 years ago
Created attachment 654887 [details] [diff] [review]
Patch v2
(Assignee)

Comment 11

5 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

5 years ago
Attachment #654489 - Flags: review+
(Assignee)

Updated

5 years ago
Attachment #654489 - Attachment is obsolete: true
(Assignee)

Updated

5 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

5 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

5 years ago
np thanks for the feedback and suggestion.
(Assignee)

Comment 16

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/730c4f0ec3ae
Target Milestone: --- → Firefox 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. 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
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Comment 19

5 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

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