HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


[SOLVED] A bug in the WYSIWYG editor when editing user profiles with Internet Explorer?

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#103049 (In Topic #20184)
Avatar

Community saint

I think I've found another editor bug :$
 
I use the latest versions of Internet Explorer and Google Chrome, and this particular issue only seems to be affecting Internet Explorer. In both browsers, WYSIWYG mode is enabled. I'm seeing the issue in areas like the Settings, Profile, and Signature tabs under the Edit tab of the members profile page. I'm seeing ​[semihtml][/semihtml] and [html][/html]​ comcode tags and in some cases even some actual html code being added to sections where the editor has no content at all. This happens when editing a user profile and clicking the Save button. I don't think this is affecting news or blog editing and I haven't tested for this issue in any other areas (forums, catalogs, wiki+, etc).
 
I think it's a little more complex than that though. Exactly what happens, and where, seems to depend on what tab you're on when you click the Save button? For example, I start off on the Settings tab under the Edit tab of a member profile. There is only one editor box (Private Topic guidelines) on that page and it is empty. If I leave that tab and go to the Profile tab, it has three editor boxes (About me, Interests, and Staff notes) and only About Me section has some plain text (no html or comcode, except for an apostrophe that was converted to ') and the other two editor boxes are empty. If I stay on the Profile tab and click Save, when I come back to the Settings tab under the Edit tab, I get this on the Private Topic guidelines editor box (clicking the Source button in the editor):
 
​​
​[html]<br />
<br />
&nbsp;[/html]​​​​​
​​​​​
 
or this:
 
​[html]<br />
&nbsp;[/html]​​​​​
​​​​​
 
And I get ​[html][/html]​ tags wrapping the plain text of About Me section of the Profile tab. And for the Interests and Staff notes sections, in the editor (clicking the Source button) I get this in both editor boxes:
 
<br />
&nbsp;
​​​​​
 
Each subsequent Save seems to put html comcode tags and/or semihtml comcode tags in each editor box each time it is saved. However, if I go back to Google Chrome browser and load the same profile that now has all of these extra html and comcode tags and go to the Edit tab, it all looks normal without all of the extra comcode tags or the html. If I re-save the profile from Chrome and load it back in with Internet Explorer, I get ​[html][/html]​ comcode tags wrapping the plain text of the About Me editor box on the Profile tab and the plain text signature in the Signature editor on the Signature tab. And the other sections that should have blank editors are back to blank again (with no html showing with the Source button in the editor).


Last edit: by Jason Verhagen
Back to the top
 
Posted
Rating:
#103071
Avatar

Hi,

I haven't tried to reproduce, but I'm not surprised different browsers are handling "empty" states differently in the editor.

I believe this will fix it:

Code (diff)

diff --git a/sources/comcode_from_html.php b/sources/comcode_from_html.php
index e2a15c8..663d3bf 100755
--- a/sources/comcode_from_html.php
+++ b/sources/comcode_from_html.php
@@ -304,6 +304,8 @@ function semihtml_to_comcode($semihtml,$force=false)
        require_code('obfuscate');
        $semihtml=trim($semihtml);
 
+       if (ocp_trim($semihtml,strlen($semihtml)<30)=='') return '';
+
        @ini_set('pcre.backtrack_limit','10000000');
 
        $semihtml=preg_replace_callback('#<input [^>]*class="ocp_keep_ui_control
 

We'll incorporate this. I think it's better to assume having only whitespace-like stuff in the editor is a signal for "totally empty", and if people really want just line breaks they can turn WYSIWYG off for the field.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#103072
Avatar

Community saint

Chris Graham said

Hi,

I haven't tried to reproduce, but I'm not surprised different browsers are handling "empty" states differently in the editor.

I believe this will fix it:

Code (diff)

diff --git a/sources/comcode_from_html.php b/sources/comcode_from_html.php
index e2a15c8..663d3bf 100755
--- a/sources/comcode_from_html.php
+++ b/sources/comcode_from_html.php
@@ -304,6 +304,8 @@ function semihtml_to_comcode($semihtml,$force=false)
        require_code('obfuscate');
        $semihtml=trim($semihtml);
 
+       if (ocp_trim($semihtml,strlen($semihtml)<30)=='') return '';
+
        @ini_set('pcre.backtrack_limit','10000000');
 
        $semihtml=preg_replace_callback('#<input [^>]*class="ocp_keep_ui_control
 

We'll incorporate this. I think it's better to assume having only whitespace-like stuff in the editor is a signal for "totally empty", and if people really want just line breaks they can turn WYSIWYG off for the field.
I added the fix to the web site and that does appear to be working for the empty editor boxes. I'm still getting [html][/html] tags wrapping around the content in editor boxes that do have content, only in Internet Explorer. That itself isn't really a problem. But if I save that in Internet Explorer, it then wraps all of that in [semihtml][/semihtml] tags. In Chrome, with WYSIWYG enabled and clicking the Source button in the editor, I save this as my Signature:

Code

<b>Jason</b><br />
<span style="font-size: 0.8em;"><i>HolleywoodStudio.com / WebMaster<br />
The H-Factor / Tech Producer</i></span><br />
<br />
&nbsp;

If I load it back in with Internet Explorer I get:

Code

[html]<b>Jason</b><br />
<span style="font-size: 0.8em;"><i>HolleywoodStudio.com / WebMaster<br />
The H-Factor / Tech Producer</i></span><br />
<br />
&nbsp;[/html]

If I then save that in Internet Explorer, I get:

Code

[semihtml][html]<b>Jason</b><br />
<span style="font-size: 0.8em;"><i>HolleywoodStudio.com / WebMaster<br />
The H-Factor / Tech Producer</i></span><br />
<br />
&nbsp;[/html][/semihtml]

Subsequent saves from Internet Explorer results in another set of semihtml comcode tags wrapping the content each time. But if I reload the same page back in Chrome, all of the extra comcode is stripped back out and it's all back to normal.
Back to the top
 
Posted
Rating:
#103081
Avatar

I couldn't reproduce on my test server, but could on your site. Playing with a debugger suggests this fix works…

Code

diff --git a/themes/default/templates/JAVASCRIPT_EDITING.tpl b/themes/default/templates/JAVASCRIPT_EDITING.tpl
index 2035d98..0a12a96 100755
--- a/themes/default/templates/JAVASCRIPT_EDITING.tpl
+++ b/themes/default/templates/JAVASCRIPT_EDITING.tpl
@@ -239,7 +239,7 @@ function load_html_edit(posting_form,ajax_copy)
                        window.wysiwyg_original_comcode[id]=e.value;
                        if (!ajax_copy)
                        {
-                               if ((typeof posting_form.elements[id+'_parsed']!='undefined') && (posting_form.elements[id+'_parsed'].value!='') && (e.defaultValue==e.value)) // The extra conditionals are for if back button used
+                               if ((typeof posting_form.elements[id+'_parsed']!='undefined') && (posting_form.elements[id+'_parsed'].value!='') && ((e.defaultValue==''/*IE bug*/) || (e.defaultValue==e.value))) // The extra conditionals are for if back button used
                                        e.value=posting_form.elements[id+'_parsed'].value;
                        } else
                        {


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#103086
Avatar

Community saint

Chris Graham said

I couldn't reproduce on my test server, but could on your site. Playing with a debugger suggests this fix works…

Code

diff --git a/themes/default/templates/JAVASCRIPT_EDITING.tpl b/themes/default/templates/JAVASCRIPT_EDITING.tpl
index 2035d98..0a12a96 100755
--- a/themes/default/templates/JAVASCRIPT_EDITING.tpl
+++ b/themes/default/templates/JAVASCRIPT_EDITING.tpl
@@ -239,7 +239,7 @@ function load_html_edit(posting_form,ajax_copy)
                        window.wysiwyg_original_comcode[id]=e.value;
                        if (!ajax_copy)
                        {
-                               if ((typeof posting_form.elements[id+'_parsed']!='undefined') && (posting_form.elements[id+'_parsed'].value!='') && (e.defaultValue==e.value)) // The extra conditionals are for if back button used
+                               if ((typeof posting_form.elements[id+'_parsed']!='undefined') && (posting_form.elements[id+'_parsed'].value!='') && ((e.defaultValue==''/*IE bug*/) || (e.defaultValue==e.value))) // The extra conditionals are for if back button used
                                        e.value=posting_form.elements[id+'_parsed'].value;
                        } else
                        {


I applied that edit, but that didn't seem to work. I still get [html][/html] tags wrapping the content in edit boxes that have content on the first save, and [semihtml][/semihtml] added on each subsequent save.
Back to the top
 
Posted
Rating:
#103087
Avatar

Darn. Have you checked javascript_editing.js as read by IE has had that change come through?

(No IE or ocP or proxy cache or cloudflare cache blocking the change)


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#103088
Avatar

Community saint

Chris Graham said

Darn. Have you checked javascript_editing.js as read by IE has had that change come through?

(No IE or ocP or proxy cache or cloudflare cache blocking the change)

I re-flushed all the caches and restarted the browser again, and I think that did it.

Thanks!
Back to the top
 
1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: