The "Insert WebGUI Image" method in 7.5.16-beta fails to show the content of the Collateral Image Manager, thus making it impossible to choose an image or upload a new one. I attach a sreenshot from the beta demo site as well as the correct one from the stable demo site, which runs 7.4.40-stable.
I meant to say of course that this is a problem in the tinymce editor of 7.5.16-beta. In 7.5.14-beta, the last version I tested before this one, this was still working fine.
Oops, I should have tested some more. It does work in IE (see screenshot), so this seems to be an issue with Firefox 3. I probably tested the earlier version with Firefox 2.
I just tested in FF3 and it works?
It's totally weird. I started FF3 in safe mode, didn't help. I tested with a simple html file, like thus:
<html> <head> </head> <body> <fieldset> <legend>This is a fieldset</legend> <iframe src="http://beta.webgui.org/demo1216234361_895/home/welcome?op=formHelper;class=HTMLArea;sub=imageTree"></iframe> </body></html>
and the result was fine.
But when I go to the same beta demo site and use the editor there the iframe remains empty. But then comes the weirdest part: in firebug the result is as in the first screenshot. Note the empty html body in the iframe. When I edit the src tag, however, and then restore it to what it was, the content of the iframe suddenly shows up, see the second screenshot. Note that the first empty html body is still there, but is now followed by what should have been there in the first place.
I only have access to this one Windows XP laptop here, but will test tomorrow on some other machines to see if I can reproduce the behaviour there.
OK, finally some light at the end of this tunnel. I believe I have a reproducible bug (not in WebGUI, but in FF3):
Tested with 7.5.16-beta and Firefox 3.0 and 3.0.1 on several different machines (Windows XP, Vista, MacOS 10.4.9, unfortunately no Linux):
1. Clear the browser cache;
2. Edit an article and open the WebGUI Collateral Image Manager
3. Be pleased that it works properly
4. Cancel the Image Manager
5. Open it again
6. Be upset that it doesn't work on that page no matter how hard you try
7. Cancel the Image Manager
8. Clear the browser cache
9. Open the WebGUI Image manager again and rejoice that it works again
10. (Optional) try to find the bug in FF3's cache management
11. Uninstall FF3 and install the latest and greatest FF2 update
I'd appreciate it if someone else could confirm the above, because for a moment I thought I was going mad trying to figure this out.
Rob Schipper
Interestingly enough, I was not able to reproduce the bug in FF3, but my build is for Fedora 9. I was able to reproduce it in Epiphany on Fedora 9 and FF3 for Cent5.1. But the bug showed up for me every time I tried to open the tinymce editor. Clearing the cache did no good.
Using Firebug I was able to determine the most likely candidate for the bug's source. The YUI resize-beta.js line 1386 is thrown as an error from Firebug.
The current WG version of the resize-beta.js is 2.5.1. So I updated to 2.5.2 with the same error in place. I'll keep digging into what's going on, but the short term fix is use Fedora :P
Line 1386: easing = YAHOO.util.Easing.easeOut;
Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.sessionHistory]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/browser.xml :: :: line 644" data: no]http://localhost/extras/yui/build/resize/resize-beta.jsLine 1386
Upon further investigation, it looks like file:///usr/lib64/firefox-3.0/components/nsSafebrowsingApplication.js line 665 is actually causing the problem and triggering the previous error I posted.
I couldn't replicate it on Vista IE7, so perhaps someone could test it on Opera or Safari and see if this is just a FF3 bug, which is fixed in at least the Fedora 9 build, so probably the rest soon.
Confirmation that it does not appear in Safari.
This comes down to a timing problem. If it tries to load the iframe too soon, it can cause problems. The timing is sensitive to different builds or caching.
Adding a small delay before loading the iframe contents fixes the issue for me.
Fixed for 7.5.18.
