Opened 9 years ago

Last modified 6 years ago

#1224 reopened defect

[confirmed] sevenbitclean? / ghost cursor error with html mode toggle (Firefox)

Reported by: guest Owned by: gogo
Priority: normal Milestone: 0.96
Component: Xinha Core Version: trunk
Severity: major Keywords: sevenbitclean 8286 8201
Cc:

Description

When sevenbitclean is enabled, toggling between html mode and wysiwyg mode inserts the following character at every end of line: ⁞

Tested on Firefox 2, on a Mac

Change History (6)

comment:1 follow-up: Changed 9 years ago by gogo

  • Severity changed from normal to major
  • Summary changed from sevenbitclean causes errors with html mode toggle to [confirmed] sevenbitclean causes errors with html mode toggle

Confirmed. I think it's the cursor place marker which is inserted when switching between modes.

comment:2 in reply to: ↑ 1 Changed 9 years ago by guest

  • Summary changed from [confirmed] sevenbitclean causes errors with html mode toggle to [confirmed] sevenbitclean? / ghost cursor error with html mode toggle (Firefox)

(Different guest here:) I get this behaviour even without having set sevenBitClean (Firefox 2 on a PC). The character, which looks like a ghost cursor, definitely appears where the cursor was at the time of switching between wysiwyg and html. No such character is inserted in IE7. Something else interesting: this is new behaviour which I have only just begun noticing, but the only change to my installation is that I recently moved from ISO-8859-1 to UTF-8 as the server default characterset. But I emphasize that I have NOT changed the seven-bit-clean option from its default value of false. I was thinking of working around this by running a regex to replace the character, but if it's a fault in the html view routine, it would be better to fix the fault than to patch it.

  • Geoffrey K

comment:3 Changed 9 years ago by guest

I think this is the Unicode character U+205E (four vertical dots). I don't know if this is the same as "character 173" mentioned in Ticket #1112, which was, in principle, fixed by ray, or whether this is a Unicode thing. I guess something like the following might fix it:

xinha_config.inwardHtml = function (html) {
          html = html.replace(/\u205E/g, '');
          return html;
       }

But it should really be fixed in the core, rather than on a per-user basis.

comment:4 Changed 9 years ago by guest

  • Keywords 8286 8201 added

Yet another guest

Can confirm different instances of this in Internet Explorer 6.0.2900, FireFox? 3.01 and Chrome 0.2.149.30 (Webkit)

In all cases this bug appears when using the sevenBitClean option (to make the resulting html suitable for email), however the actual symptoms vary.

In Internet Explorer a thin space (Unicode 8201) character is inserted at the cursor each time html mode is turned on, building up each time html mode is toggled on and off.

In Firefox and Chrome unicode character 8286 (as far as I know an undefined character) is inserted at the cursor each time html mode is turned on.

Opera 9.22 does not appear to be directly affected - from the files it looks like it is fed the 8286 character as a cursor placeholder - perhaps Opera recognizes it is not a valid character and strips it out?

The place to fix the bug (no help here, I don't know that much about javascript) is in the setCC and findCC functions, located at the end of the /modules/[specific browser] files. These are then called by XinhaCore?.js when toggling between modes:

switch(_cf){
case "textmode":
this.firePluginEvent("onBeforeMode","textmode");
this.setCC("iframe");
_d0=this.outwardHtml(this.getHTML());
this.setHTML(_d0);
this.deactivateEditor();
this._iframe.style.display="none";
this._textArea.style.display="";
if(this.config.statusBar){
this._statusBarTree.style.display="none";
this._statusBarTextMode.style.display="";
}
this.findCC("textarea");
this.notifyOf("modechange",{"mode":"text"});
this.firePluginEvent("onMode","textmode");
break;
case "wysiwyg":
this.firePluginEvent("onBeforeMode","wysiwyg");
this.setCC("textarea");
_d0=this.inwardHtml(this.getHTML());
this.deactivateEditor();
this.setHTML(_d0);
this._iframe.style.display="";
this._textArea.style.display="none";
this.activateEditor();
if(this.config.statusBar){
this._statusBarTree.style.display="";
this._statusBarTextMode.style.display="none";
}
this.findCC("iframe");
this.notifyOf("modechange",{"mode":"wysiwyg"});
this.firePluginEvent("onMode","wysiwyg");
break;

It would seem these two functions need to take into account sevenbitclean in order to know that the cursor placeholder will be converted to an escape sequence (which also defeats the purpose of the placeholder, since it can't figure out where to place the cursor when switching back).

comment:5 Changed 9 years ago by ray

  • Resolution set to fixed
  • Status changed from new to closed

rev [1051]

comment:6 Changed 6 years ago by guest

  • Resolution fixed deleted
  • Status changed from closed to reopened

It seems that Chrome 12.0.742.68 beta-m is producing the ghost cursor once more. If I toggle from WYSIWYG to HTML and back then save the contents and reload the content, the ghost cursor shows up where at the last cursor position.

Note: See TracTickets for help on using tickets.