Infamous Firefox cursor bug - Info and possible workarounds

[philip142au]

Hi,

I have a firefox browser and a IE browser, I have INPUT tag on form on a BasicDialog, but in firefox the cursor doesn't Flash when I click on the input box why?

Please help!

Thanks, Philip

[brian.moeskau]

I believe this is a FF bug, at least according to Jack. Not sure if there is a solution to it or not.

[soso]

Did anyone found a solution to this bug?

Thanks

[schmidetzki]

It-s definitiv a FF bug.
The only solution I found is to position the dialog content "fixed".
Something like this:

<div>
    <div class="x-dlg-hd ydlg-hd">no title</div>
    <div class="x-dlg-bd ydlg-bd">
	    <div style="position:fixed">
	       ... dialaog content
	    </div>
    </div>
</div>

[amitava]

I had also faced the similar problem working with yui-ext .33. After some investigating I somehow found that this only happens if shim:true, otherwise its fine. So here is my workaround tested in both FF 1.5 and 2. Not quite sure whether it is the right process.

function show_pm_msg(dlg, hwnd) {
	/* to fix firefox cursor issue */
	var useShim;
	var ua = navigator.userAgent.toLowerCase();
	if (ua.indexOf("msie") > -1){
		useShim = true;
	}else{
		useShim = false;
	}
	
	if(!pm_msg_dlg){ // lazy initialize the dialog and only create it once
		pm_msg_dlg = new YAHOO.ext.BasicDialog(dlg, {
			autoTabs:true,
			autoScroll: true,
			resizable: true,
			width:500,
			height:350,
			shadow:true,
			minWidth:300,
			minHeight:250,
			shim:useShim, //only for ie
			fixedcenter:true,
			proxyDrag: true
		});
		pm_msg_dlg.addKeyListener(27, pm_msg_dlg.hide, pm_msg_dlg);
		pm_msg_dlg.addButton('Close', pm_msg_dlg.hide, pm_msg_dlg);
		pm_btn = pm_msg_dlg.addButton('Submit', reply_to_pm, pm_msg_dlg);
	}		
	pm_msg_dlg.show(hwnd);	
}

[nhausig]

Using shim:false only helps in some situations. This bug is a firefox issue and many years old (see https://bugzilla.mozilla.org/show_bug.cgi?id=167801). I've tried many workarounds to no avail. Now there's a solution (see Comment #84). It is somehow ugly. You need a wrapper div around your text input with overflow set to auto and display to none. Then you set display to block after a short delay.

var inputWrapperDiv = ...;

if (YAHOO.ext.util.Browser.isGecko) {
  inputWrapperDiv.style.display   = 'none';
  inputWrapperDiv.style.overflow  = 'auto';
  setTimeout(function() {inputWrapperDiv.style.display = 'block';}, 10);
}

If setting overflow to auto is resulting in scrollbars (resizing elements in wrapper div), you have to give the wrapper div some extra padding.

[amitava]

Using shim:false only helps in some situations. This bug is a firefox issue and many years old (see https://bugzilla.mozilla.org/show_bug.cgi?id=167801). I've tried many workarounds to no avail. Now there's a solution (see Comment #84). It is somehow ugly. You need a wrapper div around your text input with overflow set to auto and display to none. Then you set display to block after a short delay.

var inputWrapperDiv = ...;

if (YAHOO.ext.util.Browser.isGecko) {
  inputWrapperDiv.style.display   = 'none';
  inputWrapperDiv.style.overflow  = 'auto';
  setTimeout(function() {inputWrapperDiv.style.display = 'block';}, 10);
}

If setting overflow to auto is resulting in scrollbars (resizing elements in wrapper div), you have to give the wrapper div some extra padding.

Thanks nhausig for sharing your experience.

BTW, would you please explain a little bit about those other situations where using shim:false doesn't help? Thanks again.

Amitava

[nhausig]

BTW, would you please explain a little bit about those other situations where using shim:false doesn't help? Thanks again.
Amitava

It won't help if there's another cause on the page, not just the shim iframe. The ff bug is about text input overlapping scrollable elements in general. It occurs when you have a text input overlapping a div that has overflow set to auto. There are other fixes than the js-delay-block solution but most of them have unwanted sideeffects and you cannot apply them in general. I stepped into this problem, because usually my apps have a document content area that is housed in a div with auto-overflow, because I want auto-scollbars for the document. Therefore all my modal dialogs with text-entry showed this problem.

Some interesting testcases from the mozilla bug site:

https://bugzilla.mozilla.org/attachment.cgi?id=98624
https://bugzilla.mozilla.org/attachment.cgi?id=245770
https://bugzilla.mozilla.org/attachment.cgi?id=187105

[Jonathan Feinberg]

Here's a workaround that works for me, and gives you a nice, fat, blinking cursor in the text area:

Ext.MessageBox.getDialog().on("show", function(d) {
	var div = Ext.get(d.el);
	div.setStyle("overflow", "auto");
	var text = div.select(".ext-mb-textarea", true);
	if (!text.item(0))
		text = div.select(".ext-mb-text", true);
	if (text.item(0))
		text.item(0).dom.select();
});

[hunkybill]

@Jonathan Feinberg:

Nice. Worked fine for me, but was not really 'fat'!! Nice to finally see a cursor in the middle of a border layout dialog box again. That's the first thing people have bitched to me about, the dang missing cursors in form fields. Nested border layout + dialogs with forms is pretty much a standard necessary pattern for any decent application, and the fact that most INPUT elements over West, Center, or East regions are cursor-less due to CSS sucks big time. Funny how I thought after reading the Bugzilla reports - the solution was to enclose my INPUT elements in a container with overflow:auto. Oops.. me bad.