Task HTML editor is stuck some times

[Trim]

While trying to resolve issue #5 , we reached multiple different issues.

Most have been able to be fixed, but one remains. To be more clear about the current status (4.00beta3) of releases, I open a new issue here.

As mentioned before, I've made some tries to fix this one, but I'm not able to resolve it and I think I've reached the point where I have not enough knowledge on Javascript and XUL technologies to be able to understand and fix the issue.

Note, that as I never used before the exchangecalendar task editors, I don't know the previous state of this element: does it was full working, does it had already some bugs ?

Current issue description

Exchangecalendar task editor provides a HTML text editor based on the <editor> XUL element.

I've found on the web that Mozilla don't provide a simple HTML editor directly but requires every project needing this to create themself a binding between the text area (the editor) and required buttons (like bold, italic, ...).

So, the exchangecalendar plugin does the right thing by defining itself a <exchWebServiceEditor> XBL element which contains the required editor text area, toolbar and the JavaScript bindings between them.

The issue is that, sometimes, the HTML editor is stuck in an unusable state: italic, bold and underlined buttons are stuck in an active state and the textarea is unable to be selected:

For me, it doesn't always appear, but for @smvicente it appears 98% of the time.

What I've discovered is that this state correspond to an exception raised when a click event happens. The exception is raised when the JavaScript code try to create an instance (in the XUL world) of nsICommandParams to read some button state.

The strange part is that it works well for say 5 buttons, but it fails on the ol_command button. I've tried to try/catch this exception to allow the code continues its execution, but then it failed with another instantiation creation in other part of the code.

Some tries / suggestion which didn't work

As suggested by @advancigu it can be an error of general initialization of the editor as it apperas only some times and on some basic XUL feature.

I've tried to get rid of <constructor> and <destructor> of the XBL element, but it seems to not work correctly if event handlers aren't loaded on XBL constructor phase.

Now I remember that this issue appeared after I've fixed another issue in the HTML editor: before I work on this code, the task editor reached an XML exception because the task editor dialog tried to insert badly formed HTML content inside the HTML editor. To fix this issue, I took the decision to modify the content setter to force the content to be inserted to be fixed by the Mozilla DOM parser. So, I think there is two options: either this fix caused the new issue, or this issue have always existed but wasn't reachable because of the XML parsing issue.

[smvicente]

Thank you for all the effort once again @Trim !

After trying out the beta3 going to describe better what I see, just in case it helps.

So, some times, the task description content is displayed correctly and I can update it without a hassle but, most of the times, when opening the tasks, I get to see the content briefly, but gets overwritten by a blank page immediately. If I don't hit save when that happens is ok and nothing changes, but if I save it, it will be get overwritten by the "blank" page, erasing any previous content.

When the HTML editor gets blocked, the fact that I get to see the task's content briefly, makes me think could be related to some race condition, but of course I'm just guessing, as I have no idea about the internals :(

In any case, I'm very grateful with you for fixing most of the problems!

Best.

PS: I have the feeling this happens more frequently when the task to edit has a big text inside, and less frequently with the smallest ones, but can't be 100% sure of that...

[advancingu]

@rkent Do you know anyone in the Thunderbird or Lightning teams who could help us troubleshoot?

[rkent]

No, I can't suggest anyone.

[Trim]

Well, I found a really good hint inside the book Rapid Application Development with Mozilla by Nigel McFarlane (available in a comment of this article).

In XBL chapter, I've noticed this paragraph:

15.2.1 Bound Tags and -moz-binding

Most, but not all, XUL and HTML tags can be bound to an XBL binding. For a
tag to be bound, it must have a frame—a styleable rectangular area in which
it is displayed.
Any tag with this style has no frame and cannot be bound:

{ display: none; }

A tag that gains this style will lose any binding that it has. For this rea-
son, a bound XUL tag should be collapsed rather than hidden if it needs to be
visually suppressed.

I've checked modifications I've made when porting the item dialog to the new iframe style and I've found I setted by default hidden=false inside the XUL definition and that wasn't the case before.

So I've updated the XUL and the JavaScript code to use the collapsed attribute instead.

It seems to work for me now, but I suggest to do a new beta with my todays pull requests (one is coming) to have more tests.

[smvicente]

@Trim ! that sounds great!! I can test it in the moment the new beta is released of course!

[advancingu]

Should be fixed now.

[smvicente]

Hi guys! there is no release available yet to test this out right?

Thanks a million.

[smvicente]

Hi guys! there is no release available yet to test this out right?

Thanks a million.

[smvicente]

Guys! Can confirm this issue is well fixed!

I'm not sure how to thank you for all the effort. Please let me know where I can donate.