Note: this bug manifests itself on Firefox but not IE (go figure).

1. Fresh Drupal 5.7 install
2. Fresh 5.x-2.1 FCKeditor install -- it's the only contrib module
3. Enable clean urls
4. Enable the core Upload module -- it's the only enabled non-default core module
5. Enable FCKeditor and do the minimal configuration so that you can see it on node/add/page
6. At node/add/page, open up the File attachments fieldset, browse to select a file, and hit "Attach"
7. If you're on Firefox, you'll get a dialog box with "An error occurred: Unspecified error" in it (if you're on IE, the upload works fine, believe it or not)
8. Dismiss the dialog box, and everything is pretty much fine

Also note that this is the minimal configuration to reproduce the bug. We first noticed it on an imagefield in a CCK node on a crazy site with a bazillion modules.

CommentFileSizeAuthor
#26 fckeditor_fix_uploads.patch1.01 KBquicksketch
#24 jquery.form_.js_.txt22.56 KBartur.ejsmont
#9 sample.zip435 bytesWolfmark
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dvessel’s picture

dvessel CreditAttribution: dvessel commented

Some further info. This only happens on FireFox 2.x and it was tested with v.2.6 of the FCKeditor library. FF3 is fine as is all other browsers - IE6/7 Safari 3, etc.

Version 2.5.1 of the library doesn't cause problems though.

wwalc’s picture

wwalc CreditAttribution: wwalc commented

This error occurs only if FCKeditor is enabled and visible. After clicking on "Switch to plain text editor", everything works fine.
Something funny: adding 

alert(1);

to misc/upload.js file, at the end of function "Drupal.jsUpload.prototype.onsubmit" solves this issue (?!).

Quick workaround for this bug is to add this to modules/fckeditor.utils.js:

if (Drupal.jsUpload) {
/**
 * Overwrite Handler for the form redirection error in the Upload module
 */
Drupal.jsUpload.prototype.onerror = function (error) {
  if (error != 'Unspecified error') {
  	alert('An error occurred:\n\n'+ error);
  }
  // Remove progressbar
  $(this.progress.element).remove();
  this.progress = null;
  // Undo hide
  $(this.hide).css({
    position: 'static',
    left: '0px'
  });
}
}

This should work until the real problem can be found and fixed.

wwalc’s picture

wwalc CreditAttribution: wwalc commented
Status: Active » Fixed

Let's mark it as fixed with the workaround from previous comment. If anyone has a better solution, please attach it.

marcp’s picture

marcp CreditAttribution: marcp commented
Status: Fixed » Active

We went back and installed 2.5.1 instead of 2.6. Neither one of these solutions is acceptable, really, given the laundry list of bug fixes in 2.6.

I'd like to keep this one open. It shouldn't be too hard to get the FCKEditor folks a bug report containing a small modification to one of the sample programs (ie. _samples/php/sample01.php) that demonstrates the problem, but I have since shifted gears and may not get to this for a while.

Feel free to set this back to fixed if you think this isn't worth keeping open, but I wouldn't recommend using 2.6 on a production site along with the upload module.

Anyone else experiencing this?

stashlbai’s picture

stashlbai CreditAttribution: stashlbai commented

We're seeing this problem as well. Same manifestations. I'll see if we have some bandwidth to track this down over the next few days.

Medya-1’s picture

Medya-1 CreditAttribution: Medya-1 commented

same here any update yet?

Wolfmark’s picture

Wolfmark CreditAttribution: Wolfmark commented

I think that the problem is in Drupal and how uploads are handled and has nothing to do with FCKeditor.

See how files are uploaded. When the user clicks the submit/attach/upload button, an iframe is created dynamically and added to current document, then form's target is changed to iframe. Server's response is retrieved when iframe's onload handler is called.

The problem is that sometimes, on Firefox 2 and with FCKeditor enabled, iframe's onload handler is called twice. And I think I know why.

When an iframe is added to current page, the onload handler (if any) is called immediately. For example:

<html>

<body id="bodyElm">
    <script type="text/javascript">
        <!-- this is called right after the iframe is added to current document -->
        function frameLoaded() {
            alert('loaded');
        }

        var container = document.createElement("DIV");
        container.innerHTML = "<iframe id='testFrame' name='testFrame' onload='frameLoaded()'></iframe>";
        document.getElementById("bodyElm").appendChild(container);
    </script>
</body>

</html>

When Drupal adds the iframe to page, the onload handler should be called right away. This is what Firefox does and, because the iframe has an empty content, an error occurs. Probably, because everything is happening during form's submit, the handler is not called most of the time (server's response is received fast enough). Maybe when FCKeditor is enabled Firefox is slowly and has time to call the onload handler before it starts receiving the response from server. Crazy, huh?

