htmlarea doesn't load with new Firefox 18.104.22.168
|Priority:||Must have||Due date:|
|Assigned To:||Patrick Broens||% Done:||
|PHP Version:||Is Regression:|
with v1.5dev (shipped with typo3 4.1)
going back to FF 22.214.171.124 works well
(issue imported from #M5266)
#2 Updated by Michael Stucki over 9 years ago
Well, obviously it's not a TYPO3 issue since it worked with older versions of Firefox.
You can help us by reporting the problem to the Mozilla Devs.
#3 Updated by Jonas Felix over 9 years ago
We'll have to find a workaround because all users working with firefox 2 will be updated automatically.
#4 Updated by Christian Hernmarck over 9 years ago
It appeared with FF 126.96.36.199 - but it still may be a bug in HTMLArea...
#5 Updated by Alexander Grein over 9 years ago
I have the same Problem on MAC and PC.
After updating from 188.8.131.52 to 184.108.40.206 the HTMLArea do not work anymore.
"editor has no properties"
In the generated rtehtmlarea_.....js file i found this definition:
Maybe this help's someone.
#6 Updated by Stefano Cecere over 9 years ago
how i'd like to switch to TinyMCE as default RTE.... i made some experiments.. anybody using it in production?
#7 Updated by Axel Klarmann over 9 years ago
Found a workaround with the add-on User-agent switching:
The only change one need is to replace the 1.3 in the version string, with e.g. 1.2
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:220.127.116.11) Gecko/20070309 Firefox/18.104.22.168
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:22.214.171.124) Gecko/20070309 Firefox/126.96.36.199
That goes in conjuntion with an line:
HTMLArea.is_wamcom = (HTMLArea.agt.indexOf("wamcom") != -1) || (HTMLArea.is_gecko && (HTMLArea.agt.indexOf("1.3") != -1));
in htmlarea.js on line 85
maybe that is the point where one has to start to change things
#8 Updated by Stefan Precht over 9 years ago
I'm working on a TYPO3 4.0.4 installation with an htmlarea V1.4.3 using FireFox 188.8.131.52 and of course i have the same problem. Reported below. Maybe this is helpfull for somebody to find an solution to fix it!?
enableCompressedScripts is set to 0
If I load the editor a second time it hang up while loading.
Due to this there occured an other JS error.
"editor has no properties"
Function: HTMLArea.generatePlugins = function(editorNumber)
Line 1066: var editor = RTEarea[editorNumber]["editor"];
#9 Updated by Patrick Broens over 9 years ago
RTEhtmlarea was checking if MacOS Wamcom version 1.3 was the user agent with a indexOf("1.3"). The revision number of Firefox also has 1.3 in it, because of revision number 184.108.40.206. This is now checked if version number has not indexOf(".1.3").
See the patch
Thanks to Axel Klarmann for pointing in the right direction.
When testing delete all rtehtmlarea related files in typo3temp directory.
#11 Updated by Michael Stucki over 9 years ago
Reopening this bug, see user comment in bug 0005279.
@Patrick: Next time please do not close bugs unless they have been successfully committed to SVN. Otherwise it's not possible for users to give feedback...
#12 Updated by Axel Jindra over 9 years ago
I have patched both js files without an error and the editor still won't load in FF 220.127.116.11 on Mac OS X
edit: I just tested the patch with FF 18.104.22.168 on Windows Vista and it doesn't work there either.
edit2: OK, blame on me, I did not delete the rtehtmlarea_* files in typo3temp, but due to the fact it said "When testing..." and I wasn't testing, I was serious ;-)
Now RTE works again.
#13 Updated by Staffan Ericsson over 9 years ago
When is the ter version updated? So all without shell access can update there rtehtmlarea?
#14 Updated by Patrick Broens over 9 years ago
For the people where the patch didn't work: Did you delete all rtehtmlarea related files in the typo3temp/ folder and clear the browser cache?
#15 Updated by Patrick Broens over 9 years ago
In addition to bugreport 5279:
the patch for issue 5266 is incomplete.
the patch tries to exclude following browser identifier
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:22.214.171.124) Gecko/20070309 Firefox/126.96.36.199
with this line
HTMLArea.is_wamcom = (HTMLArea.agt.indexOf("wamcom") != -1) || (HTMLArea.is_gecko && HTMLArea.agt.indexOf("1.3") != -1 && HTMLArea.agt.indexOf(".1.3") == -1);
this condition will still won't exclude future firefox versions, example:
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:188.8.131.52) Gecko/20070309 Firefox/184.108.40.206
so the same bug will reappear in about half a year.
This is not the case. This line is excluding FF to be HTMLArea.is_wamcom. The old line made FF seen as wamcom browser version 1.3 because it was looking for the string part "1.3", but it is excluding FF now with the ".1.3" (look at the dot).
This patch keeps working when FF version is 220.127.116.11
#16 Updated by Oliver Hader over 9 years ago
Concerning the "HTMLArea.prototype.accessParentElements" note (#0013254):
In fact this is a bug that should be solved by another patch (mostly conerning IRRE), see bug-id #5177. The RFC has been sent to the Core-List one week ago - currently waiting for approval.
#17 Updated by alexander onea over 9 years ago
in reply to note 13195:
you're right that your patch will work with my counter-example on bug #5279, but you're wrong assuming that your patch is correct.
check this out:
var str = "Mozilla/5.0 [...]; rv:1.3.0) Gecko[...]Firefox/18.104.22.168".toLowerCase();
var condition = str.indexOf("1.3") != -1 && str.indexOf(".1.3") -1;
... and no, adding another condition like "str.indexOf("1.3.") -1" to the list of identifiers would still not be the proper solution since it only solves the symptom and not the problem itself - that you shouldn't determine "is_wamcom" by checking for parts of version numbers.
#18 Updated by Patrick Broens over 9 years ago
in reply to note 13266:
The string "Mozilla/5.0 [...]; rv:1.3.0) Gecko[...]Firefox/22.214.171.124" is a browser based on the WamCom release of mozilla. We are not checking the version number, but the revision number. Mozilla never released revision number 1.3.0 and 1.3.1. These numbers were for the WamCom project which ended somewhere in 2004. Revision number 1.3.0 is a release from the beginning of 2003, 1.3.1 of september the same year. This project came to an end in 2004.
I don't expect Mozilla ever to release revision 1.3, 1.3.0 or 1.3.1 or whatever in this range, when they are already on revision 126.96.36.199. It's the same as M&^%* releasing a new operating system in 2008 and call it Windows 94.
I hope this clears things regarding the WamCom releases and the check on it.
#19 Updated by Christian Hernmarck over 9 years ago
Wouldn't it be easier to check
indexOf("1.3") AND indexOf(".1.3")
#20 Updated by Patrick Broens over 9 years ago
in reply to note 13275:
No, sometimes a space is used between rv: and the number, sometimes it's not. And putting a dot at the end will still not see revision 1.3 as WamCom, which is.
#21 Updated by Jason Lefkowitz over 9 years ago
Re: 0013255 --
I patched the file, deleted all the contents of the typo3temp/ directory, cleared my browser cache, restarted the browser & logged in again. HTMLArea still does not load. Firefox 188.8.131.52 on Windows XP Pro.
#22 Updated by Jason Lefkowitz over 9 years ago
Wait - I take it back. It now appears to work. Sorry about that!
#25 Updated by Jason Lefkowitz over 9 years ago
I did. Based on those I think I've figured out the issue. It looks like the patch successfully updated the standard htmlarea.js, but it failed to patch the compressed version. When I was getting the regular one it worked fine; when I was getting the compressed one it wasn't. I disabled the compressed version in the config file and now it seems to be stable -- at least on the site whose localconf.php I updated.
Of course I now have a bunch of other sites to fix, but that appears to be a different error -- it's throwing an "editor has no properties" error when it tries to load the RTE, for some reason...
UPDATE: clearing out all the rtehtmlarea* files in the typo3temp/ directory of the affected sites appears to resolve that latter problem.
#26 Updated by Marc Véron over 9 years ago
I used patch.exe from GNU utilities for Win32 (http://unxutils.sourceforge.net/) to apply the diff file. It has patched htmlarea.js, but htmlarea-compressed.js has been rejected.
As Jason, I disabled the compressed version (using the Extension Manager ). After deleting the rtehtmlarea* files in typo3temp/ the editor now works fine.
#27 Updated by Christian Hernmarck over 9 years ago
I also noticed that the patch has a problem with the compressed version - i patched the compressed js file manually and this worked.
The compressed file is only a one liner... in the patch it seems that there are more than one line...
So - we can make a patch for the "normla" file and also give the whole new compressed file as a replacement....
(to patch a one liner doesn't make sense...)
Best would be an extension update!!!
#28 Updated by Christian Hernmarck over 9 years ago
reply to 0013276:
As you wrote in 0013272 the check is only to detect this WamCom version. Are there also spaces between rv: and the version numer? you wrote "1.3.0 and 1.3.1" so I didn't know there is also an "1.3 "...
When Firefox reaches rv:1.30.something we are running in another problem... or our grand childern.... :-)
#29 Updated by Christian Hernmarck over 9 years ago
Since I dont' know if someone is updating the current rtehtmlarea extensions I did it for version 1.4.3
> 1.4.3a :)
See attached file... T3X_rtehtmlarea-1_4_3a-z-200703251756.t3x
Changed: the two htmlarea(-compressed).js, Changelog and ext_emconf.php (version & md5).
Maybe someone can put this on TER??? (I never did this ...) and create an update for 1.1.5 and 1.5...
#30 Updated by Christoph Blömer over 9 years ago
The patch: T3X_rtehtmlarea-1_4_3a-z-200703251756.t3x
is working at my typo3 installation.
When will it be on TER and when ist there an update for the 1.5.1 dev Version
And what is special about the 1.1.5 Version? It shows up as the newest Version in TER.
#31 Updated by Karsten Dambekalns over 9 years ago
I just uploaded a patch that removes the check for WaMCom completely (no updates on that project since 2003, abandoned since 2004). The T3X file is the patched version for easy testing.
REMEMBER to clear typo3temp/* AND your browser cache!
#32 Updated by Michael Stucki over 9 years ago
I replaced Patricks patch with a slightly fixed version (removed double ";;" in the compressed version).
Additionally I have uploaded a patch for TYPO3 4.0.x
#33 Updated by Marcel Alburg over 9 years ago
The extensions doens't work with typo3 4.1.
Is there any patch for htmlarea 1.5-dev ?
#34 Updated by Michael Stucki over 9 years ago
Oh well... For sure it does! The attached patch bug_5266.diff is for current SVN which should be equal to TYPO3 4.1.
Please check the following:
- There must be no copy in typo3conf/ext/ or typo3/ext/, otherwise the modification in typo3/sysext/ is void.
- Remove typo3temp/*.js
- Clear your browser cache.
#35 Updated by Marcel Alburg over 9 years ago
With bug_5266.diff and typo 4.1 with rhtmlarea 1.5-dev it works.
#36 Updated by Lars-Erik Forsberg over 9 years ago
I was able to successfully patch rtehemlarea v1.5dev on a TYPO3 4.1 install with "bug_5266.diff" supplied above. However I have been unable to successfully patch version 1.4.3 of the RTE on a TYPO3 instance using the 4.0.4 source.
My understanding from http://bugs.typo3.org/view.php?id=4870 is that both htmlarea-compressed.js and htmlarea.js need to be altered?
When I attempt to apply the diff patch bug_5266_4-0.diff to "htmlarea-compressed.js" (version 1.4.3) I receive the following error:
patching file htmlarea-compressed.js
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file htmlarea-compressed.js.rej
patching file htmlarea.js
#37 Updated by Christian Hernmarck over 9 years ago
reply to (0013323) Lars-Erik Forsberg:
The no-wamcom-Patch semms to run through...
I patched it manually - the difference is describd in the former notes...
#38 Updated by Robert Destigter over 9 years ago
I tried both .t3x files on a Firefox 184.108.40.206 and TYPO3 4.1 installation, but both fail.
The Firefox error console reports: "each is not defined". Clicking the error redirects me to the line: "var plugin = eval(plugin);"
IE, both 6 and 7 also fail (what else can you expect).
#39 Updated by Oliver Hader over 9 years ago
In reply to note 0013330:
#40 Updated by Clemens Riccabona over 9 years ago
My Xperience: Typo3 3.8. Intalled T3X_rtehtmlarea-1_4_3-z-200703261132.t3x as provided above as sysext.
Deleted all typo3temp files. Cleared all cache (and also my browsercache).
Now the editor loads, but the Window for creating links shows blank content.
#41 Updated by Karsten Dambekalns over 9 years ago
Regarding ~13346 - the extension I uploaded is taken from 4.0.5, most probably it is simply incompatible to TYPO3 3.8.
#42 Updated by Clemens Riccabona over 9 years ago
This may be right. But I can not update to typo3 4.1 immediately, because the system is a little bit more sophisticated set up, than 'normal' typo3 installations.
About 500 BE users, in about 200 groups, with about 250 different 'sites'.
As it is a 3.8, I'm also not able to tell the users, they should use IE, because most of them have already IE7, which breaks with typo3 3.8.0
AND: If it is not compatible with typo3 3.8.0, why isn't it set in ext_emconf.php????
#43 Updated by Axel Klarmann over 9 years ago
The problem concerning 3.8 is solved by using the patch only (the diff may not work, but i didn't test this). I just removed the line of the browser test containing the test for the wamcom browser. The extension seems to be incompatible 3.8; Updated the files manually and it works for all version i got; 3.8 - 4.0
#44 Updated by Christian Hernmarck over 9 years ago
my rte 1.4.3 is for Typo3 >= 4.0 (see below) but AFAIK the ExtManager in Typo3 3.8 doesn't care about that...
So, we need a version 1.1.5a - which IMHO should run with Typo3 3.8
'constraints' => array(
'depends' => array(
'cms' => '',
'php' => '4.1.0-',
'typo3' => '4.0-',
#45 Updated by Karsten Dambekalns over 9 years ago
Regarding TYPO3 3.8: of course new fixed versions will be released for 3.8 as well.
But: the version I attached to this bug is for testing purposes, and as such I just didn't care for 3.8 - which I don't run anymore. So stay cool.
#46 Updated by Clemens Riccabona over 9 years ago
Solved the problem for my customer as follows:
Installed Version 1.3.8 from TER.
Deleted the OR of the is_wamcom Variable.
Worx now. :-)
I know, it's QD but for me it's okay in this special case.
#47 Updated by Christian Hernmarck over 9 years ago
Just uploaded a corrected version for rtehtmlarea 1.5.1dev -> 1.5.1a-dev
for the ones with Typo3 v 4.1.0
Works for me - be sure to clean the browser cache and all typo3temp/htmlara... files
#48 Updated by Christian Lerrahn over 9 years ago
Guys, it is rather unhelpful if dozens of people posts patches here that don't really solve the problem. That the patch helps you, does not seem to mean that it will help everyone.
Please do not write that your patch solves the problem if you haven't confirmed it properly. None of the patches I found here seemed to work for me (Firefox Linux 220.127.116.11).
#49 Updated by Christian Hernmarck over 9 years ago
You're almost right. The problem is "solved" (FF 18.104.22.168 and rtehtmlarea don't work together) - I don't know why there are that much patches - it's IMHO much better (and for some people the only way) to upload a new rte extension - the only problem is the cache of Typo3 - AFAIK there is know "Typo3 way" to delete the typo3temp/rtehtmlarea*.js - but this is important!
BTW: I also use FF Linux 22.214.171.124 and my extensions (1.4.3a and 1.5.1a-dev) are working for me.
#50 Updated by Christian Lerrahn over 9 years ago
Ok. I confirm that this works for me now, too. No clue why I could not get it to work before.
#51 Updated by Clemens Riccabona over 9 years ago
Just a question: Why is htmlarearte 1.5.1dev NOT in TER??
Probably this would be much easier to handle for most users. ;)
@Post 0013364 and all others which may be confused:
The only thing you have to get rid of is the Browserversion check 'is_wamcom' in connection with gecko browsers. This works I think for everyone in the described way ( -> patch both, htmlarea.js AND htmlarea_compressed.js -> delete all rtehtmlarea* files from typo3temp, -> clean your browsers cache and restart it!).
The way, how to get rid of the faulty wamcom test may be different ... (Depends on the needs of each installation -> Version of t3, version of htmlarea....)
#52 Updated by Oliver Hader over 9 years ago
I uploaded the new extension versions for TYPO3 3.7 and TYPO3 3.8. Please do not use them for TYPO3 4.x releases!!
End of this week there will be new patch-level releases of TYPO3 4.0 Core and TYPO3 4.1 Core which will include the fix on RTEhtmlarea. The RTEhtmlarea is since TYPO3 4.0 part of the Core and thus developed with the Core.
T3X_rtehtmlarea-1_1_6-z--TYPO3-3_7.t3x (RTEhtmlarea 1.1.6 for TYPO3 3.7 only)
T3X_rtehtmlarea-1_2_2-z--TYPO3-3_8.t3x (RTEhtmlarea 1.2.2 for TYPO3 3.8 only)
TYPO3 3.7 & 3.8 users: Please test these extensions and tell, if there are any problems on your releases. These extension upgrades will be published on the TER tomorrow.
#53 Updated by Morten Therkildsen over 9 years ago
Will there be a new version of TYPO3? - should be. It's not fair to patch a fresh install of TYPO3.
#54 Updated by Oliver Hader over 9 years ago
Morten, as mentioned one post before yours:
There will be new patch-level releases of TYPO3 4.0 and 4.1, which means:
TYPO3 4.0.6 and TYPO3 4.1.1 as new releases.
#56 Updated by Oliver Hader over 9 years ago
Okay, there were three new releases published to TER:
- 1.1.6 (replacing 1.1.5) for the TYPO3 3.7 branch
- 1.2.2 (replacing 1.2.1) for the TYPO3 3.8 branch
- 1.4.4 (replacing 1.4.3) for the TYPO3 4.0 branch (including the features by Stanislav that are not in Core)
Today or tomorrow there will be prerelease of 4.0.6 and 4.1.1. If nobody objects, the final patch-level releases will be published at the beginning of the next week. The versions that are part of the Core as system extensions were not uploaded to TER, these are:
- 1.3.9 (replacing 1.3.8) only in TYPO3 4.0.6! Not in TER!
- 1.5.2 (replacing 1.5.1) only in TYPO3 4.1.1! Not in TER!
Just check http://typo3.org/download/packages/ for new releases the next few days...
#57 Updated by Oliver Hader over 9 years ago
Several patches for different TYPO3 branches were published in TER and SVN. New releases of the 4.0.x and 4.1.x branches will be available in the next few days.
If you experience further problems concerning this issue and thus, only on Firefox 126.96.36.199, please make sure that you've installed the correct version of the extension, check if you're using a local extension or a system extension and finally clear the system cache. If the problem remains, please open a new bug-report and describe your problem in detail.
Thanks to anyone who supported TYPO3 to solve this bug by testing, researching, coding and whatever!
This bug is resolved and fixed!