cannot call methods on fileupload prior to initialization

[oliverbob]

I get this message from the console when trying to add audio or video right after images are being uploaded first.

jquery-3.5.0.min.js:2 Uncaught Error: cannot call methods on fileupload prior to initialization; attempted to call method 'add' at Function.error (jquery-3.5.0.min.js:2) at HTMLInputElement. (jquery.ui.widget.js:266) at Function.each (jquery-3.5.0.min.js:2) at S.fn.init.each (jquery-3.5.0.min.js:2) at S.fn.init.$.fn. [as fileupload] (jquery.ui.widget.js:256) at MediaRecorder. (jquery.fancy-fileupload.js:623)

Also, I notice that when the webcam is turned on, there is no way to turn it off except to refresh the page.

The weird thing is that sometimes, the camera or the mic sometimes take time to initialize. Sometimes, they don't initialize. And when you upload a file first and then call them, it yields the same error as quoted above. The same issue happens when you get out of the tab and come back after a few minutes. (I notice the same issue as well at the admin-pack example by checking the console.

Even if the video or audio doesn't upload which is another problem (see my other issue), this behavior makes the library buggy, even though it looks promising.

Is there a way to fix this?

Thanks.

[cubiclesoft]

I am completely unable to replicate this error message on my end. I've tried both Firefox (my primary browser) and Google Chrome. If I can't replicate it, I can't fix it. Line 623 adds the recorded media to the list. The only way it wouldn't work is if the widget is being destroyed and recreated during the recording. jQuery 3.5.0 was released two days ago. The jQuery devs have a tendency to drop major releases that break stuff and then roll out a bunch of fixes shortly after. I'm still using jQuery 3.1.1 in all my stuff. It's stable and I don't see any particular reason to update.

I've fixed the issue with hanging onto the stream tracks that kept the device "open". That issue bugged me too but it's rather difficult to find working code examples that use MediaRecorder so I gave up trying to figure it out the first time. Now it immediately releases at the end of the recording in all browsers.

[oliverbob]

I am very glad with your promptness in addressing the issue. May be this has to do with jQuery release also.

I will update my fork with the current commit.

Thank you,

Oliver

[oliverbob]

I have rebased my fork with your current commit. I am happy with the webcam now "turning off" when I exit the recorder media. However here are the screenshots of the working application from the example at: https://barebonescms.com/demos/admin_pack/admin.php?action=addeditexample&sec_t=7a110e04a283159db5a4e282c76e29b02e70e52c

I experience the same behavior even with the current commit. I'll try to explain the use case scenario here as clearly as much as possible. All scenarios are observed using the latest Chrome and Firefox browsers:

Case 1: When user activates or press the mic button and then do an upload of image and then stop the mic/recording by clicking the mic again:

Case 2: Clicking either recording media afterwards case 1:

Replicating the the scenario on Firefox:

Case 3: Turning on the mic before in preparation to upload an image and turning off the mic before uploading image to server:

Case 4: Pressing the camera button after case 3, before uploading the image.

Although the image is successfully uploaded after this, there is no way to activate the mic or the camera anymore. The weird thing is that they kept themselves open while the error causes you to get stuck on these bugs, so that the only way to turn the recording media off and to get rid of the bug is of course to reload the browser. Please note that the same bugs occur with an isolated setup with current commit. I even tried to copy what was in the source code of Admin Pack as follows:

$(function() {
    var options = {
        "params":
        {
            "id":"0",
            "action":"fileuploader",
            "sec_extra":"id",
            "sec_t":"7fc3a2890de33f5110a6afae7209aaf8723ee044",
            "fileuploader":"1"
        },
        "fileupload":{
            "__flexforms":false,
            "limitMultiFileUploadSize":7860224
        },
        "maxfilesize":7860224,
        "recordaudio":true,
        "recordvideo":true,
        edit:false
    };

    if (jQuery.fn.FancyFileUpload) {
        jQuery('#thefiles').FancyFileUpload(options);
    } else {
        alert('Warning:  Missing jQuery FancyFileUpload plugin for the file uploader widget.\n\nThis feature requires the FlexForms file-uploader module.');
    }
});

Using the default setup for the recording media from the plugin wiki as follows, doesn't change thing:

<script type="text/javascript">
$(function() {
    $('#thefiles').FancyFileUpload({
        params : {
            action : 'fileuploader'
        },
        recordaudio : true,
        recordvideo : true
    });
});
</script>

I believe that with the above scenarios, this plugin bugs makes it a candidate for a hot fix. Without any of these bugs mentioned, serious developers will consider adding some more improvements, to it as well as some more exciting features.

While the bugs are still around however, I am only 90% happy and not so much satisfied integrating it in my project (except of course by disabling the recording media as its default setup). Otherwise, its amazingly great! I hope you can replicate my issue with the system you are using and commit the necessary changes. The Admin pack example (displaying this among the last modules at the bottom), which I believe is a production presentation feature by cubiclesoft should also implement the hot fix whenever the updates are committed.

