__color__,__group__,ticket,summary,component,version,milestone,type,severity,owner,status,created,_changetime,_description,_reporter
1,Active Tickets,1349,<IMG ...> vspace hsapce deprecated in HTML 4.01 / XHTML,Xinha Core,trunk,2.0,defect,normal,gogo,new,2008-12-04T08:53:13Z+0000,2010-05-10T07:25:38Z+0000,"Hi, 

in Xinha there is the possibility to enter a value for vspace, hspace to have a spacing arround a image. 

When Xinha is used in frameworks, which are producing XHTML, like the Zikula CMS, the vspace, hspace attribute will be ignored. 

Instead of vspace, hspace it should be margin-left, margin-right, ... used. 

Links:
http://www.w3schools.com/tags/tag_img.asp 


",guest
1,Active Tickets,1226,[Confirmed] Hitting enter in certain documents causes the rest of the text to disappear in Firefox 3,Browsers_Firefox,trunk,0.97,defect,blocker,ejucovy,new,2008-06-06T19:45:18Z+0000,2010-11-22T17:01:20Z+0000,"Go to http://xinha.gogo.co.nz/xinha-nightly/examples/ExtendedDemo.html and in HTML mode, insert the followin HTML:
""General Resources<br /> 
<h3>mailing lists</h3>""

Go back to document view, click at the end of the first line and hit enter.  The second line will disappear.  This is because of a bug in FF3 where getSelection incorrectly reports a selection to the end of the iframe.  This has been ticketed with Mozilla at:
https://bugzilla.mozilla.org/show_bug.cgi?id=437672

Hopefully they'll fix it before release so that we won't have to patch around their bug.",douglas
1,Active Tickets,1224,[confirmed] sevenbitclean? / ghost cursor error with html mode toggle (Firefox),Xinha Core,trunk,0.96,defect,major,gogo,reopened,2008-06-05T01:51:54Z+0000,2011-05-29T00:22:40Z+0000,"When sevenbitclean is enabled, toggling between html mode and wysiwyg mode inserts the following character at every end of line: &#8286;


Tested on Firefox 2, on a Mac",guest
1,Active Tickets,1234,[confirmed] words attribute can't keep when type [enter] key,Xinha Core,trunk,0.97,defect,major,gogo,new,2008-06-18T03:03:49Z+0000,2008-11-26T15:40:11Z+0000,"for example: 
ppl use xinha editor , firstly set attribute like font size ,font color ......  then type line of words .ppl will change new line at end of this line. then problem comes to,  it will back to default style after ppl use [enter] key for typing new line.  fonts size and font color will back to default. 
it's a bug i think  :)

my email:  xhaooo@gmail.com  , 
waitting for response , thanks !",guest
1,Active Tickets,1137,[Equation] FF3 fixes & improved way of avoiding formula changes in editor,Plugins,,,defect,normal,None,new,2008-01-26T00:05:20Z+0000,2008-12-04T17:49:10Z+0000,"due to various reasons the design of the plugin only allows changing the formula in the plugin's popup formula editor. Previously changing the formula in the editor was avoided by selecting the whole node when the cursor was in it, which was not the best solution. Now, when the cursor is in the formula, key inputs like characters, delete, and backspace are simply cancelled",ray
1,Active Tickets,1385,Add a config option to show table borders,Xinha Core,trunk,0.97,enhancement,normal,gogo,new,2009-02-05T09:27:16Z+0000,2010-05-10T07:30:46Z+0000,"A request from the forum, which I think can be done easily in this release",ray
1,Active Tickets,1599,Ajax Problem,Xinha Core,trunk,,defect,normal,gogo,new,2012-09-03T12:19:52Z+0000,2012-09-03T12:19:52Z+0000,"Dear Sir,

there's something wrong with our xinha loader when we run ajax. the textarea doesn't load it for the second time, but when I set xinha_init=null at the top of my second page texarea it just run in google chrome only, but not in firefox or IE or opera!!!!

would you please help me

regards,
Babak

",guest
1,Active Tickets,1598,An error has occurred: Method Not Allowed,Plugins,trunk,,defect,normal,None,new,2012-08-23T17:51:26Z+0000,2012-08-23T17:51:26Z+0000,"I installed Xinha and am using it on an ASP.Net 4.0 page.  When the page loads I get the following error:

An error has occurred: Method Not Allowed
URL:http://localhost:2691/mydir/xinha/plugins/Linker/scan.php

I click OK and then everything is fine.  The editor works without any problems.

The only change I made to the XinhaConfig.js was to add my textarea id.  If I remove the Linker plugin the error goes away.",guest
1,Active Tickets,1600,auto scroll on enter,User Interface,trunk,,defect,major,None,new,2012-09-11T09:17:01Z+0000,2012-09-17T02:26:48Z+0000,"Hello, I've found a bug in Xinha. This is how and what happens:
Go into HTML mode paste some text in, exit HTML mode click anywhere inside the text, and press enter.
'''What is expected to happen:''' move the text following the cursor into a new line.
'''What happens:''' it moves the text following the cursor into a new line and ''scrolls down until the new line is the first line in the editor''.

This is very disturbing when you try to write something. 
This happens on all major browsers: Chrome, Firefox and Opera.

