Wysiwyg 6.x-2.0
FCKeditor 2.6.5
Drupal 6.15

Toggle rich text to plain text ( provided via Wysiwyg)
Type something.
Hit save.
Nothing is saved.

Sorry if this is a dup but cannot find it on search.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kaakuu’s picture

Apparently this happens in Internet Explorer version 7
and probably not in Firefox.

Can someone confirm this in IE ? Any quick and dirty workaround so that users can successfully save either in rich text mode or plain text mode?

TwoD’s picture

Status: Active » Postponed (maintainer needs more info)

Is something saved when rich text edit is on?
Are there any JavaScript errors?
Are you using a default theme or have you tried with one?
Were you using the module (and it worked) before upgrading to 6.15?

kaakuu’s picture

Fresh install of Drupal 6.15
Fresh install of Wysiwyg 6.x-2.0 and FCKeditor 2.6.5
and Internet Explorer 7

Standard garland theme, no changes everything as it is.
No Javascript error messages.

Rich mode works okay.

Can you/someone else try ? Its reproducible it seems.

TwoD’s picture

I only had access to IE8 atm but a clean install of Drupal 6.15, Wysiwyg 2.0 and FCKeditor 2.6.5 worked fine when saving content after disabling the editor.
When rich text editing is disabled, the editor is detached and a 'fake' editor is attached instead to be able to put the resize bar back on the textarea (Dupal's own code is called to do that). No modification of the original textarea is done when the form is submitted, so I'm not sure where it could fail.

Are you 100% sure that noting at all is saved and it's not just a rendering problem? Ie, is the content there if you edit the node again? You could try running a local proxy like Fiddler (easy to set up) to catch all HTTP traffic and see if there is any POST data at all.

I'll get back tomorrow when I've been able to test this in IE7 as well.

kaakuu’s picture

Nothing is saved to the database, so that there is nothing to see on Edit mode too.
This problem happens wirh IE 7, which still has a fairly large number of users. Apparently it does not happen with FF. If the problem goes away with IE 8 its good.

But for the time being some work around or trick is needed to circumvent this. One way would have been if Wysiwyg could be enabled like Indic script editors on a per theme basis. Now its either for all themes or none. ( I want to post a feature request on this )

So I will also test more with IE 7, trying to understand what the problem is. In the meanwhile, keeping this posted and if any IE7 user can reproduce/confirm this I will know I am not alone having this problem.

TwoD’s picture

If you don't mind, I'd like to request access to the site where this happens. I only need enough permissions to create a node or comment using the relevant input format. Use the contact form on my profile if you send account details.
I find this problem really odd as, like I said before, Wysiwyg module basically hands things over to Drupal when the editor is disabled.

I've been unable to test it in IE 7 yet, problems with the virtual machine snapshot I use for Win XP + IE 7. Will keep trying.

EDIT: I got it working and I've now tested the same Drupal install in IE 6, 7 and 8 on WinXP and FF 3.5.6 on Ubuntu Karmic and the contents are saved properly. I installed Drupal 6.15 from scratch using a new DB and then enabled only Wysiwyg 2.0. I used the default Filtered HTML input format and set it to use FCKeditor and saved the editor profile once without changes (or the Disable Rich-Text editing button doesn't show up). When creating a new node I just disabled the editor, typed something and saved it.

A simple workaround if the non-editor mode doesn't work might be to disable the 'Disable rich text editing' link on the profile and enable the editor's 'Source mode' button instead.

I'm not sure why a enabled-per-theme setting would be a workaround in this case. I thought this happened regardless of which theme was used?

kaakuu’s picture

Thanks a lot for the whole effort you took to repeat the entire test.

Following your notes I did the same and I am unable to reproduce this on a fresh installation of just Drupal + wysiwyg + fck This means something, either any other module or whatever causing the problem in the other installation. Since this cannot be reproduced I think mark this as closed or fixed.

Per theme setting is a workaround in cases where one particular theme is screwy - Wysiwyg can be kept off for that theme (if such a feature was there). It is also useful where one needs to enable indic script module for a multilingual visitor population - indic script seems to be buggy (not confirmed) when enabled along with Wysiwyg, so two themes one with indic script typing other with regular Wysiwyg can be kept. Another usage can be when the site allows to choose the user a lite mode (eg. facebook lite) or a MOBILE/CELLPHONE mode those users can have a really light text area by default and no need to toggle.
This is actually a feature request needing another issue but now you must be 'busy' with the holidays. So postponing it for the next year.

