Closed (fixed)
Project:
Wysiwyg
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
29 Dec 2011 at 06:26 UTC
Updated:
2 Jan 2013 at 21:50 UTC
Jump to comment: Most recent file
Comments
Comment #1
ksenzeeI couldn't get TinyMCE 2 to work (maybe a browser problem), but I *think* the attached patch handles all the other editors correctly. At least everything seemed to work in my testing. It's not the most elegant code I've ever written, either; I spent all day getting it working and tested, and that's all the time I had. Feel free to iterate. :)
Comment #2
bmcmurray commentedJust confirming that this works like a charm with CKEditor.
Comment #3
twodLooks good to me too, except when submitting the form normally. The editors still get a full detach then, making things jump around.
I added a 'serialize' argument in the call to Drupal.wysiwygDetach() in Wysiwyg's event handler for reacting to form submissions to fix that.
Changed the comment over the detach() method in none.js to closer match the style in Drupal.detachBehaviors().
Also fixed jWysiwyg, which was still detaching at all times.
I hope there won't be any memory leaks from this, but I suppose we'll find out sooner or later.
Can you please confirm this is working as expected?
Comment #4
sunCan't we enforce a default of 'unload' in the detach or wysiwygDetach method?
Comment #5
twodI don't like that part either, but it is possible to call all those methods directly from any code...
On the other hand, not having those checks there could send the signal that we don't wish those methods to be called directly.
I think I might actually like that better, as it goes along with what I had in mind for 3.x.
Comment #6
sunyep, that's in line with my thinking. Other scripts and external code should never call those editor-specific methods directly. If at all, then only our own, editor-specific integration code (within the same file) may call them.
Comment #7
twodRerolled with the changes. The editor implementations now assume the trigger parameter is always present.
To speed things up, I'll commit this in a week unless something comes up.
EDIT: Just noticed I uploaded the wrong patch, it still has a some lines with
trigger = trigger || 'unload'left there, will put the correct patch up later.Comment #8
jantimon commentedI had the same issue (with tinemce) and could fix it with #7.
Comment #9
Juan C commentedCan someone update and applied the patch on #7 against the latest dev. version.
Thanks in advance.
Comment #10
twodI've committed the below patch to D7.
The -dev snapshots will be updated within 12 hours and this change will be in the next official D7 release.
I don't think we can fully backport this to D6 and/or D5 as we don't have the trigger argument or the detach behavior there, but if anyone has ideas, I'm interested. Marking this as 'needs backport' for now.
Comment #11
sunYay, thanks!
For D6, at least our own form submit handler could pass the appropriate trigger. For any other calls, we'd default to 'unload' in wysiwygDetach(), so the previous behavior is retained.
Comment #12
twodThat should fix things for regular submissions, but AJAXed submissions will still make the editors flicker and the page scroll uncontrollably. I think we'll still have other issues related to AJAX in D6 anyway, so maybe that's not a priority?
Comment #13
twodI have committed a backport of this for 6.x-2.x, without the detach() method in
Drupal.behaviors.attachWysiwygsince there's no equivalent to it in D6.