Workaround for an infamous missing caret bug in Firefox

[Paul Robertson]

Hello forum

I'm fairly sure that I am suffering from a well-known Firefox bug concerning the disappearance of the 'caret' text-cursor from within the radEditor content area. My particular scenario, which from my research I gather is not unusual, is that I have the radEditor inside a hidden DIV when the page first loads, after which the radEditor can eventually be displayed by the user's actions, through client-side/CSS manipulation of the container DIV which is then set to be visible. After this occurs though, the caret stubbornly refuses to appear inside the content area Iframe, through any workaround I have yet to try. Of course if the user minimises and maximises the window again, instantly the caret returns, blinking away as if nothing had gone wrong!

Most of the workarounds cited seem to be based around either re-setting the "contenteditable" or "designMode" attributes for various components of the radEditor, the Iframe, the DIV etc., or manipulation of visibility and textflow CSS properties. Unfortunately nothing I have yet to try makes the slightest bit of difference - so after many hours wasted, I thought it was best to come to the forum to ask if there is any prevailing view on the best way to approach this problem, for example, "contenteditable", CSS, or some other approach?

If anybody can shed light on the current thinking for solving this long-standing annoyance, I would really be grateful for a pointer in the right direction.

Regards

 

[Rumen]

Hello,

The content area of RadEditor is an editable IFRAME and the reported problem is Firefox v3.6 browser bug (a regression) introduced in Firefox 3.6. We found that this issue is logged in this BugZilla report: focus() to an iframe in designmode renders cursor (caret) invisible in FF3.6 only.

The problem should be fixed in the latest version of RadControls for ASP.NET AJAX Q1 2012 SP1.

Best regards,
Rumen
the Telerik team

[Paul Robertson]

Hi there

I did spot the Bugzilla report you refer to there, but unfortunately their suggestion workaround of calling 

     frameDocument.designMode = 'on'

on the control load event does not seem to working for me when applied to any of the document / window objects returned by the radEditor client-side API. As I am indeed using an earlier version of RadControls AJAX to the one you mention, I was wondering if anybody had successfully found a workaround to the bug - for example, as also indicated in the Bugzilla report, I too can use an alert box to defeat the bug, but I really don't want to use an alert box every time I show the editor control, it looks very clumsy. Has anybody found a more sophisticated solution? Does the success of the focus after the alert box indicate a timing issue, or a z-index issue, for example.

Thanks if anyone can advise.