Anyway, a solution which works for Firefox 2 and IE 6 is to modify the drupal.js file:

--- drupal.js   (revision 18)
+++ drupal.js   (working copy)
@@ -143,7 +143,7 @@
   window.iframeHandler = function () {};
   var div = document.createElement('div');
   div.id = 'redirect-holder';
-  $(div).html('<iframe name="redirect-target" id="redirect-target" class="redirect" onload="window.iframeHandler();"></iframe>');
+  $(div).html('<iframe name="redirect-target" id="redirect-target" src="javascript:void(0)" class="redirect" onload="window.iframeHandler();"></iframe>');
   var iframe = div.firstChild;
   $(iframe)
     .attr({
@@ -157,6 +157,7 @@
       visibility: 'hidden'
     });
   $('body').append(div);
+  iframe.src = "javascript:void(0)";
 };

which means:

a) open misc/drupal.js file
b) search for Drupal.createIframe function
c) add src="javascript:void(0)" to iframe's declaration (works for Firefox)
d) add iframe.src = "javascript:void(0)"; as function's last line (works for IE 6).

Simply set iframe's source to "javascript:void(0)" and the onload handler is not called anymore when the iframe is added to page and will be called only when server's response is received.

SamRose’s picture

SamRose CreditAttribution: SamRose commented

above fix from Wolfmark does not work for me. From #2 above...there is no "modules/fckeditor.utils.js" that I can find. Where would I find this file?

Thanks!

Wolfmark’s picture

Wolfmark CreditAttribution: Wolfmark commented
FileSize
sample.zip435 bytes

It should work. Try to clear browser's cache to make sure you're using the modified drupal.js file. If still doesn't work, post here your modified drupal.js file, so I can take a look.

Also please do a test. Open the attached file with Firefox v2 and with IE and tell me if you see only the message Frame <#2> was loaded!, or you see for #1 too.

SamRose’s picture

SamRose CreditAttribution: SamRose commented

Wolf, it worked!

