Xinha Discussion Forum

anzenews

Xinha Community Member

Registered: 2005-02-21

Posts: 41

Text formatting not always there

Hi!

Sometimes when I fire up a page in FireFox 1.0 (Linux) I get a Xinha-area that uses wrong formatting (not the one that I supply through config.pageStyleSheets). If I try to apply some formatting (justify center, formatblock,...) I get this error:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.execCommand]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://localhost/xinha/htmlarea.js :: anonymous :: line 3005" data:no]
by execCommand(justifycenter)

If I refresh the page everything is back to normal again (sometimes - not always).

Line 3005:
default: try { this._doc.execCommand(cmdID, UI, param); }
  catch(e) { if (this.config.debug) { alert(e + "\n\nby execCommand(" + cmdID + ");"); } }

I can turn config.debug off (which gets rid of the message) but formatting doesn't work.

Does anyone else have this problem? Any ideas what is causing this? To me it looks like _doc is not valid - but how is this possible and what should I do to fix this?

Any help would be appreciated.

Anze

gogo

Xinha Leader

From: New Zealand

Registered: 2005-02-11

Posts: 1,015

Website

Re: Text formatting not always there

It's probably a timing issue.  Although I thought I'd got that sorted out.  Also the editor would have to be focused (clicked in, with blinking caret) before any of the buttons will work (not sure if it would throw an exception if you tried though.

I should probably make it so the buttons are disabled while the editor is not focused to sidestep that.

---

James Sleeman

anzenews

Xinha Community Member

Registered: 2005-02-21

Posts: 41

Re: Text formatting not always there

The editor was focused (the caret was in the editor) before any buttons were pressed. If it is a timing issue then it is an initialization timing issue...

Can anybody reproduce this bug? It is there on both Linux and Windows FireFox, but I'm not 100% sure it's not just my setup (as nobody else complained). But I can't see where I could be doing something wrong.

The idea to disable buttons while not in the editor seems good to me - the users do get confused if there are too many buttons (with multiple editors on the page). But with this bug / issue I think the buttons would just stay greyed out - which doesn't help.

gogo

Xinha Leader

From: New Zealand

Registered: 2005-02-11

Posts: 1,015

Website

Re: Text formatting not always there

Can you make a test case and submit it as a new ticket.

---

James Sleeman

anzenews

Xinha Community Member

Registered: 2005-02-21

Posts: 41

Re: Text formatting not always there

Submitting a ticket - no problem. Test case - well, I'll try to make a small page that has these problems and submit it with ticket. Could take a couple of days though - I am a bit busy right now.
Will post an answer here once it is done...

Anze

anzenews

Xinha Community Member

Registered: 2005-02-21

Posts: 41

Re: Text formatting not always there

Hmmmm, I think I found the cause - and it is not in the Xinha core. I was doing character substitution on form submit (left-over from htmlarea2) in JS for the characters that IE chokes on. When I cleaned the page the bug disappeared. I have no idea why, but since that code is no longer needed I guess it is all OK now...

Sorry for taking your time & thank you for your help.

Anze

anzenews

Xinha Community Member

Registered: 2005-02-21

Posts: 41

Re: Text formatting not always there

False false alarm - the bug is still there - but it is very difficult to reproduce it. Sometimes it pops up every other time and sometimes it won't happen for quite some time. Anyway, I will post a ticket.

Could someone else please tell me if you have spotted this or not? It's probably FireFox only - I don't have IE nearby to check.

About the disabled toolbar: it's funny, on a page where I have multiple Xinha editors most of them are disabled, but some are not. They do get disabled once I click in the editor area.
Update: I'm talking about TableOperations toolbars, the other toolbars are enabled by default (and stay that way when I put a caret in the editor area).

I looked into HTMLArea.init() code and it's very messy - no comments at all. What does loadNextScript() do? Does it recursively call itself? If not, why would the variable 'current' be incremented - there is no loop and it is local var, right?

Anyway, I'll get to writing a ticket...

Thanks, enjoy!

Anze

Last edited by anzenews (2005-03-05 19:28:33)