Fixed Upload button problems in FF

It's not intentionally fixed -- the fix is really a one line issue in the swf file.

I've never been able to reliably reproduce this issue so it's hard for me to say.
 
  • Update to 1.4.1, clear cache, the problem remains (clicking on the button doesn't trigger anything).
  • Two plugins (not extensions, tested them all disabled, no change) are enabled: shockwave flash 15.0.0.152 & shockwave flash 11.8.800.168. It seems the new update didn't uninstall the former one
    => Disable one of them, the upload can only start in single file upload (black overlay uploader)
    => Rename C:\Windows\System32\Macromed\Flash\NPSWF32_11_8_800_168.dll to disable it in FF, enable only version 15, the problem remains (clicking on the button doesn't trigger anything).
  • Adding SWFObject fixes the problem in every case
 
cclaerhout said:
  • Update to 1.4.1, clear cache, the problem remains (clicking on the button doesn't trigger anything).
  • Two plugins (not extensions, tested them all disabled, no change) are enabled: shockwave flash 15.0.0.152 & shockwave flash 11.8.800.168. It seems the new update didn't uninstall the former one
    => Disable one of them, the upload can only start in single file upload (black overlay uploader)
    => Rename C:\Windows\System32\Macromed\Flash\NPSWF32_11_8_800_168.dll to disable it in FF, enable only version 15, the problem remains (clicking on the button doesn't trigger anything).
  • Adding SWFObject fixes the problem in every case
Click to expand...
It does not work for me neither.
 
The problem is coming from the SWFUpload "WINDOW_MODE". Changing "transparent" to "opaque" or "window" will "fix" the issue... but will be super ugly.
 
Option 1:
Edit the file xenforo/js/swfupload/swfupload.min.js and add at the end this code.
Option 2:
Edit the file xenforo/js/swfupload/swfupload.min.js and replace its full content with this code (from SWFUpload 2.50 beta 3)
Option 3:
Install this addon. It will use a html5 library to upload files instead of a flash solution script. This is probably the best solution.
Option 4:
Set the window_mode on "opaque" and apply a css setting the opacity on zero only for FireFox
Code: 
SWFUpload.prototype.getFlashHTML = function () {
   // Flash Satay object syntax: http://www.alistapart.com/articles/flashsatay
   var extraStyle = [];
   if ($.browser.mozilla && this.settings.button_window_mode == SWFUpload.WINDOW_MODE.TRANSPARENT){
     this.settings.button_window_mode = SWFUpload.WINDOW_MODE.OPAQUE;
     extraStyle.push('opacity: 0');
   }
 
   extraStyle = extraStyle.join(';')

   if(extraStyle){
     extraStyle = ' style="'+extraStyle+'"';
   }
 
   return ['<object id="', this.movieName, '" type="application/x-shockwave-flash" data="', this.settings.flash_url, '" width="', this.settings.button_width, '" height="', this.settings.button_height, '" class="swfupload"', extraStyle,'>',
         '<param name="wmode" value="', this.settings.button_window_mode, '" />',
         '<param name="movie" value="', this.settings.flash_url, '" />',
         '<param name="quality" value="high" />',
         '<param name="menu" value="false" />',
         '<param name="allowScriptAccess" value="always" />',
         '<param name="flashvars" value="' + this.getFlashVars() + '" />',
         '</object>'].join("");
};

Content of updated swfupload.min.js
 
From tests with @Brogan, this is wmode related. Setting the wmode to opaque or transparent causes it; setting it to window immediately seems to fix it and potentially even keep it fixed in additional tests. (Setting the wmode to window is a non-starter in our usage.)

Still have some additional testing, but I do have a simplified test case now.
 
Mike said:
From tests with @Brogan, this is wmode related. Setting the wmode to opaque or transparent causes it; setting it to window immediately seems to fix it and potentially even keep it fixed in additional tests. (Setting the wmode to window is a non-starter in our usage.)

Still have some additional testing, but I do have a simplified test case now.
Click to expand...
You're very welcome.
 
Having rolled this out (to fix the window problem with FF) I'm now getting complaints from Chrome and Opera users that the editor is slow to respond and posting can be delayed up to a minute. Would this updated file impact on the editor in this way? And if so, is there an XF fix in the pipeline? (If so, I'll revert and use the official fix when it's out).

Thanks,
Shaun
 
There isn't a verified fix. It's likely to require a browser change. Also note that it doesn't happen to everyone; I have failed to reproduce it on 3 machines.

We have tested changes to the wmode unsuccessfully (opaque made no difference; only window works which breaks many other things). We've also seen that changing this can temporarily make it work in some situations where it breaks again after restarting FF (thus masking the true cause).

We've reproduced the issue without any JS involved, so simply adding JS to the end of a file shouldn't change anything, though it's theoretically possible that changing the initialization process could change something.
 
Mike said:
There isn't a verified fix. It's likely to require a browser change. Also note that it doesn't happen to everyone; I have failed to reproduce it on 3 machines.
Click to expand...

We have two computers, though I haven't tested it on my mom's, but it's pretty much the same for me. It works most of the time, and I only run into the issue on occasion.
 
Clickfinity said:
Having rolled this out (to fix the window problem with FF) I'm now getting complaints from Chrome and Opera users that the editor is slow to respond and posting can be delayed up to a minute. Would this updated file impact on the editor in this way? And if so, is there an XF fix in the pipeline? (If so, I'll revert and use the official fix when it's out).

Thanks,
Shaun
Click to expand...
I don't use Redactor, but yes it's possible since the SWFObject certainly has some event listeners which might cause conflicts. SWFObject has been added in the last version of swfupload and documented like this:
SWFObject
The SWFObject plugin uses the SWFObject library to handle the embedding of the SWFUpload Flash Component into the page.

This plugin also provides support for Document Ready loading and Flash Version Detection. Usage details are documented in the plugin file itself. You should not use the SWFObject's Document Ready loading mixed with another libraries DOMReady. Use one or the other but not both.

Flash Player 10: Because Flash Player 10 requires the SWFUpload swf to act is a button the movie must be visible in order for it to load. If the button_placeholder_id is set to an element that is hidden (visibility set to hidden or display set to none) SWFUpload will fail to load.
Click to expand...

The problem with the wmode & swfupload is not new as the documention shows it:
WMODE / BUTTON_WINDOW_MODE
In some browsers the selected WMODE (which is set using the BUTTON_WINDOW_MODE) can prevent the Flash Control from loading if the control is not on screen. The control will finally load once the user scrolls the page so the control becomes visible.

This behavior can adversely affect the SWFObject plugin. No SWFUpload events will be fire and the button image will not be loaded until the control becomes visible.

On some systems (Linux is affected) when the WMODE is transparent Flash opens the File Dialog window behind the browser window.
Click to expand...

On my browser all solutions given above are working. For the SWFObject solution, it should mean the FF & Flash problem comes from when or how is loaded the swf element in the dom.

If you only want to target FF, try the solution 4. It will set the wmode to opaque without any opacity, so it's only html and css manipulation through JS. It works on my system, but this solution has not been tested on a Firefox version that works normally.
 

Similar threads

Joeychgo
Fixed Upload button problems in FF
2
Replies
23
Views
5K
Wdes
Wdes
Top Bottom