Community
Participate
Eclipse IDE
I am using the swt browser widget on Suse linux 9.1 with Mozilla 1.7. I try to access html pages with forms that have <input type="file"...> and get the following exception thrown: unable to open file picker [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIBaseWindow.blurSuppression]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: file:///home/ratkinson/Projects/iMan25/iManager/run/bin/linux/mozilla/components/nsFilePicker.js :: anonymous :: line 213" data: no] The file chooser window never comes up. Some example html code: <form enctype="multipart/form-data" method="post"> <p> Please specify a file, or a set of files:<br> <input type="file" name="myfiles" size="40"> </p> </form>
Please update the satus of this bug. It was entered 7 months ago and is still listed as NEW. If nobody is going to fix this then I will look at writing code to fix the problem. Thanks.
NS_ERROR_NOT_IMPLEMENTED looks like it might be a problem in Mozilla itself. Note that if a bug is marked NEW that just means it's still open (at least the way we use bugzilla). Please feel free to help investigate any of our open bugs. I guess it's unfortunate that you can't tell from bugzilla whether someone is actively working on a problem, but I'm not sure how useful that would be anyway.
I believe the fix for this will be very similar to the fix for bug 60975.
Bugs to investigate will be prioritized this week. This should be one of them.
ok, it's a missing nsIFilePicker implementation. This will be fixed soon.
Hi Grant, We are at the end of our development for one of our products, this bug fix is critical to our product. Is there anyway you could give us an estimate as to when you will have a fix for this problem?
I released a fix to HEAD earlier this afternoon for gtk, and will have the analagous change released on motif tomorrow morning. The only thing I haven't tested yet is gtk on 64-bit. So how do you want to get these changes? Are you planning to have a release later based on eclipse 3.1.1? Or do you want a patch attached here so that you can do something with it? It's a pretty large change, but is quite isolated in nature.
Could you please attach the patch here?
Backporting this to 3.0.2 has been more involved than I expected, but I've got it working on gtk. Attached next is the patch that's needed for swt-gtk, followed by the updated swt-mozilla library. The equivalent backport to motif is crashing for me, though it's working fine in HEAD. I'll keep looking into this, but if you don't care about motif (ie.- it's not a target platform for you) then please follow up here, as there's no other reason to try to make this work in 3.0.2.
Created attachment 26547 [details] patch for gtk, based on 3.0.2
Created attachment 26548 [details] updated swt-mozilla library (gtk)
ok, I figured out what was happening on motif. The 3.0.2 patch and library for it are attached next. Important: note that the motif patch requires that the gtk patch be applied first, because the gtk patch contains some shared code that the motif patch does not contain but does need to use.
Created attachment 26559 [details] 3.0.2 patch for swt-motif
Created attachment 26560 [details] updated swt-mozilla library (motif)
mozilla interface nsIFilePicker is unfrozen, so added comment to mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=248683#c19 . Marking report as fixed > 0826. Beth if you still have questions regarding 3.0.2 then feel free to append them here.
Hi Grant, I've applied your patch and rebuilt the SWT jars, and they seem to get farther with the old .so file (i.e. the Browse dialog appears - but then other errors occur, as expected), however, when I use your new .so file, I'm getting an UnsatisfiedLinkError -- complaining that it cannot find libstdc++.so.6. Is libstdc++.so.6 a requirement for this new .so? Didn't seem to be for the old one... Is there any way this can be recompiled against libstdc++.so.5?
Hi Grant, Thanks for porting the fix to 3.0.2, looks like we are very close except the libaray mismatch that Daniel had found. Is it possible that this can be recompiled against libstdc++.so.5?
Created attachment 26566 [details] (gtk) new swt-mozilla library for swt, recompiled to not depend on libstdc++.so.6 ok, these should be better...
Created attachment 26567 [details] (motif) new swt-mozilla library for swt, recompiled to not depend on libstdc++.so.6
This has been backported to the 3.1.1 stream as well.