Also on Opera, when I do this xinha also adds from 3 to 7 or more new lines before the newly created line, just like I would press enter multiple times.(I'm not holding the enter key pressed for to long) This happens just in Opera.

* by new line I mean a new set of <p> tags",guest
1,Active Tickets,1586,background images and firefox latest release,Browsers_Firefox,trunk,,defect,major,None,new,2011-10-17T18:38:55Z+0000,2011-10-17T18:38:55Z+0000,"Hello, my name is Robert Hood, and have found that any background images set are being removed once opened in the editor via firefox. Is this a known issue or is there any understanding as to way this may be happening. I have searched high and low through the documentation and have not fond any discussion regarding this bug.

Thanks for any updates I may have missed.
-RH",guest
1,Active Tickets,1312,background-color is removed from table cells,Xinha Core,trunk,Improved table support,defect,normal,gogo,new,2008-10-22T14:44:07Z+0000,2008-11-26T15:51:05Z+0000,"When using cell properties you can insert a background-color on a cell. This inserts: <td style=""background-color:#ff0000...

The next time you open this content in the editor. The background-color is removed.

It's a problem in both IE6 and Firefox3.


Best regards

Henrik Stokbro Andersen
henrik.andersen@valtech.dk




My initialize:


    xinha_editors = null;
    xinha_init    = null;
    xinha_config  = null;
    xinha_plugins = null;

    xinha_init = xinha_init ? xinha_init : function()
    {
      xinha_plugins = xinha_plugins ? xinha_plugins :
      [
       'TableOperations',
       'ContextMenu',
       'InsertAnchor'
      ];
             if(!Xinha.loadPlugins(xinha_plugins, xinha_init)) return;

      xinha_editors = xinha_editors ? xinha_editors :
      [
        'dt_IWContentData'
      ];

       xinha_config = xinha_config ? xinha_config() : new Xinha.Config();
       
		xinha_config.toolbar = [
			[ ""separator"",
			  ""formatblock"", ""space"",
			  ""bold"", ""italic"", 
			  ""separator"",
			  ""copy"", ""cut"", ""paste"", ""clearfonts"", 
			  ""separator"", ""undo"", ""redo"", ""separator"",
			  ""justifyleft"", ""justifycenter"", ""justifyright"", ""justifyfull"", ""separator""
			],
		  
			[ ""insertorderedlist"", ""insertunorderedlist"", ""outdent"", ""indent"", ""separator"",
			  ""inserthorizontalrule"", 
			  ""createlink"", 
			  ""insertimage"",
			  ""separator"",
			  ""htmlmode"", 
			  ""popupeditor"", ""separator"", ""showhelp"", ""separator""
                  ],

			[ ""simpletablecreation"", ""tablegallery"",
 			  ""inserttable""
			]
		];	

      xinha_editors   = Xinha.makeEditors(xinha_editors, xinha_config, xinha_plugins);

      Xinha.startEditors(xinha_editors);
    }

	    Xinha._addEvent(window,'load', xinha_init);",guest
1,Active Tickets,1403,baseHref not stripped in Edit Link,Xinha Core,trunk,0.97,defect,normal,gogo,new,2009-03-07T11:46:58Z+0000,2010-05-10T07:54:41Z+0000,"When editing a link the directory component of baseHref is not stripped.

For example baseHref is www.example.com/something

When editing a link the URL inserted is /something/index.php

I fixed this in XinhaCore.js on line 2957 by replacing ""$1"" with this.config.baseHref

var _1d4=this.config.baseHref.replace(/^(https?:\/\/[^\/]+)(.*)$/,this.config.baseHref);
",guest
1,Active Tickets,1522,blank space above when creating a table,HTML Output,trunk,,defect,normal,None,new,2010-06-02T01:31:42Z+0000,2010-06-02T01:31:42Z+0000,"On creating a table, Xinha creates a blank whitespace just right above the table around 15-20 linebreakes. I checked the html code but it does not appear any spaces or html tags in there.

Is this a xinha bug? Maybe you can try creating a table.",guest
1,Active Tickets,1564,Cache-busting config option,Xinha Core,trunk,,enhancement,normal,gogo,new,2010-11-27T15:09:40Z+0000,2010-11-27T23:05:35Z+0000,"When doing development on Xinha or a plugin, the most recent changes in plugin files are sometimes not loaded when I refresh the page, because of my browser's caching behavior.

Sometimes this trips up users as well; a lot of requests for help in the forum end up being a matter of clearing the browser's cache and reloading.

It might be helpful to have a `cacheBuster` option in `xinha_config`. When set to true, it would append a random query string (like `""?nocache=""+new Date().valueOf()`) to all resources that are loaded by `XinhaCore.js`",ejucovy
1,Active Tickets,1310,Can't escape from a <pre> element,Xinha Core,trunk,2.0,defect,normal,gogo,new,2008-10-20T20:04:53Z+0000,2010-05-10T07:20:43Z+0000,"When the last element in the WYSIWYG editor is a {{{<pre>}}} element, there's no clear way to get out of that element and into a normal paragraph.  Hitting enter just expands the pre.

Even without a control to add pre elements, you can get them in your content pretty easily through copy-and-paste.",guest
1,Active Tickets,1411,Cannot display panel at bottom in Stylist,Xinha Core,trunk,0.97,defect,normal,gogo,new,2009-03-22T08:46:49Z+0000,2010-05-10T07:55:45Z+0000,"This used to work (I think in 95 or maybe earlier) but does not now.
I used to be able to add the stylist panel to bottom instead of the right (where in my opinion it takes too much space).
I managed to change Stylist.js to display at the bottom but the height parameter did not readjust like it used to.
This parameter should be a config item that can be set when calling xinha IMHO.
Thanks",guest
1,Active Tickets,1554,"Clean up and refactor shared ""createlink"" code and logic",Xinha Core,trunk,,enhancement,minor,ejucovy,new,2010-11-15T16:39:59Z+0000,2010-11-15T16:40:11Z+0000,"Per #1553:

> Further cleanup would be nice - the two linky plugins both
> define some functions with identical logic that could be 
> moved to core, and I think the same could be said of the 
> default logic for the anchor-double-clicker. But those can 
> be addressed separately, and are not essential.

Specifically:

 * The `pluginMethod.js` scripts in Linker and !CreateLink both define a `_getSelectedAnchor` method which seem to be identical.  Can/should this be moved to core?  (http://trac.xinha.org/browser/trunk/modules/CreateLink/pluginMethods.js)
 * Linker and !CreateLink use confusingly different names for their various functions -- `Linker._createLink` vs `CreateLink._show` vs `Linker.Dialog.show` ... vs `editor._createLink`!  It would be nice to rename the functions in `Linker` and `CreateLink` to be a bit more uniform.  Would this break any backwards compatibility promises?  (I doubt it, I don't think these plugins advertise anything as API.)  
 * Does it make sense to define the anchor-double-clicker somewhere more stable than `dblclickList`?  (http://trac.xinha.org/browser/trunk/XinhaCore.js#L1186)  It seems like a shame that the !DoubleClick plugin needs to rewrite this when it redefines the `dblclickList` because it's not necessarily obvious code.",ejucovy
1,Active Tickets,1578,Color picker does not keep proper position on page,Dialogs,trunk,0.97,defect,major,None,new,2011-05-19T02:16:44Z+0000,2011-05-19T02:16:44Z+0000,"The color picker plugin is not keeping the proper position on the page. I.E. When I scroll down on the page the color picker pops up higher on the page.  Here is the patch to fix this problem, the code is located in xinha/modules/ColorPicker/ColorPicker.js",guest
1,Active Tickets,1422,"Combobox options are defined in (unordered) object data structure, but it is treated as an ordered data structure",Xinha Core,trunk,0.97,defect,major,gogo,new,2009-04-13T13:46:40Z+0000,2010-05-10T08:22:22Z+0000,"Around line 4611 of XinhaCore.js, in prototype.updateToolbar, the selectedIndex of the fontname- and fontsize-comboboxes is determined based on the position of the selected option in the config's option listing. This listing is an object, i.e. unordered, so it cannot be assumed that the order in which the properties of such an object are handled by an iterator are in any way constant or consistent.",guest
1,Active Tickets,1605,Config ---Help Please,Xinha Core,trunk,,task,major,gogo,new,2012-11-29T11:18:16Z+0000,2012-11-29T11:18:16Z+0000,"Considerate thsi folder structure

+Root
+---Tools
+------Xinha
+------Config File
+ Html File with Textarea


After follow allow the step defined in the newbie start and read some example for the download, still can not change the texarea to xinha.",guest
1,Active Tickets,1502,"Create MootoolsFileManager plugin, combining ExtendedFileManager and ImageManager",Plugins,trunk,0.97,enhancement,normal,None,new,2010-02-18T02:12:36Z+0000,2011-03-28T23:09:31Z+0000,"As mentioned in ticket:1478 and ticket:708

Mootools File Manager (http://cpojer.net/Scripts/FileManager/Demos/)  is a php/ajax/dhtml/mootools based filemanager which allows the upload of multiple files simultaneously, progress bars, and a generally better experience when it comes to uploading and selecting files than ExtendedFileManager and ImageManager.

I will shortly commit a new plugin called MootoolsFileManager which utilises the Mootools File Manager to perform the basic function of both ExtendedFileManager and ImageManager.

Currently, the functionality is limited in that it is not possible to set the various other attributes of the image/link (border, alt, title, target etc), you may upload, rename, delete, create directories, and select the file you wish.

By default the configuration is locked down, it won't do anything until you configure it.  The configure.php file has instructions, but in brief, this is the recommended way.

{{{
     /** STEP 3 ***************************************************************
       * We create a default configuration to be used by all the editors.
       * If you wish to configure some of the editors differently this will be
       * done in step 4.
       *
       * If you want to modify the default config you might do something like this.
       *
       *   xinha_config = new Xinha.Config();
       *   xinha_config.width  = 640;
       *   xinha_config.height = 420;
       *
       *************************************************************************/

       xinha_config = xinha_config ? xinha_config : new Xinha.Config();
 
       with (xinha_config.MootoolsFileManager)
        { 
          <?php 
            require_once('../contrib/php-xinha.php');
            xinha_pass_to_php_backend
            (       
              array
              (
                'images_dir' => /home/username/public_html/images',
                'images_url' => '/images',
                'allow_images_upload' => true,

                'files_dir' => /home/username/public_html/files',
                'files_url' => '/files',
                'allow_files_upload' => true,          
              )
            )
          ?>
        }
}}}

== Future ==
As indicated, this version is limited to the most basic functionality.  We need to add the following...

  1. Add support for title and target when inserting links
  2. Add support for the various attributes that ImageManager allows you to edit (alt, border etc).
  3. Add support for resizing based on width/height attributes which get added in (2).
  4. Add support for editing images utilising ""Ajax Image Editor"" ( http://www.ajax-image-editor.com/ )",gogo
1,Active Tickets,1344,CSS plugin: Strange behaviour on IE,Plugins,trunk,0.97,defect,normal,None,new,2008-11-27T15:59:51Z+0000,2010-05-10T07:25:09Z+0000,"Hi,

Problem's description:

1: Under Xinha 0.95 with CSS plugin activated and IE7

2: Type a text (test1), select it and add a class with the CSS plugin drop down list.

3:clic just at the end of test1 and type carriage return (Enter)

4:type a text(test2)

5:look at the html

The corresponding html is like that under IE7: (As you can see <span> contains <p>)
<span class=""foo"">
    <p>test1</p>
    <p>test2</p></span>

The correspondant html is like that under FF3:(As you can see <p> contains <span>)
<p><span class=""pucevdp"">test1</span></p>
  <p>test2</p>

Additionaly it's difficult under IE to return in the normal style (strange behaviour depending on cursor position, selected text, etc.) 

Regards,

SB.

",guest
1,Active Tickets,1367,Cursor position is not set correctly when switching to source view,Browsers_Safari,trunk,0.97,defect,normal,,new,2008-12-30T17:13:07Z+0000,2008-12-30T17:13:07Z+0000,"The cursor placement works correctly in Safari when first switching into source view mode, but does not on subsequent changes into source view mode.

To reproduce:

 1. Insert the text, ""This is a test""
 2. Position the cursor someplace in the text (e.g., after the word ""This"")
 3. Switch into source view. Note that even though the cursor doesn't show up, it ''is'' in fact placed correctly (you can verify this by typing a character or two)
 4. Switch back to HTML mode. Note that the cursor is visible and stilled positioned correctly.
 5. Switch to source view again. The cursor will again disappear, and this time you can't type anything.

Tested on Safari 3.1.2. FF3 does not have this problem.",nicholasbs
1,Active Tickets,1484,Deeply relative links cause Xinha to fail,Xinha Core,trunk,0.97,defect,normal,gogo,new,2009-12-07T00:25:33Z+0000,2010-05-10T09:08:28Z+0000,"Read this thread:
http://www.xinha.org/punbb/viewtopic.php?id=2477",gogo
1,Active Tickets,1395,deprecated font tags for styling,Xinha Core,trunk,0.97,defect,normal,gogo,reopened,2009-02-14T08:30:39Z+0000,2009-11-14T18:01:15Z+0000,"xinha still uses the deprecated font tags for font size/ family.

it should instead either use css via classes or inline style or at the very least span elements.

Adam J",guest
1,Active Tickets,1487,Disco Bug in Stylist Plugin - activateEditor(),Plugins,trunk,0.97,defect,normal,None,new,2009-12-17T14:50:46Z+0000,2010-05-10T11:38:36Z+0000,"Hi there,

We're using Xinha in our CMS and found a strange bug in stylist plugin. If more than one Xinha is included in a document and you activate the first one an then, very short after that, the second textarea, then you get what we call a disco. The editors toolbars alternatingly activate and deactivate. 

User Interface is unusable until you click several times into one of the textareas. This occures in Xinha 0.96beta2 with stylist included.

I could reproduce this inside our CMS and in a local environment.",guest
1,Active Tickets,1347,do something more smart than showing an alert when right-clicking statusbar item,Xinha Core,trunk,0.97,enhancement,normal,gogo,new,2008-11-29T17:40:19Z+0000,2008-11-29T17:40:19Z+0000,,ray
1,Active Tickets,1565,DynamicCSS + Stylist together break HTML/WYSIWYG mode-toggling,Plugins,trunk,,defect,normal,,new,2010-11-29T02:02:35Z+0000,2010-11-29T02:02:35Z+0000,"As reported on the forum: http://www.xinha.org/punbb/viewtopic.php?id=3405

 1. Start the Xinha extended demo
 1. Enable both the Stylist and DynamicCSS plugins
 1. When the editor loads, toggle to html mode
 1. Now try to toggle back to wysiwyg mode

You will be unable to toggle back to wysiwyg mode; the toolbar is entirely greyed-out.

Possibly relatedly, there is a Javascript error:

  `/xinha-nightly/plugins/DynamicCSS/DynamicCSS.js:182 Uncaught TypeError: Cannot call method 'toLowerCase' of undefined`

The workaround is to only enable one or the other of the two plugins.",ejucovy
1,Active Tickets,1508,Editing inside DIV elements now almost impossible in Xinha/IE,Xinha Core,trunk,0.97,defect,major,gogo,new,2010-03-16T17:23:31Z+0000,2010-05-11T12:35:26Z+0000,"I'm not sure if it was the ""focus"" fix for #1268 which created the problem (I haven't updated my server installation for a while), but now in IE8 when attempting to edit content within absolutely positioned DIV tags, it is impossible to use any of the navigation keys (forward arrow, back arrow, etc.) without IE losing its focus inside the DIV area (the cursor jumps immediately to the end of the DIV, outside it). The problem might be related to the striped box which appears, in IE only, when editing inside absolutely positioned DIV tags. This was obscuring the ""new"" dialog system. The fix in #1268 was to force IE8 to focus on the first text field in the dialog box. Now, however, even without invoking a dialog, the striped box disappears as soon as one types anything inside the DIV. It is possible to continue typing, but as soon as one uses a navigation key, the cursor jumps outside the DIV, requiring a double-click to get back in. This effectively renders IE useless for editing such documents. NB Firefox does not have this problem, since it handles editing inside DIVs in a much more transparent manner.
  -- Geoffrey K",guest
1,Active Tickets,1359,EFM and image mode (RGB-CMYK),Plugins,,,enhancement,normal,None,new,2008-12-19T18:43:34Z+0000,2008-12-19T18:43:34Z+0000,"Its good idea to add in configuration for EFM restriction for some images mode. For example if user upload jpg in CMYK mode, IE  show as broken image.
getimagesize() tells for CMYK image mode, channels=4 and for RGB image mode channels=3

Something like: 
{{{
$IMConfig['allowed_image_modes']='RGB,CMYK' // enable all modes (default)
}}}
or
{{{
$IMConfig['allowed_image_modes']='RGB'// enable only RGB mode
}}}
",guest
1,Active Tickets,1396,EFM Link mode does not add the title attribute on the first time,Plugins,trunk,0.97,defect,major,None,new,2009-02-16T03:26:44Z+0000,2010-05-10T07:38:02Z+0000,"Select an image and click the File Link from EFM to create a link on the image, define an url or select some file, and set the tooltip text. 
The resulting link only has href and no title. Repeating the process and adding the title(tooltip) again get's it right.

",guest
1,Active Tickets,1466,EFM: automatically select a newly uploaded file,Plugins,trunk,0.97,enhancement,normal,None,new,2009-08-04T09:43:02Z+0000,2010-05-10T08:42:57Z+0000,"An issue in ExtendedFileManager is that when you upload files you have to browse the list to find the picture you just uploaded. I guess that the day you upload a file, you want to use it as it's done uploading...

To do this, get to xinha/plugins/ExtendedFileManager/Classes/'''ExtendedFileManager.php''', in the''' _processFiles($relative, $file)''' function.

You have to find something like


{{{
if(!is_int($result))
{
  Files::delFile($file['tmp_name']);
  Return 'File ""$file='.$file['name'].'$"" successfully uploaded.';
}
}}}


Inside this if-block, erase (or comment) the line that calls a return.

Before or after (not important) the call to Files::delFiles, add these lines:


{{{
$entry=Files::escape($file['name']);  //complies with the final name of the file
$t=array();  //our new return value
$t['relative'] = $relative.$entry;  //needed for the call to JS function selectImage (see below)
$img = null;  //should be $img = $this->getImageInfo($fullpath.$entry),
              //up to you to find how to create a fullpath with
              //ExtendedFileManager::getImagesDir, Files::makePath and $relative (given as a parameter)
if(!is_array($img)) $img[0]=$img[1]=0;
$t['image'] = $img;  //needed for the call to JS function selectImage
$t['entry'] = $entry;  //needed for the call to JS function selectImage
Return $t;
}}}


You can see it's (almost) a copy/paste of the contruction of the table in ExtendedFileManager::getFiles. Also, the statement $img = null; is because I don't need this piece of information, but perhaps you do.

Once this is done, you'll have to gather the result in JS function init defined in xinha/plugins/ExtendedFileManager/images.php.

Look for ""$uploadStatus"", you should have something like


{{{
if(isset($uploadStatus) && !is_numeric($uploadStatus) && !is_bool($uploadStatus))
  echo ""alert(i18n('$uploadStatus'));"";
...
}}}


Make it become


{{{
if(isset($uploadStatus) && is_array($uploadStatus))
  echo ""selectImage('""
       .$uploadStatus['relative'].""', '""
       .preg_replace('#\..{3,4}$#', '', $uploadStatus['entry']).""', ""
       .$uploadStatus['image'][0]."", ""
       .$uploadStatus['image'][1]."")"";
else if(isset($uploadStatus) && !is_numeric($uploadStatus) && !is_bool($uploadStatus))
  echo ""alert(i18n('$uploadStatus'));"";
...
}}}


The first case testing if we have our array out of the function issues a (future, JavaScript is client-sided) call to selectImage. This call is (almost) pasted from the same file. Look for ""selectImage"" if you don't believe me ;)

That's all, you should have your newly uploaded files already selected once the upload is over.",guest
1,Active Tickets,1520,Error in WordClean - clearClass,Xinha Core,trunk,0.97,defect,normal,gogo,new,2010-05-26T07:53:55Z+0000,2010-05-26T07:53:55Z+0000,"in function clearClass the line
node.removeAttribute(""..."") contains the wrong class name ""classname"" instead of class. 
With
node.removeAttribute(""class"");
it works.",guest
1,Active Tickets,1585,ExtendedFileManager Icons,Plugins,trunk,,enhancement,normal,None,new,2011-10-12T20:08:21Z+0000,2011-10-12T20:08:21Z+0000,"Can we have icons for docx, xlsx, pptx  files ?",guest
1,Active Tickets,1567,ExtendedFileManager images list,Plugins,trunk,,defect,normal,None,new,2010-12-15T13:50:06Z+0000,2010-12-15T13:50:06Z+0000,"When the image name is longer than $thisFileNameLength, the name goes in lower case. In file images.php, Line 211, strtolower() must be removed.

strtolower(substr($entry,0,$thisFileNameLength)).""...""",guest
1,Active Tickets,1543,ExtendedFileManager. Wrong path when edit properties.,Plugins,trunk,,defect,normal,None,new,2010-09-10T13:39:56Z+0000,2010-09-10T13:39:56Z+0000,"Inserting new image at page is ok.

But when open EFM by ""Image properties"", field ""File name"" get wrong path included directory name above root path of $IMConfig['images_url']


=====[ my cfg.php: ]=============================
$cfg['site']['url']= ""http://"".$_SERVER['HTTP_HOST'].""/somesoft/"";
$cfg['site']['dir']= ""c:/apache/htdocs/somesoft/"";
$cfg['files']['dir']       = ""files"";
============================================


=====[ EFM config.inc.php ]=========================
include(""../../../cfg.php"");

$IMConfig['backend_url'] = ""backend.php?__plugin=ExtendedFileManager&"";

$IMConfig['base_dir'] = getcwd();
$IMConfig['base_url'] = '';


$IMConfig['images_dir'] = $cfg['site']['dir'].$cfg['files']['dir'];
$IMConfig['images_url'] = $cfg['site']['url'].$cfg['files']['dir'];
============================================



File name when insert new image: /test.jpg
File name when edit properties of image: /somesoft/files/test.jpg",guest
1,Active Tickets,1604,Extra Bullets are being added when indenting,Plugins,trunk,,defect,normal,None,new,2012-09-28T07:53:48Z+0000,2012-09-28T07:53:48Z+0000,"When you bullet an item then create a new line (the next line will be bulletted as well) then increase the indent of the new line and after you save then xinha will add an extra bullet for each increment in indent.

Steps to reproduce:
-bullet a line
-press enter then increase the indentation(the bullet will change form)
-repeat previous steps if you want and add more indentations
-submit/save

Result new bullets will be added
I included screenshots to help and as proof",guest
1,Active Tickets,1475,Feature Request - Table Operations,Xinha Core,trunk,2.0,enhancement,normal,gogo,new,2009-10-06T18:08:09Z+0000,2010-05-10T08:43:55Z+0000,"I have noticed in CKEdit and a few others that when you are editing a table that when you are in a cell that the re-size box nodes are moved to the border of the cell and you can re-size the cell by using those. I am currently using xinha in my CMS Project OpenTitan. I am about to release the Hosted Commercial Service but I really need something like this.

Thank you",guest
1,Active Tickets,1400,FF3.0.5: paraHandlerBest - When hitting Enter in a table it skips to below the table,Xinha Core,trunk,0.97,defect,normal,gogo,new,2009-02-18T20:46:17Z+0000,2010-05-10T07:42:00Z+0000,"Go to http://www.xinha.org/xinha-nightly/examples/ExtendedDemo.html

Add a table to the bottom, after the UL by hitting Enter twice, with 2 rows and 2 cols, for example.  Position the cursor in the first row and column.  Hit Enter.  For some reason it skips to below the table.  I have had it do the proper thing if I inspect the html before hitting enter within the table.  This may be related to ticket 1226.

When it messes up, the resulting html below the ul list is as follows:


{{{
<p> </p>
  <table cellpadding=""5"" style=""border: 1px dotted #000000; width: 100%; border-collapse: collapse;"">
    <tbody>
      <tr>
        <td style=""border: 1px dotted #000000;"" />
        <td style=""border: 1px dotted #000000;""> </td>
      </tr>
      <tr>
        <td style=""border: 1px dotted #000000;""> </td>
        <td style=""border: 1px dotted #000000;""> </td>
      </tr>
    </tbody>
  </table>
  <p> </p><br />
}}}
",guest
1,Active Tickets,1588,Firefox -  GetHtml issue,Plugins,trunk,,defect,normal,None,new,2011-11-08T09:21:45Z+0000,2011-11-08T09:21:45Z+0000,"GetHtml plugin adding broken html code. Something like 

{{{
&lt;span id="">""&gt;
}}}

Reproduce the issue.


1) Put this code into editor with enabled GetHtml plugin.


{{{
<br />&nbsp;
<p style=""color:red;"">First text</p>
<p style=""color:red;"">Second text</p>
}}}

2) Switch to HTML view

3) Select word ""First""

4) Switch to Source view

5) Switch back to html view and see what is happen before word ""Second""
",guest
1,Active Tickets,1481,Firefox doesn't show embedded content when switch to WYSIWYG mode,Xinha Core,trunk,Currently Unfixable,defect,normal,gogo,new,2009-11-30T03:32:28Z+0000,2010-05-10T08:53:01Z+0000,"Insert embed content into article under the text-mode of Xinha:
"" <embed src=""http://www.tudou.com/v/UHdc70ECfPI"" type=""application/x-shockwave-flash"" allowscriptaccess=""always"" allowfullscreen=""true"" wmode=""opaque"" width=""420"" height=""363"">
    </embed>""
In IE, if you switch mode to WYSIWYG mode, you will see the embed content,like a flash.

But FF does not show the embed content when switching between modes. However, FF will show the video when Xinha is created or the article is submitted.

It would be nice, if Xinha can show the embed content when switching between modes in Firefox.

Hope it will be fixed soon.
",guest
1,Active Tickets,1427,Font changes in Firefox when starting new paragraph,Xinha Core,trunk,0.97,defect,normal,gogo,new,2009-04-16T16:25:58Z+0000,2010-05-10T08:24:05Z+0000,"Select a font face and size and type a paragraph.  Then hit enter and start to type a new paragraph.  The font face and size will revert to the font that was used before you selected new options.

This seems to happen in Firefox 2/3.  In IE, it will keep your font selection.  From looking at the html, it appears that font tags are inserted after the new paragraph tag is created, but the cursor is placed outside of the font tags.",guest
1,Active Tickets,1579,Fonts,Xinha Core,trunk,0.97,enhancement,normal,gogo,new,2011-05-24T19:15:08Z+0000,2011-05-24T19:15:08Z+0000,how I can include fonts of Google Web Fonts,guest
1,Active Tickets,1190,"FormOperations Bug with IE7 with the ""name"" Attribute, and other errors all over the place",Plugins,trunk,Currently Unfixable,defect,normal,None,new,2008-04-17T12:36:02Z+0000,2009-11-10T09:57:31Z+0000,"Hello

We found a Bug in the FormOperations Plugin using Internet Explorer 7.
1. In an empty Page create a simple Textfield
2. In the Dialog showing on the bottom of the Page enter some Text for ""Name"" and ""Value""
3. Click somewhere in the document then in the Textfield again, the Name and Value is still here.
4. But when you switch to source code view, the ""Name"" attribute is not there. When you switch back to Wysiwyg Mode the ""Name"" attribute is also empty.

In Firefox it works all perfect, this Error only appears in EI7

BG Manfred",guest
1,Active Tickets,1542,Fullscreen plugin hides caret/cursor in FF3.6.x,Browsers_Firefox,trunk,,defect,normal,None,new,2010-09-08T20:24:10Z+0000,2010-09-08T20:24:10Z+0000,"When going into fullscreen using Firefox 3.6.x, the cursor will disappear. Same goes for switching back to the previous size. This is most likely a [https://bugzilla.mozilla.org/show_bug.cgi?id=542727 Gecko bug] as it doesn't appear in the other browsers, nor Firefox 3.5.x. (FireFox4-beta-5 has this issue as well..)

A workaround I've found to work is: after the resize, put focus on a toolbar item, then restore focus to Xinha and the cursor will re-appear. To make the experience seamless, I've added saveSelection/restoreSelection as well.

I've currently implemented this using YUI2 but will change it into generic javascript and apply a patch in the coming week.

Cheers,
Arthur Bogaart
",guest
1,Active Tickets,1393,"Gecko.js, Opera.js must change to use keydown event in isKeyEvent(). Add event onKeyDown, onKeyEvent, change onKeyPress definition",Xinha Core,trunk,2.0,enhancement,normal,gogo,new,2009-02-13T15:35:51Z+0000,2010-09-30T10:33:39Z+0000,"Can we have an event for onKeyDown please 

e.g.
xinha_config.Events.onKeyDown

we currently have onKeyPress - but that fires too late.

Adam J",guest
1,Active Tickets,1421,getHTML plugins broke urls,Plugins,trunk,0.97,defect,normal,None,new,2009-04-08T20:58:14Z+0000,2010-05-10T08:21:21Z+0000,"if try to edit wacky url like

<a href=""http://test.com/john%27s"">test</a>

getHTML converts %27 to '",guest
1,Active Tickets,1590,ghost cursor error with html mode toggle in Firefox 9.0.1,Browsers_Firefox,trunk,,defect,normal,None,new,2012-01-24T00:57:28Z+0000,2012-01-24T00:57:28Z+0000,This issue where the character (U+205E)is being inserted when switching from HTML mode back to editing mode is still very much existing. Has anyone been able to resolve it? Please respond if you have any knowledge regarding this pesky issue.,guest
1,Active Tickets,1207,Identity Portion of Equation Editor that is inserting script reference,Plugins,trunk,0.97,enhancement,normal,None,new,2008-05-05T19:52:02Z+0000,2008-11-26T16:25:47Z+0000,"As I posted in the forum (net-buoy) I working with xinha and equation editor in moodle where I have also installed asciimathml as a filter.

Since asciimathml is running as a filter,  there is no reason to actually insert a reference to the asciimathml.js script in the edited page once the edits have been completed.  

I have looked at the code but am unclear how that insertion is accomplished and would like to be able to document how that can be commented out.

Eventually perhaps a separate button on the gui would be appropriate for inserting the reference or not,  which could be defaulted to however the user wishes?",guest
1,Active Tickets,1592,IE Browser has issues with bulk bulleting when text is copied from notepad.,Plugins,trunk,,defect,normal,None,new,2012-04-19T10:18:44Z+0000,2012-04-19T10:18:44Z+0000,"There is an issue with bulk bulleting using unordered/ordered list when a series of text options are copied from notepad.
For example: we copy[[BR]]
Apple[[BR]]
Mango[[BR]]
Banana[[BR]]

Steps to reproduce:[[BR]]
1. copy text from notepad to xinha editor [[BR]]
4. Select a line where you want to put the bullet. You may highlight all options (Apple, Mango, Banana)[[BR]]
5. Click on the bullet button from the tool bar(""Bulleted List"").[[BR]]
6. Bullet is placed at the begining of the Editor box and indents ALL the text.[[BR]]

Result:[[BR]]
* Apple[[BR]]
Mango[[BR]]
Banana[[BR]]

Expected result is:[[BR]]
* Apple[[BR]]
* Mango[[BR]]
* Banana[[BR]]

This is working in Google Chrome and Firefox.",guest
1,Active Tickets,1440,IE6 Security error on https (This page contains both secure and nonsecure items),Browsers_InternetExplorer,trunk,0.97,defect,normal,None,new,2009-06-03T12:49:38Z+0000,2010-05-10T08:32:45Z+0000,"Here is only fix for the IE6 Security error (This page contains both secure and nonsecure items) that works for me -> change src of every iframe-element from 
{{{
about:blank
}}}
to 
{{{
javascript:false;
}}}

For example in ExtendedFileManager at line 154 change:

{{{
<iframe src=""about:blank"" name=""imgManager"" id=""imgManager"" class=""imageFrame"" scrolling=""auto"" title=""Image Selection"" frameborder=""0""></iframe>
}}}
to
{{{
<iframe src=""javascript:false;"" name=""imgManager"" id=""imgManager"" class=""imageFrame"" scrolling=""auto"" title=""Image Selection"" frameborder=""0""></iframe>
}}}

And maybe the most important is in XinhaDialog.js at line 187:

{{{
backG.src = ""about:blank"";
}}}
to

{{{
backG.src = ""javascript:false;"";
}}}
",guest
1,Active Tickets,1250,IE7 DOMwalk empty styled paragraphs collapse,Browsers_InternetExplorer,trunk,0.97,defect,normal,None,new,2008-07-19T23:41:54Z+0000,2010-05-10T07:18:45Z+0000,"On the restricted demo page using IE7 (XP SP2), clear the xinha, type ""Foo"", hit Enter twice, type ""Bar"", hit Enter once.  Observe that the HTML for the blank line is <p>&nbsp;</p>, which is desireable and will be preserved when displayed.

Clear the xinha, turn on bold (or any style tag) and type as above.  Observe that the HTML for the blank line is <p><strong></strong></p>, which will be collapsed into nothing when displayed.

I worked around this by setting getHtmlMethod to TransformInnerHtml which produces <p><strong></strong>&nbsp;\n</p> for the blank line.  This preserves the extra space, which is at least usable for now.",guest
1,Active Tickets,1573,IE8 + doctype adds extra style attribute,Xinha Core,trunk,,defect,normal,gogo,new,2011-03-16T13:13:00Z+0000,2011-03-18T22:06:02Z+0000,"I noticed that a fresh Xinha implementation displays some odd behaviour.

When loading Xinha on the following element:

<textarea id=""textareaId"" name=""textareaId"" style=""width: 400px; height: 400px;"">
    	<a href=""/my/link.html"" id=""player"" style=""width: 200px; height: 200px;"">Link text</a>
    </textarea>


And then toggling the HTML source via the Xinha button, the html had been transformed into the following:

<a id=""player"" style=""player"" href=""/my/link.html"" style=""width: 200px; height: 200px"">Link text</a>

As you can see, an extra style attribute has been added with a value of the elements ID, effectively rendering the already present style attribute useless.

This behaviour is only present in IE8 when there is a doctype present. Remove the doctype and all works fine.


Works correctly in: IE6, IE7, FF3.5.8, IE8 (without doctype)\

Broken in: IE8 + doctype

Xinha version: Xinha 0.96.1 (2010-05-12)

Used code: Taken from http://trac.xinha.org/wiki/NewbieGuide (see attached file)",guest
1,Active Tickets,1581,IE9 Fix,Xinha Core,trunk,,defect,major,gogo,new,2011-09-30T19:02:02Z+0000,2012-06-16T02:04:27Z+0000,"XinHaCore.Js
{{{
1. approx line 1610
    function noselect(e) {
        if (e.tagName) {
            e.unselectable = ""on"";
        }
        if (e.childNodes) {
            var imax = e.childNodes.length;
            for (var i = 0; i < imax; i += 1) {
                if (e.tagName) {
                    noselect(e.childNodes[i]);
                }
            }
        }
    }
2.
approx Line 6284
  Xinha._stopEvent = function(ev)
  {
    if (ev.preventDefault)   { //add
        ev.preventDefault();
    }
    if (ev.stopPropagation){ //add
        ev.stopPropagation();
    }
  };
}}}",guest
1,Active Tickets,1607,Image folder contents deleted,Plugins,trunk,0.97,defect,major,None,new,2013-03-01T17:56:00Z+0000,2013-03-01T17:56:00Z+0000,"Dear Sir/Madam:
I hope all is well in your side.
I have use xinha to one of my project, from last 2 weeks the contents of the Image folder which is updated by the filemanager - Imagemanager is changing by some one I visit your website and as per Security Patch I did the necessary changes in the mentioned file but still the problem is same, I couldn't find how to stop the hacker from changing the picture (Images) from the images folder, if there is any update security patch or any other solution please let me know.

Thanks:
Mustafa Amiri",guest
1,Active Tickets,1380,Image Manager Window not closing in FF and .97 Beta,Xinha Core,trunk,0.97,defect,minor,gogo,new,2009-01-29T00:01:23Z+0000,2009-01-29T00:01:23Z+0000,"I am using the .97 beta and when I use the Image Manager pop-up window, after I click Ok or Cancel to complete my operation, the window whites out, but just stay. I can't close it, and finally have to just click on the parent window.
It does what I want to do, but won't close.
Also, in trying to test if just FF, I tried in IE 8 and can't even use the Image Manager at all.
I am using Firefox 3.05 on Mac OX X 10.5.6",guest
1,Active Tickets,1480,"In FF,moving anchors will create more anchor after swaping text to html",Plugins,trunk,0.97,defect,normal,None,new,2009-11-19T02:26:23Z+0000,2010-05-10T08:48:47Z+0000,"1.Insert an anchor.
2.Move it by mouse click and dragging.
3.Swap text to HTML mode, then back to text mode.
4.All above will make as many anchors as the times you moved the anchor. It looks like copy not just a move.

The test environment is FireFox3.5 and the Xinha on-line demo.
BTW, insert anchor doesn't work for IE7.(another ticket has already mentioned this)

(This is rain in the discussion forum, I can't log in the ticket system with that account. So these two system need different account?)",guest
1,Active Tickets,1601,Incorrect width calculations,Xinha Core,trunk,,defect,normal,gogo,new,2012-09-15T14:44:26Z+0000,2012-09-15T14:52:25Z+0000,"Tested on Google Chrome Version 21.0.1180.89 with Ubuntu 11.04 -- I haven't yet tested any other browsers.

 1. Load the `examples/simple_example.html` page in a browser
 1. Wait for Xinha to finish loading
 1. Press enter a few times, until the sample text is taller than its containing frame and a vertical scrollbar appears

The vertical scrollbar appears in the wrong place: it shows up about 10 pixels to the left of the right-hand side of the Xinha container, instead of being attached to the side of the container.

This is because Xinha's status bar is assigned a bigger width than it should get, but only after the iframe's width has been set.  The status bar's width ends up being wider than both the iframe and the `<table class=""htmlarea"">`.   This causes the table's width to be extended to contain the statusbar, but the iframe's width is not updated accordingly.  As a result, the iframe's width ends up being 10 pixels less than the (incorrect) width of the entire Xinha container so the vertical scrollbar looks like it's floating detached from the container.

A screenshot is attached.",ejucovy
1,Active Tickets,1253,iPhone support?,Browsers_Safari,trunk,Version 1.0,enhancement,normal,None,new,2008-07-23T21:59:40Z+0000,2008-11-18T17:26:32Z+0000,"Has anyone discussed the possibility of supporting the iPhone / iPod Touch yet? That would be extremely handy, and I think my company would put some developer time toward this goal if there's a likelihood of the changes being merged into the next release. Anyone have any advice or guidance?  Where would you start on a task like this?

Thanks!

Troy",guest
1,Active Tickets,1550,Issues with table operations,Plugins,trunk,Improved table support,defect,major,None,new,2010-10-20T14:59:32Z+0000,2010-11-18T16:55:29Z+0000,"Insert cell option

Click on ""insert cell after/before"" option, this results in new column creation on right hand side. One of its cell has the shifted value, rest of the cells are not usable. I am not able to have any content in them (attachment - unusable_cells)

Table layout when its not 100%

When table layout is not 100% and I continue to add more data, like list of points - the bullets merges with last column of the table. And its only visible when saved otherwise it appears to be okay.(attachment - list_table_merge)

Insert column

When I click on insert column, it does work but it inserts columns with very thin or invisible borders by default, particularly when there is big table with loads of content. At first I thought the button is not working at all until I spotted it in a smaller table.",guest
1,Active Tickets,1245,it' not possible to enter percent values to height or width attributes of images,Xinha Core,,0.97,defect,normal,gogo,new,2008-07-14T07:35:41Z+0000,2010-05-10T07:15:59Z+0000,"1) insert an image with the ""Insert/Modify Image"" button.

2) switch to the source view

3) add width and/or height attributes to the image tag with percent values e.g.:
<img src=""http://www.google.at/intl/de_at/images/logo.gif"" alt=""google test"" width=""50%"" />

4) swtich back to the wysiwyg view
5) again, switch to the source view

Now the with of the image is an absolute pixle value, in the above case something like:
<img width=""436"" alt=""google test"" src=""http://www.google.at/intl/de_at/images/logo.gif"" />

The Problem seems to be in the modules/GetHtml/DOMwalk.js file.
In this file the line
value = root[a.nodeName];
is used to read the value of the width value, and root[a.nodeName] returns the absolute pixle value.

value = a.nodeValue; would return the correct % value.",guest
1,Active Tickets,1494,Large Word 2007 Files locks IE 7/8,Xinha Core,trunk,0.97,defect,normal,gogo,new,2010-02-02T17:56:41Z+0000,2010-05-10T11:39:35Z+0000,When pasting the contents of a large (6000 word) Word 2007 document into IE 7/8 the cursor flickers for a while and IE locks up.,guest
1,Active Tickets,1432,Linker - Title issue,Plugins,trunk,0.97,defect,minor,None,new,2009-04-26T05:22:45Z+0000,2010-05-10T08:27:50Z+0000,"The linker does not implement correctly the title tag, I've made a fix for that modifying both pluginsMethods and dialog (find attachments)",guest
1,Active Tickets,1566,List behavior on Chrome is bad,Xinha Core,trunk,,defect,normal,gogo,new,2010-12-02T15:40:51Z+0000,2010-12-02T21:30:14Z+0000,"To reproduce, on http://www.xinha.org/xinha-nightly/examples/ExtendedDemo.html --

 1. Clear all the text from the editor, and press backspace until the path is just `body`.
 1. Type ""morx"" and press enter.  Now the path will be `body >> p`
 1. Click the ""bulleted list"" button.  Now the path will be `body >> p >> ul >> li >> span.Apple-style-span` -- huh?
 1. Now type ""fleem"" in the list item, and press enter again.
 1. The cursor will have exited the bulleted list entirely, and the path is now `body >> p >> p`.

There are three errors here.  Expected behavior:
 1. When the ""bulleted list"" button is clicked, the path should be `body >> ul >> li`.  Instead it is `body >> p >> ul >> li >> span.Apple-style-span` -- the list is incorrectly inside a `<P>`, and the text within a list item is incorrectly inside a `<span class=""Apple-style-span"">`.
 1. After enter is pressed, the cursor should be in an empty second list item.  Instead, the list is ended with one item.
 1. After the list is ended (which would normally mean pressing enter twice on an empty list item) the cursor should just be in a `<P>`.  Instead it's in a nested `<P><P>`.

I tried this in Firefox and it is working fine there, so this is probably a bug in the WebKit module.  I haven't tried it in Safari, Opera or IE yet.  So I'm going to file it in Xinha Core until it's confirmed that it doesn't affect Opera or IE.",ejucovy
1,Active Tickets,1360,Make automatic code indentation in source view mode configurable,Xinha Core,trunk,0.97,enhancement,normal,gogo,new,2008-12-19T20:16:34Z+0000,2008-12-19T20:16:34Z+0000,"It's been [http://www.xinha.org/punbb/viewtopic.php?id=1796 requested] that Xinha's automatic code indentation in source view mode be made optional. I propose that we add a new Xinha configuration variable, {{{indentMarkup}}} (with a default value of true), to make this possible.

Looking at the code, this seems like it should be pretty trivial. One complication I can see is that we'll need to make changes to the getHtml methods in both DOMwalk and TransformInnerHTML.

In [http://trac.xinha.org/browser/trunk/modules/GetHtml/TransformInnerHTML.js TransformInnerHTML], the relevant code is here:

{{{
html = Xinha.indent(html);
}}}

Commenting out the above should do the trick.

In [http://trac.xinha.org/browser/trunk/modules/GetHtml/DOMwalk.js DOMwalk], changing the following line to not increment {{{indent}}} solves half the problem:

{{{
html += Xinha.getHTMLWrapper(i, true, editor, indent + '  ');
}}}

...but DOMwalk will still insert newline characters all over the place, so a solution here will require a bit more thought.

Thoughts?",nicholasbs
1,Active Tickets,1168,New Plugin created - Media,Plugins,trunk,Version 1.0,enhancement,normal,None,new,2008-03-17T02:26:59Z+0000,2008-10-14T20:03:00Z+0000,"Hello,
I've been working on a new plug-in: 'Media'. The results of which can be seen (and downloaded) here:

http://www.jljsolutions.co.uk/xinha.html

Those of you who have used other wysiwyg editors may notice a similarity to another plug-in - this is what the 'open-source' community is about ;-), I didn't like to see xinha fall behind. I've adapted doublick and contextmenu to work with the new plug-in and these are bundled within the zip for download.  

Updates for this plug-in are on-going but this gives you an idea about what it does.

Hope it's some use. Would love to see it with standard bundles of xinha in the future? 

Cheers,
John",guest
1,Active Tickets,1283,New-dialogs version of TableOperations is incomplete,Plugins,trunk,0.97,defect,normal,,new,2008-10-01T21:49:17Z+0000,2010-05-10T07:19:54Z+0000,"I realized today that the version of the TableOperations plugin for new-dialogs is incomplete. Most notably, the settings from its various dialogs (e.g., Table Properties) do not get applied to the table. 

I've looked into the code a bit and discovered at least one of the issues: the dialog is constructed dynamically in part using the InlineStyler module. This means that when Xinha.Dialog.translateHtml creates its reverse ID index of all elements in the document, it does not actually get all of the form elements. This in turn means that dialog.hide() does not return values for some of the input elements, making it impossible for TableOperations to properly update the attributes.

Off the top of my head, I can think of a couple of ways to fix this:

1. Hard-code the dialog HTML instead of dynamically generating it

2. Add a method that updates Xinha.Dialog's reverse ID lookup index

I'm initially in favor of doing (2) but not strongly so, and I admit I haven't spent a lot of time thinking about this/looking at the code.

Thoughts? Ray, I believe you did the initial work on this plugin a while ago, how were you planning on tackling this?",nicholasbs
1,Active Tickets,1533,On-screen keyboard,User Interface,trunk,,enhancement,minor,None,new,2010-07-23T16:56:53Z+0000,2010-07-23T16:56:53Z+0000,"== Feature Request: ==
I'd like an on-screen keyboard to make it easier for my users to enter text in different languages which they may not have the characters of on their keyboard. I am proposing a button on the toolbar which brings up a dialog box with an on-screen keyboard and a drop-down where they can choose layouts / languages for it, and click on letters to input them. Right to left languages would be input correctly.

Thanks!

",guest
1,Active Tickets,1546,onMouseUp Event,Xinha Core,trunk,0.97,enhancement,normal,gogo,new,2010-09-18T07:49:30Z+0000,2010-10-09T16:28:09Z+0000,"pretty easy to add:

XinhaCore.js [5463]

  if ( ev.type == 'mouseup' )
  {
    if(editor.firePluginEvent('onMouseUp', ev))
    {
      return false;
    }
  }",adamj
1,Active Tickets,1334,Paste HTML command,Xinha Core,trunk,,enhancement,normal,gogo,new,2008-11-19T22:06:21Z+0000,2008-11-24T19:23:23Z+0000,"It would be nice to have a command/button to paste HTML.  This is HTML you'd typically get from some other service (e.g., flickr) that you want to paste in literally.  I imagine it opening up a dialog where you paste into a field, it does preview, and when you hit OK it goes into the editor.  On Firefox where you can't programmatically paste, so a dialog is necessary (arguably the dialog would be useful regardless, since it involves people pasting stuff they probably don't understand and the preview gives them a chance to see it first).

If #1331 is implemented, those transformations should also be applied to the paste on its way in. ",guest
1,Active Tickets,1495,Pasting text from Word is broken.,Xinha Core,trunk,0.97,defect,normal,gogo,new,2010-02-12T02:44:11Z+0000,2010-05-10T09:34:38Z+0000,"Create new word document and type some text. Select the typed text and paste it into the Xinha demo text area on your page:

http://xinha.raimundmeyer.de/x_examples/restricted.php

right after the text ""Write somethin' nice"".

You will notice that the text is pasted a line below your current position instead of the line your cursor is in (in Firefox 3.6). 

However, even worse after the text is pasted in the wrong line below, the cursor is now placed (it jumps) at the top of the text area. So if you continue typing like normal your would type somewhere completely unexpected.",guest
1,Active Tickets,1453,PATCH: InsertImage selection dropdown for inline attachments [Needs Work],Xinha Core,trunk,0.97,enhancement,normal,gogo,new,2009-07-20T08:25:37Z+0000,2009-11-08T03:48:11Z+0000,"From here: http://www.xinha.org/punbb/viewtopic.php?id=2251

Hello,

   Some software allows users to upload images as attachments to their posts. The uploaded attachments are usually accessible for viewing via a URL internally generated by the software, but unknown to the user. These attachments should be accessible from the InsertImage dialog so that users can place what they've uploaded inline.

   This patch creates the configuration option 'selectableImages'. This option allows xinha to be passed a list of attached image names and their internal attachment URLs so that they may be used inline during message posting. The creation of the selectableImages array is a task for the coder on the server side via Perl, Php, Python, etc.

   The default selectableImages array is empty. A sample array may look like:

{{{
xinha_config.selectableImages = [
  ['image_name01', 'image_url01'],
  ['image_name02', 'image_url02'],
];
}}}
I've been integrating Xinha into OpenWebMail and ran into this need.

Thanks,
Alex

P.S.- The file modules/InsertImage/insert_image.html is no longer used and is confusing to have laying around. It would be great if it could be removed.

{{{
Index: XinhaCore.js
===================================================================
--- XinhaCore.js	(revision 1190)
+++ XinhaCore.js	(working copy)
@@ -934,6 +934,18 @@
     [""separator"",""htmlmode"",""showhelp"",""about""]
   ];
 
+  /** This array provides a list of filenames and their corresponding URLs, so that those images may be chosen
+   *  via a selection dropdown menu in the InsertImage dialog module. This enables integration with email or blog
+   *  software where users have uploaded images accessable via special URLs provided by those softwares, but not
+   *  immediately apparent to the user. A sample array should look like [['image1','url1'],['image2','url2']].
+   * Default value:
+   *<pre>
+   *xinha_config.selectableImages = [];
+   *</pre>
+   * @type Array
+   */
+  this.selectableImages = [];
+
   /** The fontnames listed in the fontname dropdown
    * Default value:
    *<pre>
Index: modules/InsertImage/insert_image.js
===================================================================
--- modules/InsertImage/insert_image.js	(revision 1190)
+++ modules/InsertImage/insert_image.js	(working copy)
@@ -71,20 +71,47 @@
 	// Connect the OK and Cancel buttons
 	dialog.getElementById('ok').onclick = function() {self.apply();}
 
-	dialog.getElementById('cancel').onclick = function() { self.dialog.hide()};
+	dialog.getElementById('cancel').onclick = function() {
+          dialog.getElementById('f_selectable').options.selectedIndex = 0;
+          dialog.getElementById('f_url').value = '';
+          dialog.getElementById('ipreview').src = '';
+          self.dialog.hide();
+        }
 
-	dialog.getElementById('preview').onclick = function() { 
-	  var f_url = dialog.getElementById(""f_url"");
+	dialog.getElementById('f_selectable').onchange = function() {
+          var f_url = dialog.getElementById('f_url');
+
+          if (dialog.getElementById('f_selectable').options.selectedIndex > 0) {
+             var f_selectable = dialog.getElementById('f_selectable').options[dialog.getElementById('f_selectable').options.selectedIndex];
+             f_url.value = f_selectable.value;
+          } else {
+             f_url.value = '';
+             dialog.getElementById('ipreview').src = '';
+          }
+        }
+
+        // Populate the f_selectable selection list
+        for (var i=0; i<editor.config.selectableImages.length; i++) {
+          var text = editor.config.selectableImages[i][0];
+          var value = editor.config.selectableImages[i][1];
+          // preserve option 0 of the select list (the nothing selected option)
+          dialog.getElementById('f_selectable').options[i+1] = new Option(text, value);
+        }
+
+	dialog.getElementById('preview').onclick = function() {
+	  var f_url = dialog.getElementById('f_url');
 	  var url = f_url.value;
 
 	  if (!url) {
 	    alert(dialog._lc(""You must enter the URL""));
 	    f_url.focus();
-        return false;
-      }
-	  dialog.getElementById('ipreview').src = url;
+            return false;
+          }
+
+          dialog.getElementById('ipreview').src = url;
 	  return false;
 	}
+
 	this.dialog.onresize = function ()
   {
 		var newHeightForPreview = 
Index: modules/InsertImage/dialog.html
===================================================================
--- modules/InsertImage/dialog.html	(revision 1190)
+++ modules/InsertImage/dialog.html	(working copy)
@@ -5,6 +5,14 @@
   <tbody>
 
   <tr>
+    <td style=""width: 7em; text-align: right""><l10n>Attachments:</l10n></td>
+    <td>
+      <select size=""1"" name=""[f_selectable]"" id=""[f_selectable]"" style=""width:75%"" title=""_(Select an attached image here)"" />
+        <option value=""0""><l10n>-- no attachments are selected --</l10n></option>
+      </select>
+    </td>
+  </tr>
+  <tr>
     <td style=""width: 7em; text-align: right""><l10n>Image URL:</l10n></td>
     <td><input type=""text"" name=""[f_url]"" id=""[f_url]"" style=""width:75%""
       title=""_(Enter the image URL here)"" />
@@ -80,4 +88,4 @@
 <div class=""buttons"" id=""[buttons]"">
   <input type=""button"" id=""[ok]""     value=""_(OK)""     />
   <input type=""button"" id=""[cancel]"" value=""_(Cancel)"" />
-</div>
\ No newline at end of file
+</div>
}}}
",ray
1,Active Tickets,1328,PersistentStorage/PSLocal/PSServer/PSFixed Plugins [was: Update the ExtendedFileManager to use new dialogs...],Xinha Core,trunk,2.0,enhancement,normal,douglas,new,2008-11-18T22:14:24Z+0000,2010-05-10T07:23:37Z+0000,"The ExtendedFileManager, which is the replacement for the deprecated ImageManager, is very heavily tied to the UI, and the popup system.  It needs to be cleaned up / refactored /rewritten to use the new dialogs, and ideally updated to clean up the server protocol.",douglas
1,Active Tickets,1476,Plugin spellchecker find wrong words with french accents - Ticket #120 Continued,Xinha Core,trunk,2.0,defect,normal,gogo,new,2009-10-19T11:24:35Z+0000,2010-05-10T08:44:47Z+0000,"Hello, I'm using Xinha 0.95 with the SpellChecker plugin in a web based CMS called Bricolage. Bricolage uses UTF-8 as default encoding for all it's HTML pages. My Linux install has the UTF-8 set, too. 
When spellckecking Spanish texts, words get truncated before special characters (accented wovels mainly). I've noticed the same problem addressed in a previous ticket (#120). A solution was provided an implemented. The problem is that I still experience this problem with recent versions of Xinha. I've set the conversion to entities to ""false"", but the script still converts utf-characters to HTML-entities. I think the offending lines are in the if-block that applies the conversion in ""spell-check-logic.php"". The ""!isset($_REQUEST['utf8_to_entitis'])"" evaluates always to true, and the conversion is being carried out by default.",guest
1,Active Tickets,1412,plugins/ImageManager/Classes/Files.php,Plugins,trunk,2.0,enhancement,normal,None,new,2009-03-22T12:20:59Z+0000,2010-05-10T08:00:00Z+0000,This is an E_STRICT patch,guest
1,Active Tickets,1489,Portuguese Brazilian translation,Internationalization,trunk,Version 1.0,defect,normal,None,new,2009-12-30T20:48:59Z+0000,2009-12-30T21:08:46Z+0000,"Some fixes

'''/lang/pt_br.js.diff'''
{{{
--- http://svn.xinha.org/trunk/lang/pt_br.js	qua dez 30 18:31:25 2009
+++ /home/gabriel/xinha/lang/pt_br.js	qua dez 30 18:30:57 2009
@@ -57,7 +57,7 @@
   ""Current style"": ""Estilo Atual"",
   ""Cut selection"": ""Recortar seleção"",
   ""Developer"": ""Desenvolvedor"",
-  ""ENTER"": ""ENTRAR"",
+  ""ENTER"": ""ENTER"",
   ""Editor Help"": ""Ajuda do Editor"",
   ""Em"": ""Em"",
   ""Enter the image URL here"": ""Entre aqui com a URL da imagem"",
@@ -88,7 +88,7 @@
   ""Middle"": ""Meio"",
   ""Name"": ""Nome"",
   ""New window (_blank)"": ""Nova janela (_blank)"",
-  ""None (use implicit)"": ""Nenhum (uso implicito)"",
+  ""None (use implicit)"": ""Nenhum (uso implícito)"",
   ""Not set"": ""Não definido"",
   ""Number of columns"": ""Número de colunas"",
   ""Number of rows"": ""Número de linhas"",
@@ -107,7 +107,7 @@
   ""Rows:"": ""Linhas:"",
   ""SHIFT-ENTER"": ""SHIFT-ENTER"",
   ""Same frame (_self)"": ""Mesmo frame (_self)"",
-  ""Select Color"": ""Selecionar côr"",
+  ""Select Color"": ""Selecionar cor"",
   ""Select all"": ""Selecionar tudo"",
   ""Set format to paragraph"": ""Definir formato para o parágrafo"",
   ""Space between adjacent cells"": ""Espaço entre células adjacentes"",
@@ -129,20 +129,20 @@
   ""Version"": ""Versão"",
   ""Vertical padding"": ""Espaçamento interno vertical"",
   ""Vertical:"": ""Vertical:"",
-  ""Width of the table"": ""Larguran da tabela"",
+  ""Width of the table"": ""Largura da tabela"",
   ""Width unit"": ""Unidade de largura"",
   ""Width:"": ""Largura:"",
   ""Would you like to clear font colours?"": ""Deseja limpar as cores de fonte"",
   ""Would you like to clear font sizes?"": ""Deseja limpar os tamanhos de fonte"",
   ""Would you like to clear font typefaces?"": ""Deseja limpar os tipos de fonte"",
   ""Xinha Help"": ""Ajuda do Xinha"",
-  ""You are in TEXT MODE.  Use the [<>] button to switch back to WYSIWYG."": ""Você está no MODO TEXTO.  Use o botão [<>] para mudar para o modo de Visualização (WYSIWYG)"",
+  ""You are in TEXT MODE.  Use the [<>] button to switch back to WYSIWYG."": ""Você está no MODO TEXTO.  Use o botão [<>] para mudar para o MODO VISUAL (WYSIWYG)"",
   ""Your Document is not well formed. Check JavaScript console for details."": ""Seu Documento não está formatado corretamente. Verifique o console do JavaScript para maiores detalhes."",
   ""insert linebreak"": ""inserir quebra de linha"",
   ""new paragraph"": ""novo parágrafo"",
-  
+
   // not find with lc_parse_strings.php
-  ""Subscript"": ""Subescrito"",
+  ""Subscript"": ""Subscrito"",
   ""Superscript"": ""Sobrescrito"",
   ""Direction left to right"": ""Da esquerda para direita"",
   ""Direction right to left"": ""Da direita para esquerda"",

}}}

Regards,
Gabriel D. Oliveira",guest
1,Active Tickets,1391,PreserveScripts doesn't correctly handle php in html tags,Plugins,trunk,0.97,defect,normal,None,new,2009-02-13T00:42:14Z+0000,2010-09-17T15:31:16Z+0000,"php can appear in html tags like this:

<input value=""<?php print $foo;?>"">

if u paste this into code view and then toggle html/ code - it comes back as:

<input src=""/xinha-nightly/plugins/PreserveScripts/php.png"" id=""PreserveScripts_1"" value=""&lt;img title="" />&quot;&gt;

AdamJ",Adam J
1,Active Tickets,1603,problem with automatic javascript code remove from textarea,Xinha Core,trunk,,defect,normal,gogo,new,2012-09-26T18:38:01Z+0000,2012-09-26T18:38:01Z+0000,"Hi 
i use xinha for a long time and work well, i m fan of it ! ;)
but i have a problem, i ll like to have the possibility to insert some javascript in the textarea , but the code is automaticly remove!??
for instance: i click on the ""html source code"" button, i paste this code just for test:
<script type=""text/javascript"" id="""">
</script>
and after i click again on the ""html source code"" button to return to edit section and without do anything else i just look again the source code and my javascript code is full remove!?
but if i do the test on xinha html demo, it is not remove?
how is it possible that xinha don't remove the javascript code insert in the source code from the textarea?
my url test page : http://www.mathieuweb.fr/test/
Thanks ",guest
1,Active Tickets,1587,prototype.fixRelativeLinks causing a JSfault when the url is like example.com/folder/../folder2/image.png,Xinha Core,trunk,,defect,major,gogo,new,2011-10-20T01:11:01Z+0000,2011-10-20T01:11:01Z+0000,"{{{
Uncaught exception: TypeError: Cannot convert 'base_m' to object 
 Error thrown at
}}}
http://trac.xinha.org/browser/trunk/XinhaCore.js#L5924



CheckedPath: http://www.example.com/folder/../folder2/image.png [[BR]]
localPath (where editor is right now): https://www.domain.tld/page.php 
[[BR]]
{{{
# base_m = b.match( relPath );
b = https://www.domain.tld/page.php
relPath = [RegExp] = new RegExp( ""(.*?)(([^\/]*\/){""+ url_m.length+""})[^\/]*$"" );

# url = src[i].match(/(src|href)=""([^""]*)""/i); 
>>> url[0] 
 ""src=""http://www.example.com/folder/../folder2/image.png"""" 
>>> url[1] 
 ""src"" 
>>> url[2] 
 ""http://www.example.com/folder/../folder2/image.png"" 
>>> url[3] 
 undefined

# url_m = url[2].match( /\.\.\//g );
>>> url_m[0] 
 ""../"" 
>>> url_m[1] 
 undefined
}}}


'''tl;dr;'''[[BR]]
local url mixed with remote url?",guest
1,Active Tickets,1547,Remove border around toolbar buttons,Xinha Core,trunk,0.97,defect,normal,gogo,new,2010-09-22T15:07:39Z+0000,2010-09-23T19:31:12Z+0000,"In FF4Beta there is a border around the toolar buttons.

[[Image(http://dev.shiftcreate.com/xinha/toolbar.gif)]]

This can be removed by adding this to Xinha.css:


{{{
td.toolbarElement{
    border:0;   
}
}}}

",adamj
1,Active Tickets,1279,Replace ereg* functions with preg* in php code,Plugins,trunk,Version 1.0,enhancement,normal,None,new,2008-09-26T11:31:03Z+0000,2008-09-26T11:31:03Z+0000,"Because the ereg extension of PHP will be moved to PECL in PHP 6, I think it is wise to replace the ereg* functions with preg* equivalents in the PHP code of some plugins. 

ereg* functions are used in the following plugins (and files).

ImageManager:
Classes/NetPBM.php ,
Classes/Transform.php

SpellChecker:
spell-check-logic.php

SuperClean: 
tidy.php 

See also: 
http://www.php.net/~derick/meeting-notes.html#move-ereg-to-pecl
and
http://bitfilm.net/2007/12/09/unofficial-php-6-changelog/

I am using version 0.95 of Xinha.",guest
1,Active Tickets,1544,retain selection between modes,Xinha Core,trunk,,enhancement,normal,gogo,reopened,2010-09-12T21:14:01Z+0000,2010-10-09T16:27:08Z+0000,"similar to #900 but this would also retain cursor selection instead of just cursor position when toggling between modes.

Adam J",Adam J
1,Active Tickets,1597,Safari 5.1.6 Webkit insertNodeAtSelection,Xinha Core,trunk,,defect,normal,gogo,new,2012-07-30T13:08:16Z+0000,2012-09-17T02:26:54Z+0000,"Within the WebKit.js, the selection process for the object passed to insertNodeAtSelection at line 420 is always of node type DOCUMENT and not ELEMENT:

Xinha.prototype.getSelection = function()
{
  return this._iframe.contentWindow.getSelection();
};

Therefore when switching on the node.NodeType on line 430, none of the cases are met and the text is just deleted and not replaced with underlined text.",guest
1,Active Tickets,1420,Saveas button does not function in .96,Plugins,trunk,0.97,defect,normal,None,new,2009-03-28T12:23:11Z+0000,2010-05-10T08:13:32Z+0000,"This is easily seen by comparing the demo examples, the newest one does not show a saveas button correctly and does not function when you click on it. 
This only applies to IE as this button is not used in other browsers I think.",guest
1,Active Tickets,1361,SaveSubmit saving message does not show up in fullscreen mode,Plugins,trunk,0.97,defect,normal,,new,2008-12-19T23:53:11Z+0000,2008-12-19T23:55:11Z+0000,"After clicking the ""Save"" button provided by [wiki:Plugins/SaveSubmit SaveSubmit], Xinha typically displays a status messaging while it saves. However, when in fullscreen mode, this message does not appear. I can't find any note that this is the intended behavior, so I assume this is a bug.

Thanks to sigmounte on IRC for catching this!",nicholasbs
1,Active Tickets,1529,Security Issues in XINHA WYSIWYG 0.96.1,Xinha Core,trunk,0.97,defect,normal,gogo,new,2010-07-13T17:45:42Z+0000,2010-11-24T23:02:47Z+0000,"Hello there,

we at MajorSecurity found some security related vulnerabilities within XINHA WYSIWYG Editor. Please tell me the email address I should send the security related details to. 

You may contact me at: david.kurz[(at)]majorsecurity[(dot)]net

Best regards,

David Vieira-Kurz
Head of Security Research, MajorSecurity",guest
1,Active Tickets,1572,Select text with different font sizes does not set font-size combo box to a state indicating different font sizes,User Interface,trunk,,defect,normal,None,new,2011-03-14T14:01:07Z+0000,2011-03-14T14:01:07Z+0000,"Pre-Condition:
Two words, each with a different font size.

Approach:
Selecting both words

Expected:
Font-size combo box defaults to ""--size--"" (indicates that different font sizes are present in the current selection)

Current behaviour:
Font-size combo box is set to the lowest of both font-sizes.",guest
1,Active Tickets,1167,"Selection problem in Safari 3 prevents display of table, row and cell props dialogs",Browsers_Safari,trunk,0.97,defect,normal,None,reopened,2008-03-14T15:13:20Z+0000,2010-05-11T08:59:09Z+0000,"If you use the nightly build demo on xinha.org, enable TableOperations and ContextMenu, create a table, then right click in a table cell, selecting table, row or cell properties, you get an empty dialog window.",guest
1,Active Tickets,1602,Setting editor.config.Events after makeEditors has no effect,Xinha Core,trunk,,defect,normal,gogo,new,2012-09-17T14:39:13Z+0000,2012-09-17T14:39:13Z+0000,"The example configuration script in source:trunk/examples/XinhaConfig.js describes that you can adjust an editor's configuration values between calls to `makeEditors()` and `startEditors()`:

{{{
	  xinha_editors   = Xinha.makeEditors(xinha_editors, xinha_config, xinha_plugins);
	
	  /** STEP 5 ***************************************************************
	   * If you want to change the configuration variables of any of the
	   * editors,  this is the place to do that, for example you might want to
	   * change the width and height of one of the editors, like this...
	   *
	   *   xinha_editors.myTextArea.config.width  = '640px';
	   *   xinha_editors.myTextArea.config.height = '480px';
	   *
	   ************************************************************************/
	
	
	  /** STEP 6 ***************************************************************
	   * Finally we ""start"" the editors, this turns the textareas into
	   * Xinha editors.
	   ************************************************************************/
	
	  Xinha.startEditors(xinha_editors);
}}}

This mostly works; however, I've noticed that if you try to set the `config.Events` object at this stage, like so, it has no effect:

{{{
xinha_editors   = Xinha.makeEditors(xinha_editors, xinha_config, xinha_plugins);
xinha_editors.myTextArea.config.Events = {'onBeforeSubmit': function() { alert(""foo""); };
Xinha.startEditors(xinha_editors);
}}}

On the other hand, updating sub-objects of the existing `config.Events` object does work properly:

{{{
xinha_editors   = Xinha.makeEditors(xinha_editors, xinha_config, xinha_plugins);
xinha_editors.myTextArea.config.Events.onBeforeSubmit = function() { alert(""foo""); };
Xinha.startEditors(xinha_editors);
}}}

This should probably be documented; and possibly fixed, or an explanatory error/warning triggered.",ejucovy
1,Active Tickets,1358,SmartReplace panel shows in view source mode,Plugins,trunk,0.97,defect,minor,,new,2008-12-18T20:59:33Z+0000,2008-12-18T20:59:33Z+0000,"The SmartReplace Settings panel does not get hidden when switching to source view.

See Stylist for an example of a plugin that does hide its panel when switching modes.",nicholasbs
1,Active Tickets,684,SpellChecker messing with my images,Plugin_SpellChecker,,,defect,major,gogo,new,2006-02-16T21:40:49Z+0000,2009-11-08T08:14:33Z+0000,"I got the spellchecker installed and working however there are some quirks I don't know how to fix.

1) It finds the forced space &nbsp to be a misspelled word.  And I cannot add it to the dictionary

2) Image files get very messed up by, for some reason, automatically changing <img to <span class=  then it starts changng the quotes and such. ",anonymous
1,Active Tickets,1589,Strange issue with the string 'graph' in the body of a xinha enabled text area,Xinha Core,trunk,,defect,normal,gogo,new,2011-11-29T15:52:34Z+0000,2012-02-15T07:19:38Z+0000,"I have implemented the Xinha editor in a number of projects over many years and never noticed this issue before (that doesn't necessarily mean it wasn't there).  In an instance where I have multiple editors on one page, if the text 'graph' is included anywhere in any of the editors (either on it's own or as part of another word such as 'photographic'), the currently enabled editor fails to load and I get a javascript error on the page as follows:

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152)
Timestamp: Tue, 29 Nov 2011 15:30:37 UTC

Message: 'parentNode' is null or not an object
Line: 2635
Char: 3
Code: 0

If I remove or modify the text, everything works fine!! I have given this as a temporary workaround at the moment but, as you can understand, replacing ""Graph"" with ""Chart"" is much more acceptable than replacing ""photographic"" with ""photografic""....

Unfortunately, I don't have any time at the moment to investigate further but thought it worthwhile to just raise here in case anyone has come across this or if it rings any bells with those of you that maintain or add to Xinha.  I have searched the site without success.

When I get more time to investigate, if I find a resolution/root cause, i'll post an update here.  ",guest
1,Active Tickets,1341,Stylist produces bad markup and leaves a trail of empty tags,Plugins,trunk,Version 1.0,defect,normal,,new,2008-11-25T22:19:05Z+0000,2008-11-25T22:19:05Z+0000,"Select a few words and apply a style. Then (additionally) select a few more adjacent words and apply the same style. Ideally, this would apply the style just once, as Stylist would be smart enough to combine elements, remove redundant or unnecessary markup, etc.

For example, Stylist produces the following code (FF3) after applying the ""bluetext"" style to the selection ""This is"" and then applying the same style to the entire string ""This is a test""

{{{
<span class=""bluetext""></span><span class=""bluetext""><span class=""bluetext"">This is</span> a test</span>
}}}

It would be much nicer if Stylist simply produced this:

{{{
<span class=""bluetext"">This is a test</span>
}}}
Not sure how much of this is browser-dependent.",nicholasbs
1,Active Tickets,1511,SuperClean and word comments,Plugins,trunk,0.97,defect,normal,None,new,2010-03-24T11:11:36Z+0000,2010-05-10T11:52:13Z+0000,"Using Xinha 0.95, the super clean plugin updated to the latest from the site.

The following sequence of HTML comments that come from a copy/paste from MS Word are not cleaned up by SuperClean, although as I read the regex in word.js, it should. 

<!--[if !supportEmptyParas]--> <!--[endif]-->
",guest
1,Active Tickets,1163,TableOperations breaks if tables have a TH,Xinha Core,trunk,Improved table support,enhancement,normal,gogo,new,2008-02-28T06:55:55Z+0000,2009-11-08T08:59:12Z+0000,"When the TableOperations plugin performs an operation on a column or row, it is only coded to expect that every cell is a td. If a cell is a TH, it breaks the table and the user must undo and view source and perfom the table edit without the WYSIWYG.

This is different from ticket #640, which really is for the insertTable module to support creating tables with header rows and columns. This ticket relates to the granular problem that once a table with headers is in Xinha, Xinha cannot perform normal table operations on it. Such a table could already have been pasted, generated in Dreamweaver or Contribute, or created in Xinha with a modified insertTable function as described in #640. ",mharrisonline
1,Active Tickets,1560,TableOperations: define a dblclickList action for tables,Plugins,trunk,0.97,enhancement,normal,,reopened,2010-11-18T00:25:25Z+0000,2010-11-18T21:53:16Z+0000,"The !TableOperations plugin could define a `dblclickList` action for `table` (or maybe `td`, I'm not sure which would be better) which would open up its ""edit table properties"" dialog.

(Original discussion for this feature was at http://trac.xinha.org/ticket/1555#comment:7 and following comments)",ejucovy
1,Active Tickets,1540,TableOperations: Resize Handles Disappear,Plugins,trunk,,defect,normal,None,new,2010-08-23T21:41:09Z+0000,2010-08-28T21:34:56Z+0000,"Steps to Reproduce:

1. Create a table

2. Resize table with handles

Actual Results:
Handles disappear and do not re-appear until you click outside the table and then on the table once again. This is confusing for users!

Expected Results:
When the table is selected, or the cursor is inside the table, the handles are displayed and work.

Reproduced on FF PC/Mac and IE",guest
1,Active Tickets,1606,Text area always disabled,Xinha Core,trunk,,defect,normal,gogo,new,2013-02-28T03:29:41Z+0000,2013-02-28T03:37:19Z+0000,"Hi,
I have a xinha editor in a jquery dialog box and I can't write in the text area. Normaly just resizing the editor fix the problem but not this time. What's odd is the I can add pictures throught the images manager. I've use the bowser consol for debug and when I use the setHTML methode to feed some stuff in the editor, it doesn't show my input. I can get back what I've set in it with getHTML so I know it's there somewhere. Only if I use insertHTML will it show what I've wrote. Yet I still can't click on it to edit the thing through the editor.",guest
1,Active Tickets,1596,"TransformerInnerHTML.js hangs browser in raw image data ""img"" tag",Xinha Core,,,defect,normal,gogo,new,2012-07-04T14:18:18Z+0000,2012-09-17T02:27:16Z+0000,"I am using Xinha to allow rich text editing in my web application. When the editor component gets an ""img"" tag with raw base64 encoded image data in it (see template file for html img data that cause the problem) the TransformerInnerHTML.js script hangs on the ""cleanHTML"" method. Probably the regular expression match and replace takes too long for these type of use cases. Problem is reproducible in Xinha 0.95. I haven't tried other Xinha versions.",guest
1,Active Tickets,1568,TransformInnerHTML.js replace error,Xinha Core,trunk,,defect,normal,gogo,new,2010-12-17T13:21:14Z+0000,2010-12-17T13:23:14Z+0000,"Xinha happens to sometimes transform code of the form
{{{href=""http://some.url.com/?par=F%FCr%20mich""}}}
to 
{{{$1http://some.url.com/?par=F%FCr%20mich""}}}
(seen in current Firefox)

I discovered that this can be fixed by replacing this:[[BR]]
before: {{{'$1'}}}[[BR]]
after:  {{{ RegExp.$1}}}[[BR]]
(appears 2times in TransformInnerHTML.js)",guest
1,Active Tickets,1584,Turkish Translation,Xinha Core,trunk,,enhancement,normal,gogo,new,2011-10-06T09:51:20Z+0000,2011-10-06T09:51:20Z+0000,"Hey there,

we have a turkish translation of Xinha plus 7 modules/plugins here. Interested? Its very hard to contribute though - took me 20 minutes to find out how to write this ticket as guest - I found no way to register for a normal user account, the link to the mailinglist admin page is dead, as are all the links on the http://trac.xinha.org/wiki/Tickets, and so on.... :-/
I am not sure how the prefered way of contribution is, so i just attach the tarball containing (also) the tr.js files here...",guest
1,Active Tickets,1571,Use of current font size in lists (bullets / numbers),Xinha Core,trunk,,enhancement,normal,gogo,new,2011-03-14T12:07:18Z+0000,2011-03-14T12:07:18Z+0000,"If I create an ordered or unordered list inside the Xinha editor and I change the font-size of the text inside this list, the text of the items grows as expected but the size of the bullets (unordered list) resp. numbers (orders list) stays the same.

Expected behaviour: The size of the bullets/numbers grows accordingly",guest
1,Active Tickets,1531,Use PasteText plugin automatically for all pastes?,HTML Output,trunk,,task,normal,None,new,2010-07-20T18:58:48Z+0000,2010-07-20T18:58:48Z+0000,"Hello
I was wondering if there is a way to have all items that are pasted into Xinha to paste as plain text? My client uses the PasteText plugin, but often they forget to tell interns to do this, making the formatting on the website look very inconsistent at times.

Also, can I disable/hide the font type and font size buttons? it would help them stay within the stylesheet. thanks!",guest
1,Active Tickets,1493,Word clean doesn't remove Word 2007 garbage,Xinha Core,trunk,0.97,defect,normal,gogo,new,2010-02-02T17:52:02Z+0000,2010-05-10T11:39:11Z+0000,"Word clean doesn't remove header garbage. See attached document.

mso 9 tags inside HTML comments can lead to page HTML being commented out.

See Ticket #1290 for similar Word 2003 issue.

Browser: FF 3
",guest
1,Active Tickets,1582,Wrong dialog size of ImageManager in FF7,Dialogs,trunk,,defect,normal,None,new,2011-10-04T18:22:35Z+0000,2011-10-06T19:18:44Z+0000,The modal dialogues of the plugins ImageManager and ExtendedFileManager has the wrong size after showing. This error occurs only with FF7.,guest
1,Active Tickets,1365,WYSIWYG view of font face and size selections,Plugins,trunk,0.97,enhancement,normal,None,new,2008-12-24T16:30:59Z+0000,2008-12-29T19:30:27Z+0000,"Xinha is the most powerful editor available, but one capability that other high end editors have (and have had for quite some time now) that Xinha lacks is the ability for fonts to be selected with a preview of what they look like, and sizes to show what size they are.

Mozilla makes it possible to show font styling in a dropdown, IE does not. This is typically done on a layer. It can greatly reduce toolbar real estate that is being used, and today is an expected capability.

I think this is something that would be best done as a plugin.

Thanks!",guest
1,Active Tickets,1342,Xinha config autofocus setting does not work in Firefox 2,Browsers_Firefox,trunk,0.97,defect,normal,,new,2008-11-26T16:54:04Z+0000,2008-11-26T16:54:04Z+0000,"autofocus works correctly in IE7, FF3, and Safari 3, but not FF2. In FF2, the editor appears to be activated automatically, but it's not possible to actually type anything (this can be bypassed by activating and then deactivating fullscreen mode).",nicholasbs
1,Active Tickets,1513,Xinha inserts <br /> after empty <div>,HTML Output,trunk,0.97,defect,normal,None,new,2010-04-20T14:57:51Z+0000,2010-05-10T09:50:40Z+0000,"When editing a page in Xinha I find that a "" <br />"" gets inserted after an empty <div>

I have created a test page on my domain at [http://stu.ie/xinhatest/xinhatest.html]

If you enter source mode and go to the line with the #slideshow <div> you will see "" <br />"" after the closing div tag. If you delete that <br /> and then go back to WYSIWYG, then back to source, you will see that the <br /> has been re-created.

This happens if I remove the space between the </div> and the </td>, AND if I use a self-closing <div />.

I can prevent this from happening by putting some content (&nbsp;) in the #slideshow <div> but that's not really a great solution...

I'm struggling to find the cause of this weirdness, and haven't noticed it before now. I have searched tickets and Google for this issue but cannot find mention of it.

I can reached by email at stuart.gilbert @ gmail.com if any more information is required, or if there's a known fix for this issue.

Regards,
Stuart.",guest
1,Active Tickets,1199,Xinha resizable (beta),Xinha Core,trunk,0.97,enhancement,normal,gogo,new,2008-04-25T00:23:10Z+0000,2008-11-26T15:39:23Z+0000,"Hello,
please visit http://www.jljsolutions.co.uk/xinha.html to see my experiments at making xinha resizeable. Works in IE6/7 FF and Safari as far as I know.

Just a demo for possible future inclusion(?). 

Cheers,
John

",guest
1,Active Tickets,1608,zen coding,Plugins,trunk,,enhancement,normal,None,new,2013-05-12T14:49:05Z+0000,2013-05-12T14:49:05Z+0000,"what about the integration of the zen coding plugin?
http://code.google.com/p/zen-coding/",guest
