TYPO3 Core

Can you confirm, that it works correctly in Internet Explorer? For me it does.

But I can reproduce the issue with Firefox 3.6: Clicking on "Choose file" does nothing. Closing the box again works for me. There is no error in the console.

Now upgrading to 4.5beta1 - it still does not work in FF .-(

It works on IE - although I find it rather strange that the uploader starts without any mouseclick???

Do you have a Firefox extension, which blocks Flash installed?

No I do not - the fileuploader works fine in TYPO3 v. 4.4.4 in my FF 3.6.12

Have tested with a clean install of FF 3.6.12 and FF 4.0 beta 7. Only installed Flash-plugin. Fileuploader don't work in either of them.

The test is done in Windows XP mode to have a clean test instance.

Still does not in TYPO3 4.5 beta2.

Claus, it would be perfect, if you could use the subversion checkout from https://svn.typo3.org/TYPO3v4/Core/trunk/ and step back to revions ~8000 and try, if it still breaks.

Works in alpha1 and alpha2, not in alpha3, beta1 and beta2

It works in alpha2. That is Rev. 8856. I just tested Rev. 9085 and it still works there.
It is broken in Rev. 9090.
(Alpha3 is Rev. 9185.)

I just went through these revisions and found the following, which are somehow JS and/or filelist related and so might have to do with the problem.

Still does not work in TYPO3 4.5 beta4.

The fileuploader works when choosing: Plupload (HTML5, Flash, Silverlight, Form)

It does not work when choosing: Flash Uploader (requires Flash 9+)

I use Firefox 3.6.13 and have Flash 10 installed

It works, because you use HTML5 ;-)

Yes but why is Flash Uploader (requires Flash 9+) available when it does not work? :-|

It only doesn't work for you.

.. and for plenty of other users, which hit flash limitations (HTTP Auth, self-signed SSL,..).
plupload also far from perfect (and their flash implementation also can't circumvent these problems).

Right, it works with plupload.

But @ Steffen: I can reproduce Claus' problem with Firefox. For me it worked before and I did not add HTTP authentification, a self-signed certificate or something in between...

I now put one installation back to TYPO3 4.4.6: Flash Upload is working. With 4.5.0alpha3 in the same installation it is broken as described here. So it does not have to do with the installation or the server, but with the TYPO3 source.

dunno

How can you prevent the HTML5 upload to work?

It would be interesting to know, if the Flash implementation in plupload, which is used then, works correctly. If it does, we could just remove the Flash 9+ option I think...

plupload.js
change order html5,flash,... to flash

I changed that in typo3/js/extjs/PluploadWindow.js
Uploading via Flash also does not work there - but there is an error message:

IO error. (-300: Error #15279)

Note that this only is a problem in Plupload. This error is not present when using the mass uploader.

Yes.. so Flash also doesn't work.

Sorry.. typo3/js/extjs/PluploadWindow.js

Do you have cookiesHttpOnly option set?

I'm suffering the same problem with 4.4.6 tested with chrome, IE and FF in Linux OS

@ Steffen: I use the default value for cookiesHttpOnly.

Can I have a login?

Iam on OSX and Firefox 3.6.x, and i have this only on first click. Then nothing happens. Second click works for me. Someone else posted on german mailing list that he has problems too. He's also on FF.

Here is the thread, maybe it helps us:
http://lists.typo3.org/pipermail/typo3-german/2011-January/074877.html

===

Steffen Gebert had a look at this problem.

Intermediary results:
- It seems like the target URL gets lost.
- After successless(!) upload, you have a message in the BELog stating that there was an upload. Nothing about an error there.

- Might be an idea to check that through a proxy so that you see, what Flash is sending.

It got broken in Rev. 9090 by changes for #23595.

Hey Christopher,

i don't get why, but to remove the position works for me. Its just a test to get the reason for that behavior. I think to delete the position in that file has some side effects.

I found one different behavior with safari and firefox under osx. When clicking on "select files" the "class" within the parent dom element get different class attributes.

Parent element: <table cellspacing="0" class="x-btn x-btn-text-icon".....

Within firefox it adds "x-btn-click" to the class. Within safari it doesn't. Its just an idea. I hope that helps.

Anyone could help to test this? Without position it works for me (osx & ff).

A problem with the "Select files" button is that you don't click the real button, but an invisible Flash object, which is positioned over the button and gets opacity: 0.
(see screenshot button-markup.png). That's the cause, why sometimes nothing happens, when you click the button.

Could you check the dimensions of the flash object, please? Or if anything changes after the first click?

I think this bug report mixes up several issues with the Uploader. No we're at "Nothing happens when the Select Files button is clicked" and "Upload fails with Error 2038", which is a stupid "I could not do that" error from flash without any information.

Hey Steffen,
I think this happens:
The js event listener catches the event and adds the x-button-click param. This calls the CSS config with position relative. Thats why at the same moment the button overlays the swf. Result: The click can't reach the swf. In a nutshell, firefox re-orders z-index witin the same time. (i think)

I think that other browsers doesn't catch this js event. Result: No new new CSS param. The click reaches the swf.

@ Steffen: Sorry for the confusion. Let us fix the "Button not clickable" error here. The "2038" error also prevented uploads and so I thought both were related. But that one was only reproducable with Plupload for me. It is no longer in current trunk.

To your questions:
The dimensions of the Flash object are the following (tested in Firefox):
<object width="111" height="22" class="swfupload" data="/typo3/contrib/swfupload/swfupload.swf?preventswfcaching=1295905286065" type="application/x-shockwave-flash" id="SWFUpload_0">
...
<param value="(....much text...)&
buttonWidth=111&
buttonHeight=22&
buttonText=&
buttonTextTopPadding=0&
buttonTextLeftPadding=0&
buttonTextStyle=(...some declarations...)&
buttonAction=-110&
buttonDisabled=false;"
name="flashvars">
</object>

The dimensions do not change after the first click. (Note: I never had the problem, that it did not work with the first click, but worked with later clicks.)

Now the patch:
I tested it and it solves the problem for me.

Are there sideeffects?
The button did not have any position explicitly set before the patch of #23595.
So it should behave the same as if "relative" would have been set. The only difference is that when "relative" is set, you can move the button with "top", "left"... But that is not done. In a perfect world it would be logically, that this change should not break anything.

No, Christopher.. this issue was opened b/c of Error 2038 ;)

I'm currently investigating the JS problems.. this one - for which I ask you to create a new report - will hopefully follow soon.

Okay, editing the OP's report is a solution ;)

Exceptionally yes, because it was me who added the part on the 2038 error there, after I thought that this was the reason behind it all. What a mess...

Ah, fine..!

One note before: The line "position: relative;" has been committed with #23595, but does not belong to that patch. Seems like it should fix issues with the icon inside some ExtJS buttons.

I have just tested Sascha's patch in different browsers with the buttons in workspaces, recycler and EM. I could not find problems, which it might introduce.

<b>Please test RC2</b>

We fixed two issues last night: One JS error, caused by the click menu (#24773) and the problem that hitting "Select Files" does not work in Firefox for the first time (#24773).

I'm closing this issue now. For sure, problems will remain, coming from Flash limitations.

If you have issues with the FlashUploader, please create a new bug report including detailed system information - and, please, don't mix up all different problems of the uploader in one thread, again.