{9} All Changed Tickets (40 matches)

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.

Recent versions of Firefox do in fact exhibit the problem, and a quick check of IE also shows some signs of it. I will apply Nicholas' fix to these modules, and also Opera (which I have not checked but at the least I don't see how it could hurt anything).

changeset:1316 probably fixes this

See forum post http://www.xinha.org/punbb/viewtopic.php?id=3782

In IE9 xinha build 1263 onwards fail to load. They stop showing in the loading box.

Loading in progress. Please wait! Create Toolbar

Using IE developers tools I get the following error in the console... but not in compatibility mode when it works fine.

SCRIPT5002: Function expected XinhaCore?.js, line 1572 character 18

Commited (something like it) in changeset:1314

Leaving ticket open so it's easy for people to find this.

Thanks, that worked for me.

seems that problem was fixed with new FF update

Disable all Xinha plugins and then try.

There's no reason that simply the word "graph" would cause such a thing in the Xinha core that I can think of.

And for the love of all that is holy, use a proper browser when you debug, Chrome or Firefox.

You can see the problem in Xinha demo instalation, right here:

http://xinha.raimundmeyer.de/latest/plugins/ExtendedFileManager/backend.php?__plugin=ExtendedFileManager&__function=images&mode=image&viewtype=thumbview#

Isn't the permission to delete the files being denied by the operating system instead of the application? Should this screen appears called directly by the browser or should it only appears called by the editor? Isn't this the latest version?

No it doesn't. You must have a poor configuration or an old version. Ensure you properly configure your EFM and ImageManger?.

changeset:1326

There seem to be two problems with the status bar's width calculation:

1. Its width property is set to be equal to the width of the overall container. But in Xinha.css, the statusbar is given 4px padding-left and 4px padding-right, as well as a 1px border on each side. So when _statusBar.style.width is set to N px, its actual calculated width ends up being N+10 px.
2. Even after accounting for that, the status bar's width property is derived from the _htmlArea's offsetWidth, but the _htmlArea's offset width has an extra two pixels (from borders, I think) that shouldn't be included.

The following patch addresses the problem I'm seeing, by using _htmlArea.clientWidth instead of .offsetWidth, and by manually subtracting 10 pixels to account for the status bar's styles; probably the 10 pixels shouldn't be hardcoded, and I'm not sure if using clientWidth is really correct here.

Also, I haven't tested on any other browsers/versions/operating systems, so the patch isn't final.

Index: XinhaCore.js
===================================================================
--- XinhaCore.js	(revision 1327)
+++ XinhaCore.js	(working copy)
@@ -2230,7 +2230,9 @@
     } 
     else
     {
-      var width = size['width'];
+      var width = parseInt(size['width']);
+      // the statusbar has 4px padding on each side, plus 1px border on each side
+      width = width - 10;
       self._statusBar.style.width = width + "px";
     }
   });
@@ -3054,8 +3056,9 @@
   this._textArea.style.height = this._iframe.style.height;
   this._textArea.style.width  = this._iframe.style.width;
      
-  this.notifyOf('resize', {width:this._htmlArea.offsetWidth, height:this._htmlArea.offsetHeight});
-  this.firePluginEvent('onResize',this._htmlArea.offsetWidth, this._htmlArea.offsetWidth);
+  this.notifyOf('resize', {width:this._htmlArea.clientWidth, height:this._htmlArea.offsetHeight});
+  this.firePluginEvent('onResize',this._htmlArea.clientWidth, this._htmlArea.offsetWidth);
+
   this._risizing = false;
 };
 /** FIXME: Never used, what is this for?