{5} Assigned, Active Tickets by Owner (Full Description) (4 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

mokhet (1 match)

Ticket Summary Component Milestone Type Severity Created
Description
#658 enhanced IE event handling Xinha Core 0.96 enhancement normal 01/19/06

For every events we want to manipulate, we always have to check if HTMLArea.is_ie or not to take the correct event object. (by the way, it may be better to do ev?ev:window.event instead of is_ie?window.event:ev, but that's not the point here)

I think we could simulate the DOM behavior for IE if we change a little bit the function _addEvent as following 

HTMLArea._addEvent = function(el, evname, func)
{
  el['xinha_evt' + evname + func] = function() { func(window.event); }
  el.attachEvent("on" + evname, el['xinha_evt' + evname + func]);
  HTMLArea._eventFlushers.push([el, evname, el['xinha_evt' + evname + func]]);
};
HTMLArea._removeEvent = function(el, evname, func)
{
  el.detachEvent("on" + evname, el['xinha_evt' + evname + func]);
  el['xinha_evt' + evname + func] = null;
};

This way, i think we would never have to check if we have the event object or not. Here is a sample of what we have to do, checking if is_ie to get the correct object : 

HTMLArea._addEvent(el, "mousedown", function (ev) {
  if (obj.enabled) with (HTMLArea) {
    _addClass(el, "buttonActive");
    _removeClass(el, "buttonPressed");
    _stopEvent(is_ie ? window.event : ev);
  }
});

but simply 

HTMLArea._addEvent(el, "mousedown", function (ev) {
  if (obj.enabled) with (HTMLArea) {
    _addClass(el, "buttonActive");
    _removeClass(el, "buttonPressed");
    _stopEvent(ev); // <--- MODIFICATION HERE, NO TEST, WE KNOW WE HAVE OUR EVENT
  }
});

This way, the event object will always be correctly populated if we are IE or not and we will not have to ponder again about this boring crossbrowser stuff inside Xinha events.

I dont have tested it yet but as you may have noticed i'm actually focused on reducing the maximum of tests inside xinha i can, and i think this one can be a good one. What do you think ?

nicholasbs (2 matches)

Ticket Summary Component Milestone Type Severity Created
Description
#1259 Editor still active when dialog is open (new-dialogs branch) User Interface 0.96 defect normal 08/12/08

To reproduce:

1) Click insert image (or any other plugin that has been converted to the new dialog system)
2) Tab through the form elements. If you tab enough times you'll end up back in the editor field and can type whatever you like as well as use editor controls (e.g., the font popup menu).

This is almost certainly not the desired behavior, as it seems odd that users should be able to tab out of the dialog.

This happens in both Firefox 3.0.1 and Safari 3.1.2 on Mac OS X 10.5.4.

#1264 Lightboxes should close when user presses ESC User Interface 0.96 enhancement normal 08/14/08

It's pretty standard that lightboxes (i.e., dialogs like the ones in the new-dialogs branch) close when the user presses the escape key. This should be a configurable option that can be set globally.

paulb (1 match)

Ticket Summary Component Milestone Type Severity Created
Description
#349 Paste support for Firefox! Xinha Core Version 1.0 defect normal 06/17/05

FCKEditor has a brilliant solution to the paste problem on firefox: popup a window and allow the user to paste into it. I've shamelessly stolen their code and implemented a WordPaste? plugin. It will remove all of MSWord's junk and then some (it may remove too much for general use - feel free to make changes). I've attached the plugin code, and there is one modification required in htmlarea.js:

line 3479: 

  case "cut":
  case "copy":
  case "paste":
    try {
      this._doc.execCommand(cmdID, UI, param);
    } catch (e) { }
    if (this.config.killWordOnPaste) {
      if(typeof WordPaste == 'undefined')
      {
        HTMLArea.loadPlugin("WordPaste", function() { editor.generate(); } );
        editor.registerPlugin('WordPaste');
      }
      editor.plugins['WordPaste'].instance._buttonPress(null, null);
    }
    break;

I'm not sure if all of that is necessary, I just copied how it was done in another part of the program and it seemed to work.

Also, when you load your editor, you must enable the "WordPaste?" plugin.

This is solving two problems at once: pasting from FireFox?, and MSWord clean. Probably most people will want to configure these things individually, and so this code will have to be modified to accommodate that.

Note: See TracReports for help on using and creating reports.