Thank you for keeping up the good work,

Oliver

[cubiclesoft]

The steps you show are similar to what I've run through many times (e.g. start recording, upload image, stop recording, start recording, stop recording, reload page, upload image, start recording, stop recording, start recording, stop recording, upload recording, alternate microphone/webcam, etc). Unfortunately, I'm unable to replicate on my end. I never doubted that the error exists for you as it's kind of difficult to fake a stack trace. I've tried from multiple computers with several different webcam/microphone setups and using both Firefox and Google Chrome and they all work fine. I'm thinking this is something very specific about your computer setup (e.g. browser plugins, external software) or its hardware or network configuration (e.g. a proxy) rather than the software found here. The Firefox screenshots show a bar at the top, "You must login to this network before you can access the Internet." The fact that you can see the audio/video recording buttons AND can upload other files just fine means the fileupload object is most definitely initialized even though jQuery says it is not. The error is real on your end but since I can't replicate it on my end, I can't even begin to surmise as to what is going on let alone track it down. I've seen anti-malware software do weird stuff to websites before and corporations love to install a bevy of weird software products onto computer systems that may similarly interfere with correct operation of the machine.

As to MediaRecorder hanging around after encountering an error in the callback on your computer, well that's just Javascript bailing out due to the error and, well, I'm not surprised to see other stuff breaking past that point.

Barebones CMS, Flex Forms, and Admin Pack are all active CubicleSoft software products. The Admin Pack w/ kitchen sink demo site let's me play around with most of the Flex Forms modules within an Admin Pack context. jQuery Fancy File Uploader has a Flex Forms module for seamless integration with Flex Forms enabled tools like Admin Pack. The Barebones CMS website is a historical location for Admin Pack and much of my other software that's since moved to GitHub.

[oliverbob]

Thank you for letting me know about this on your end.

I feel very sorry that my issue is not replicated in your situation. All the browsers are fresh installed from a fresh download after a fresh reset without any plugin. I have one more issue related to this:

$('.selector').FancyFileUpload('destroy');

also shows the same error message when you try reinitialize the plugin via a function call with:

$('.selector').FancyFileUpload({
        ....
});

Replacing line 111 with...

data.form.find('input[type=file]').remove(); //data.form.find('input[type=file]').fileupload('destroy');

seems to fix the issue.

If this is a browser issue, I suspect that this may be due to the recent releases of these browsers.

Also, the current "allow edit" is not designed to break word and therefore breaks the design on mobile view when uploaded/or uploadable files have longer text or file name strings.

My suggested improvement for this plugin are:

• Allow integration with summernote text editor.
• Allow editing captions for individual files or any text editor (or simple text-area).

The reason for that is, the uploader plugin just sit pretty and upload files. Actual usage demands these features and with the current setup, it demands "modification" of jquery.fancy-fileupload.js

Thank you,

[cubiclesoft]

I'm running the latest stable channel browsers (Chrome, Firefox, Edge). Please try on another computer on a different network because the original issue is clearly a problem with your existing combination of computer hardware/OS/network/browser.

I've fixed the problem with 'destroy' being called more than once. Your fix is actually incorrect and introduces a memory leak. I forgot to clear jQuery data and the problem would only show up if the same DOM element was used again. Very few people are going to do that. It's also unrelated to the original issue.

WYSIWYG editors for web browsers are largely broken-by-design software products that are filled with countless issues that integrators have to put up with and resolve for themselves.

Specific integrations between any two given software products are not actually anyone's concern. That's frustrating, I know, but that's the state of the world of software. Combining software from two different vendors requires skill with a measure of elegance and patience.

The text field for changing filenames is a standard input field type, not a textarea. If the styles of input fields are being monkeyed with, the input field might look like a textarea when it is not.

Actual usage demands these features and with the current setup, it demands "modification" of jquery.fancy-fileupload.js

I'm closing this issue. If you can figure out precise steps to replicate the original issue across multiple systems thus allowing me to replicate the problem on my end or you manage to figure out and fix the bug, we can revisit this issue. Each issue on an issue tracker is to track a single, replicatable bug. There's possibly a bug somewhere with in-browser audio/video recording and uploading but I can't replicate it. Making "demands" though of any software developer contributing to the world of open source is unacceptable.

[oliverbob]

I'm facing the same issue on Linux. Latest distro on Puppy Bionic 64.

[cubiclesoft]

I don't have any native Linux desktop machines configured. I mostly run Windows, Ubuntu Server LTS editions, and occasionally a Mac mini all on real hardware, and VMs for everything else. I tried replicating via a virtual machine and mapping in a USB webcam, but the VM guest OS (Puppy Bionic, 64-bit) didn't like it. The packaged Chrome saw a device but failed to connect to it.