Happy holidays :)

TwoD’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

I hope this issue didn't mess up a production site of yours, if so I could try to find the conflict if you're willing to provide an account.

That's a good point about different 'browsing modes'. We have planned to add support for multiple profiles per input format in Wysiwyg 3.x, maybe that could be tied into themes somehow. However, when Wysiwyg is turned 'off' for a field but the scripts are loaded because that field has an editor in either format, the 'fake' (aka 'none') editor is still used just as if Rich text edit had been turned off. Otherwise we could not re-attach the resize bar to the original textfield when switching from another editor. So if something is wrong with the 'none' editor it would still affect the field. The bad effect should be minimal tho since, like I said before, the 'none' editor runs no code before the form is submitted so the contents are never touched by Wysiwyg.

Anyawy, I'll mark this 'closed' since it can't be reproduced on a fresh install. 'Fixed' sounds wrong since nothing was patched and "won't fix" just looks like we didn't want to patch it...

Happy holidays!

kaakuu’s picture

No not at all :). Its not production site, a test site that I am trying to develop for multiuser blogging along with geolocation and multiple blogs per user.
So there is no url. The conflict seems to happen with Advanced Blog and I have posted issues w.r.t that.
Thanks again!

TwoD’s picture

Title: Nothing is saved in plain text mode » FCKeditor is not properly detached in IE
Status: Closed (fixed) » Active

I've found that FCKeditor's onsubmit handler still runs after we've detached the editor and this will sometimes cause the editor to run the function to transfer the editor contents back to the original textarea, hence the field is emptied or returned to its previous value (which was stored in the editor). I think we might be racing the garbage collector here because it seems much less likely to happen after waiting some time or running other scripts on the page. I think I partially confirmed this by alert(FCKeditorAPI.Instances['edit-body']) not saying 'undefined', which it should since we delete it in the detach() method.

So far I've only seen this in IE 7, but I have not made extensive re-runs of the tests in the other versions yet. Debugging this appears to be very hard (especially using MS's crappy Script debugger...) but I'll try my best.

kaakuu’s picture

Thanks TwoD.
Can you kindly say how to set alert(FCKeditorAPI.Instances['edit-body']) to 'undefined' - that is, in which file I find this line?

The standalone FCKeditor module for Drupal do not seem to have this problem, if that is any clue. But once used to Wysiwyg its impossible to change to that.

TwoD’s picture

That code snippet is not in a file, it's something I used to debug with. After detaching the editor, typing javascript:alert(FCKeditorAPI.Instances['edit-body']) in the browser's address bar and pressing enter should show a popup box saying 'undefined'. But now it says 'Object [object]' or something similar for a while until the browser finally gets around to actually remove the object which we asked to have deleted in the detach() method in fckeditor-2.6.js.

The fckeditor.module only hides the editor when toggling it off. I don't think we can do that due to the risk of interfering with other editors.

kaakuu’s picture

Let us take the risk. As optional on or off code snippet which can be manually added by those who want. I am so much eager to know which/what line to be added where.

'Thanks' will now be a lesser word for the immense support and fast responses by you.

TwoD’s picture

Version: 6.x-2.0 » 7.x-2.x-dev
Status: Active » Needs review
FileSize
1.12 KB

How about if we remove the offending event handler instead? It's automatically added each time FCKeditor is attached anyway, so it shouldn't hurt.
This patch seems to do the trick. It uses FCKeditor's own functions to as they already has the proper browser specific code in them.
I've tested this in IE 7 on an actual machine and in a virtual environment, the code to transfer the editor's contents to the textarea are no longer called.

If possible, we should probably do this for other editors as well, but I don't think all of them keep references to the event handlers where we can access them.

The patch was created against 7.x-3.x-dev as the editor implementations are the same, it should be possible to apply to 6.x-2.x-dev and 6.x-2.0 (which is what I originally wrote it for) as well but with some line offsets.

kaakuu’s picture

Yay! This seems to work for 6.x-2.0 - need more tests etc.
But that damned IE7 now is able to save plain text.

TwoD’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
1.24 KB

Just changed the commenting to what I hope gives it a smaller WTF factor.
This patch applies to all branches, with an offset of 1 for some.

Based on kaakuus IE7 test, and more testing in other versions and browsers, and it being a pretty straight forward fix, I'm considering this RTBC.
Will hold off committing it for a day or two just to give people a final chance to look at it. The status should provoke at least some responses. ;)

sun’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for reporting, reviewing, and testing! Committed with a couple of comment tweaks to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.