What I did:

  1. Switched to DRUPAL-5--2-1-BETA2 fckeditor module just for the hell of it
  2. Downloaded 2.6 of fck script
  3. applied your changes to drupal.js exactly as you describe above
  4. set $base_url (an option to $cookie_domain described at #235032: File browser "disabled" ? in settings.php
  5. Did everything else required in README.txt

...and it works great (newer fckeditor is way faster, too)

marcp’s picture

marcp CreditAttribution: marcp commented

@Wolfmark - I haven't tried your fix yet, but it sure sounds like you know what you're talking about! Any chance you would be interested in filing an issue against Drupal core for this? Thanks for your work on this issue.

crazydaddy’s picture

crazydaddy CreditAttribution: crazydaddy commented

Hi Wolfmark

Got the same problem. Followed your excellent instructions, modified drupal.js and its working fine now.

Many thanks

crazydaddy’s picture

crazydaddy CreditAttribution: crazydaddy commented
ChristieLuv’s picture

ChristieLuv CreditAttribution: ChristieLuv commented

Wolfmark, your fix looks great, can you help me out. I don't know where the iframe's declaration is or the function's last line or did you mean put both of them right under Drupal.createIframe. Can you give me instructions that are like "place this code directly below where it says this" Thank you so much!

ChristieLuv’s picture

ChristieLuv CreditAttribution: ChristieLuv commented

Ah, silly me I figured out your patch instructions and I needed to clear my cache also to see the new drupal.js file. Then it worked! ^______^ Thank you!

Also if anyone is getting this in Opera the patch on this thread worked for me:

http://drupal.org/node/253258

ajg112’s picture

ajg112 CreditAttribution: ajg112 commented
Title: File upload throws error on attach only when FCKeditor is on page » Almost, but not quite

I've tried Wolfmark's fix and it does seem to work with Firefox, however. It seems to break Imagefield with IE6. With the fix in place, if you upload an image with IE6, you get a 'image not found' red-cross.

I tried making the fix conditional for firefox and that seemed to sort it out.

I then went on to try it out with IE7. Again the red-cross. Am I missing some IE7 ImageField compatibility issues?

Any ideas?
Andy

Drupal 5.7
FCKEditor 5.x-2.1
ImageField 5.x-2.1

SamRose’s picture

SamRose CreditAttribution: SamRose commented

ajg112, what happens if you disable fckeditor totally on the same site, does imagefield now work for you?

ajg112’s picture

ajg112 CreditAttribution: ajg112 commented

I'm at home now and can't try that out until tomorrow.

However, I've tried to replicate the same error on my own machines. IE6 IE7 FF1.5 FF2 & Opera 7.x
Of course everything works this time (including with the fix)!

I'm wondering if the problem is in fact with the accessing and displaying of the image from its temporary location. I notice that after an upload (but before a page submit) the image src is listed as the final destination, however, the file doesn't actually exist there yet (As it says on the form, 'Images are not saved until the form is submitted').

I now think the problem may be related to the secure pages module. Hopefully I'll have more info soon....

ajg112’s picture

ajg112 CreditAttribution: ajg112 commented

Just a note in case someone was having the same issue. If you are using the securepages module with imagefield, IE6 seems to have some problems accessing the temporary image files. Adding files/* to the Ignore pages section in the secure pages configuration seems to fix this.
Andy

wwalc’s picture

wwalc CreditAttribution: wwalc commented
Title: Almost, but not quite » File upload throws error on attach only when FCKeditor is on page
mediamash’s picture

mediamash CreditAttribution: mediamash commented

when i apply the patch all JS seems to be disabled, how can i avoid that?

internal’s picture

internal CreditAttribution: internal commented

Do you have a final solution? I trace to editorInstance.LinkedField.form.onsubmit call, it seems upload click shouldn't trigger fck's onsubmit call, fck cause the mistake of submitting whole form to server!

Jorrit’s picture

Jorrit CreditAttribution: Jorrit commented
Status: Active » Postponed (maintainer needs more info)

It looks like something that was encountered in a different way in the 6.x branch. Could you try changing

editorInstance.LinkedField.form.onsubmit = function() {

into

$(editorInstance.LinkedField.form).submit(function() {

in fckeditor.utils.js

artur.ejsmont’s picture

artur.ejsmont CreditAttribution: artur.ejsmont commented
FileSize
jquery.form_.js_.txt22.56 KB

I think i also made it usable in drupal 6.6 and 6.8 with current fck editor by replacing the jquery form lib with one line patch

Index: jquery.form.js
===================================================================
--- jquery.form.js	(revision 41144)
+++ jquery.form.js	(working copy)
@@ -166,7 +166,7 @@
 		var s = jQuery.extend(true, {}, $.extend(true, {}, $.ajaxSettings), opts);
 
         var id = 'jqFormIO' + (new Date().getTime());
-        var $io = $('<iframe id="' + id + '" name="' + id + '" />');
+        var $io = $('<iframe id="' + id + '" name="' + id + '" src="javascript:void(0)" />');
         var io = $io[0];
 
         if ($.browser.msie || $.browser.opera)

Also please take a look at the issue in case they resolve or change stuff here:
http://drupal.org/node/356573

Good luck!

martysteer’s picture

martysteer CreditAttribution: martysteer commented

This has worked for me too.
Note tho: I am using 5.x, TinyMCE and Wysiwig API. Disabling the editor stops the error, but with the patch the error is always resolved.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Version: 5.x-2.1 » 6.x-1.3
Status: Postponed (maintainer needs more info) » Needs review
FileSize
fckeditor_fix_uploads.patch1.01 KB

This problem still exists in the latest DRUPAL-6--1 branch, and it affects not just upload.module but also FileField, ImageField, or any module that uploads files using AHAH. See #432038: FCKEditor Causes "HTTP error 0" Preventing Upload for the FileField issue.

It looks like this problem is twofold. First, the loop in the TeaserStuff function is incorrect, it's currently doing for( var i = 0 ; i < fckLaunchedJsId.length ; i++ ), but fckLaunchedJsId, is an object, not an array. When trying to reference fckLaunchedJsId[i], it will be undefined since fckLaunchedJsId does not have numeric keys. It needs to be switched to for ( var i in fckLaunchedJsId ) {.

The second problem is that sometimes the instance isn't yet activated by FCKeditor, so when you call FCKeditorAPI.GetInstance( fckLaunchedJsId[i] );, sometimes that returns undefined. We should either find what's causing our fckLaunchedJsId array to be inaccurate, or just do what this patch does and check that the ID is valid before trying to call GetXHTML().

nonsie’s picture

nonsie
she/her
Primary language Estonian
CreditAttribution: nonsie commented

Patch in #26 solves the problem for me

glass.dimly’s picture

glass.dimly CreditAttribution: glass.dimly commented

I'd really like to see this issue get fixed. It's a pretty serious error.

Jorrit’s picture

Jorrit CreditAttribution: Jorrit commented
Status: Needs review » Postponed (maintainer needs more info)

As far as I can see, fckLaunchedJsId is an array. What makes you think it's an object? Does someone have a guide to reproduce this on version 6.x-1.3 or 6.x-2.x ?

Jorrit’s picture

Jorrit CreditAttribution: Jorrit commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

Closed because of inactivity.