Cursor behaviour on select lists

When dropping down above text input fields

[BlobFisk]

I've just seen an usual behaviour that I've never seen before. I have form with a select dropdown list, that drops down over some input boxes. This seems to cause the default arrow* to change on some options (but not all!) from the pointer to the text cursor, when the options are over an input box.

I've tried adding a class to the select that uses the "default" or "auto" cursor, but this still happens.

Has anyone seen this before, and if so, did you manage to work out a solution?

TIA

* - This is for an application that is being developed for IE6+ on Win2k+ only.

[BlobFisk]

Strange - I create a flat HTML version of the page and the issue no longer shows. It would seem to be linked to the Struts environment... could this be possible?

[Alternative Future]

Hi BlobFisk,

Also working on a similar application using struts1.1.
We have loads of forms with the select and input boxes underneath, but i cannot seem to replicate the problem you are having...!
We are using struts nested input and select tags.

Also checked it over textareas and double instances of textboxes and other selects.

-George

[BlobFisk]

Hey George,

Yep! It's certainly an interesting one.... They are indeed struts nested input and select tags:

<crmcustom:nvcollection validCodeKey="3" scope="request" id="busnessSegmentList"/>
<html:select property="query.businessSegment" onkeypress="dropDownKeyPressed(this)" styleClass="cursAuto">
<html:options collection="busnessSegmentList" labelProperty="name" property="value" styleClass="cursAuto"/></html:select>

...

<html:text maxlength="35" styleClass="char35" property="query.lastName" />

This one has me puzzled... I thought that it could be the onkeypress event, but this is just javascript "listening" for the enter key:

//constant for enter key
var ENTER_KEY=13;

//get last key event
function getKey(){
return event.keyCode;
}

//submit drop down if enter key has been pressed
//and drop down has changed.
function dropDownKeyPressed(dropDown){
if(getKey()==ENTER_KEY){
dropDown.form.submit();
}
}

I'm totally at a loss with this one....

[Alternative Future]

BlobFisk,

Your struts usage looks very like our version one codebase where we also used <html:select> since moving onto struts1.1 we are now using <nested:select> as below:

<nested:select property="selectedIsolationType" styleClass="editorlargecombo">
<html: option value=""><bean:message key="global.please.select"/></html: option>
<html: options collection="isolationTypes" property="name" labelProperty="name"></html: options>
</nested:select>

<nested:text property="taskDescription" styleClass="textfieldlarge"/>

I tested version one codebase also to see if I could replicate it, but no joy!

Am sure I have seen what you are talking about though, and if my memory serves me right it had to do with the JavaScript menu we had in place at the time. Am looking through our historical notes to see if i can find that issue. Like you say it is a weird one and I cannot think how we managed to get past it, it might have been resolved when we moved onto a newer JavaScript dropdown menu.

Like you say you wouldn't think JavaScript is to blame on this one, as we also had double combos populating one another with an onclick event. But with the dropdown menu (am sure) being at fault with the first issue we had, it kinda points that way.

If I manage to find anything more on this one I shall post back.

But good luck in the meantime...

-George

[BlobFisk]

Thanks! All help appreciated!

[BlobFisk]

Well, I've tracked down the cause of this and it looks like another IE quirk. And a very strange one at that...

I have a marquee tag on a hidden layer on the page (which is toggled to visible to act as a system busy indicator) and it looks like that when there is a marquee tag on the page, IE switches the cursor on a drop down select list to the text cursor. I've tested this on a number of pages and in a number of environments, and it happens consistently. This is an IE only phenomenon.

[Alternative Future]

Nice one BlobFisk,

That's nice to know, I will keep this in our records just encase we come accross it. When I saw this behaviour before i don't think we had any marquee tags in place.

Cheers and well done on the debug.

-George

[BlobFisk]

When I saw this behaviour before i don't think we had any marquee tags in place.

Which makes me wonder if there are more objects that might cause this behaviour in IE other than the marquee tag...

Something worth testing when I get some spare time (latest estimate on that is circa. 2015!).

Cheers George!