Share - Firefox - File Upload Issue

[sthurrott]

We have installed Share on Linux, we have setup Apache Reverse Proxy with Self Signed Certificate and run into a couple of problems:

1.  We can't connect using Webdav, error says the folder is unavailable (my connection is as follows:  https://myserver/alfresco/)
2.  We can't upload files using Firefox 3 through the web client in Share.  I can upload files on the Alfresco side using Firefox as well as upload files using IE for both Share and Alfresco.

I suspect we have a configuration error but I'm not sure where to look as sys-admin is not my area of expertise.  Any insight into this would be helpful?

Thanks

[kevinr]

Is everyone else who sees this problem running opensuse or other Linux desktop env?

This might help us pin it down…

Kev

[lateral]

Kevin,
We're using 3.1E on Ubuntu 8.10 Server with Firefox 3 on Windows/Mac/Ubuntu clients and IE on the same clients and various flavours of Flash player from 9.0.45 up to latest 10.x release

No joy…and most annoying. Plus the javascript files changed between 3.0.1 and 3.1 so that the change we made to disable the flash uploaded and use only HTML as discussed on the forums were no longer viable…we're now concerned that the same will happen again between 3.1 and 3.2 making it even more annoying that we will keep having to re-add workarounds…

would love an idea of how Alfresco plans to address this issue…and also what is known about which environments/configurations seem to be most affected…and maybe some plans to externalise the control to switch off flash uploader would be nice? ie write it into a share global config somewhere rather than override it at the specific js level

thanks,
Alex

[kevinr]

Can anyone else seeing this issue please reply to the thread with their environment - is it only affecting opensuse 11.1 or other unix envs?

Thanks,

Kev

[jottley]

I am seeing this issue on Ubuntu Jaunty (9.04) with FF3

[mikeh]

Could the Ubuntu users please test with the Labs 3.2 version (or latest nightly build) - we've upgraded to YUI 2.7.0 which may have an effect on this issue.

Also: there are reports that resizing the browser slightly whilst the upload dialog is visible can make the button appear - please test that too.

Thanks,
Mike

[dc41]

Interesting, but better to use YUI's browser detection instead:

this.hasRequiredFlashPlayer = Alfresco.util.hasRequiredFlashPlayer(9, 0, 45) && (YAHOO.env.ua.gecko > 0);‍

Thanks,
Mike

Where do I put this code?

Thanks!

[ag4apple]

We're using 3.1E on Ubuntu 8.10 Server with Firefox 3 on Windows/Mac/Ubuntu clients and IE on the same clients and various flavours of Flash player from 9.0.45 up to latest 10.x release

Just to add my two cents, we are running Alfresco 3.2 Preview 2, and we are seeing this upload bug with Firefox 3 and Safari 4 as well. 

No joy…and most annoying. Plus the javascript files changed between 3.0.1 and 3.1 so that the change we made to disable the flash uploaded and use only HTML as discussed on the forums were no longer viable

You are right, just modifying the file-upload.js file does not by itself seem to force Alfresco to use the HTML uploader.  But, we found the solution.  You also need to modify the file-upload-min.js file, converting that value to false as mentioned previously.  So the value in both files will look like this:

this.hasRequiredFlashPlayer = false‍

Finally, one other modification you can make here to clean things up a bit is get rid of the message in the HTML uploader that tells the user that if they install Flash they can get access to the more functional Flash uploader.  Kind of confusing if you are forcing them to use the HTML uploader.  Just modify the  html-upload.js file and the html-upload-min.js file and look for this section:

// Show the help label for single uploads
Dom.removeClass(this.widgets.singleUploadTip, "hidden");
Dom.addClass(this.widgets.singleUpdateTip, "hidden");‍‍‍

Modify this like so:

// Show the help label for single uploads
Dom.addClass(this.widgets.singleUploadTip, "hidden");
Dom.addClass(this.widgets.singleUpdateTip, "hidden");‍‍‍

Hope this helps someone . . .

[mikeh]

Just to say we're seeing no problems at all with this on Safari 4 - in fact, I've been using it as my preferred test environment since it's release.

Mike

[jottley]

Also: there are reports that resizing the browser slightly whilst the upload dialog is visible can make the button appear - please test that too.

Yes.  Resizing the window makes the button appear.

[ag4apple]

Just to say we're seeing no problems at all with this on Safari 4 - in fact, I've been using it as my preferred test environment since it's release.

Mike, I probably needed to be more clear, as looking back at this thread it is not entirely obvious that we are all talking about the same thing.

The problem we are seeing happens when accessing Share with Firefox 3 or Safari 4 through HTTPS exclusively.  The problem does not occur with those browsers when we use the default HTTP access. 

Unfortunately, we need to force all our Share traffic over HTTPS for security reasons, so this is why the bug is affecting us.  We are running a self-signed certificate at this point, just as the OP is, so it could certainly be that once we move to a real certificate this problem will go away.

But for now, we are having to force our users into the arms of the HTML uploader.  Which is a shame, because the Flash uploader is pretty slick.