Struts 1
  1. Struts 1
  2. STR-3006

Struts HTML taglib's select element doesn't support proper onfocus events in IE7

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.0.0, 1.0.1, 1.0.2, 1.1.1, 1.2.2, 1.2.4, 1.2.6 Beta, 1.2.7, 1.2.8, 1.2.9, 1.3.5, 1.3.6, 1.3.7, 1.4.0
    • Fix Version/s: None
    • Component/s: Tag Libraries
    • Labels:
      None
    • Environment:
      Any
    • Flags:
      Patch

      Description

      There is a known issue with IE7 and the plain <select> input element... let's say for example you have this:

      <html>
      <head>
      <title></title>
      </head>
      <body>
      <select onFocus="this.style.backgroundColor='#ff0000';">
      <option value="1">1</option>
      <option value="2">2</option>
      </select>
      </body>
      </html>

      In IE7, when you click on the dropdown arrow, the list of items will not immediately show up, you need to click it twice. This is due to the onFocus handler being attached. This is a known issue with IE. The solution is to simply add an onFocusIn handler which (usually) mimics the onFocus handler.

      However, in Struts 1, because the HTML taglib does not allow arbitrary attributes (something I believe it should, and I said as much on a BugZilla ticket which I can't seem to find in JIRA now, and along with it I suggested adding a strictHTML attribute, which would default to true, to allow (false) or disallow (true) arbitrary attributes), you cannot properly deal with this issue at present if you use the HTML taglib.

      Attached please find two updated files, BaseHandlerTag.java and struts-html.tld, which adds support for the onfocusin attribute.

      I marked this as Minor, but for those of us dealing with this issue right now, it's more like a Major I also consider it a bug since I don't see any viable work-around (someone can correct me if I'm wrong... and yes, not using the HTML taglib is I suppose a valid answer, but I'd be looking for something else)

      1. struts-html.tld.diff
        0.8 kB
        Frank W. Zammetti
      2. struts-html.tld
        343 kB
        Frank W. Zammetti
      3. struts-attr-tag-v2.patch
        34 kB
        Niall Pemberton
      4. BaseHandlerTag.java.diff
        1 kB
        Frank W. Zammetti
      5. BaseHandlerTag.java
        31 kB
        Frank W. Zammetti

        Issue Links

          Activity

          Hide
          Frank W. Zammetti added a comment -

          Update BaseHandlerTag.java class

          Show
          Frank W. Zammetti added a comment - Update BaseHandlerTag.java class
          Hide
          Frank W. Zammetti added a comment -

          Updated struts-html.tld file

          Show
          Frank W. Zammetti added a comment - Updated struts-html.tld file
          Hide
          Niall Pemberton added a comment -

          The policy has always been not to add non-standard html attributes and generally to not implement workarounds for other things that are broken - such as browsers. A viable workaround for people who want to use non-standard attributes is to create custom implmentations of the HTML taglib - not "don't use the HTML taglib".

          Show
          Niall Pemberton added a comment - The policy has always been not to add non-standard html attributes and generally to not implement workarounds for other things that are broken - such as browsers. A viable workaround for people who want to use non-standard attributes is to create custom implmentations of the HTML taglib - not "don't use the HTML taglib".
          Hide
          Frank W. Zammetti added a comment -

          I'm sorry, but if "create custom implementations of the HTML taglib" is the answer to such things, then what's the point of using a framework in the first place? Sure, I can extend virtually anything I want at any time, but a huge part of using a framework is that things like this are dealt with.

          Can we please just state that the Struts tags are essentially Abandonware and people should use them at their own peril? If the policy is to not fix things just because it might require something non-standard, or for any other reason frankly, then the tags are stagnant and stand little chance of ever moving forward (which I think we all knew before anyway), so let's just state it and get it over with once and for all so people know where things stand.

          I have to say, it seems to me that almost any time in the last year or so that anyone comes along with updates to the taglibs, there's always some excuse (ahem, policy) for not doing it. That to me translates to the tags are dead in the water, which would be fine, if that was stated. I'm sure you can point out things that have been done, but I'd be shocked if any of them were nontrivial.

          Show
          Frank W. Zammetti added a comment - I'm sorry, but if "create custom implementations of the HTML taglib" is the answer to such things, then what's the point of using a framework in the first place? Sure, I can extend virtually anything I want at any time, but a huge part of using a framework is that things like this are dealt with. Can we please just state that the Struts tags are essentially Abandonware and people should use them at their own peril? If the policy is to not fix things just because it might require something non-standard, or for any other reason frankly, then the tags are stagnant and stand little chance of ever moving forward (which I think we all knew before anyway), so let's just state it and get it over with once and for all so people know where things stand. I have to say, it seems to me that almost any time in the last year or so that anyone comes along with updates to the taglibs, there's always some excuse (ahem, policy) for not doing it. That to me translates to the tags are dead in the water, which would be fine, if that was stated. I'm sure you can point out things that have been done, but I'd be shocked if any of them were nontrivial.
          Hide
          Michael Jouravlev added a comment -

          Seems that you believe that there is a policy to not fix taglib bugs. I hope that I was not the culprit of this misunderstanding. Apparently Martin Cooper got the same idea from my suggestion to deprecate (as in: to discourage from use and to freeze fixes to, not to remove) BEAN and LOGIC tags. He pointed out that there is no such policy.

          Speaking for myself, I am indeed have no interest in fixing bugs in BEAN and and LOGIC tag libraries because this functionality is covered by JSTL, and JSTL is a bigger standard that Struts. In this regards I am not a worthy asset to Struts 1, despite that I was "brought in to help maintain an S1 project" and apparently was supposed to be dealing with such stuff. On the other hand, I am all for continuing working on HTML tags, for example it would be great to have Hubert's HTML2 stuff in core Struts taglib.

          If you are sure that it won't break anything in other browsers nor in future versions of either MS or other browsers then it may be worth applying to taglib. I personally have nothing against arbitrary attributes but seems that I am in the minority. On another hand, if IE7 is buggy despite at least two years of development and testing and their claims of ensuring the outmost compatibility, isn't it their fault? Firefox seems to work fine

          Anyway, it would be great if you submitted patches in CVS/SVN terms, that is, a diff file against known file version in SVN. Submitting 340K of modified struts-html.tld seems just too much.

          Show
          Michael Jouravlev added a comment - Seems that you believe that there is a policy to not fix taglib bugs. I hope that I was not the culprit of this misunderstanding. Apparently Martin Cooper got the same idea from my suggestion to deprecate (as in: to discourage from use and to freeze fixes to, not to remove) BEAN and LOGIC tags. He pointed out that there is no such policy. Speaking for myself, I am indeed have no interest in fixing bugs in BEAN and and LOGIC tag libraries because this functionality is covered by JSTL, and JSTL is a bigger standard that Struts. In this regards I am not a worthy asset to Struts 1, despite that I was "brought in to help maintain an S1 project" and apparently was supposed to be dealing with such stuff. On the other hand, I am all for continuing working on HTML tags, for example it would be great to have Hubert's HTML2 stuff in core Struts taglib. If you are sure that it won't break anything in other browsers nor in future versions of either MS or other browsers then it may be worth applying to taglib. I personally have nothing against arbitrary attributes but seems that I am in the minority. On another hand, if IE7 is buggy despite at least two years of development and testing and their claims of ensuring the outmost compatibility, isn't it their fault? Firefox seems to work fine Anyway, it would be great if you submitted patches in CVS/SVN terms, that is, a diff file against known file version in SVN. Submitting 340K of modified struts-html.tld seems just too much.
          Hide
          Paul Benedict added a comment -

          I do not support defining custom attributes, but I do support an effort to create an <html:attribute> tag which allows emitting additional attributes in our tag libraries.

          Show
          Paul Benedict added a comment - I do not support defining custom attributes, but I do support an effort to create an <html:attribute> tag which allows emitting additional attributes in our tag libraries.
          Hide
          Niall Pemberton added a comment -

          Frank,

          You're probably right, not many people have had much interest in tags for at least a couple of years. Whether the tags are abandonware or not is a separate issue from what the stated policy is on non-standard attributes though. Personally its not a big deal IMO to extend the tags - I have customized versions of Struts tags - and I don't think its a frameworks job to implement every whim thats requested. The number of non-standard attributes is large and as well as being a never ending nightmare maintenance-wise it also will create untold problems for developers when they mistakenly use non-standard tags and their users use a browser which doesn't support them. Only implementing a standard is a good policy IMO.

          On the "attributes" request - from memory Martin objected to solution that emitted non-standard attributes. This will probably not satisfy you in any way, but I'm attaching a patch for an <html:attr> tag - that doesn't fall foul of that objection. It doesn't resolve your issue, but would make custom implementations easier - since the plumbing is present

          Show
          Niall Pemberton added a comment - Frank, You're probably right, not many people have had much interest in tags for at least a couple of years. Whether the tags are abandonware or not is a separate issue from what the stated policy is on non-standard attributes though. Personally its not a big deal IMO to extend the tags - I have customized versions of Struts tags - and I don't think its a frameworks job to implement every whim thats requested. The number of non-standard attributes is large and as well as being a never ending nightmare maintenance-wise it also will create untold problems for developers when they mistakenly use non-standard tags and their users use a browser which doesn't support them. Only implementing a standard is a good policy IMO. On the "attributes" request - from memory Martin objected to solution that emitted non-standard attributes. This will probably not satisfy you in any way, but I'm attaching a patch for an <html:attr> tag - that doesn't fall foul of that objection. It doesn't resolve your issue, but would make custom implementations easier - since the plumbing is present
          Hide
          Frank W. Zammetti added a comment -

          Interesting idea Paul... how to you envision it working? How would having a new <html:attribute> tag allow me to specify onfocusin on am <html:select> tag? Doesn't sound like a bad idea to me.

          Michael, my belief is that there is insufficient interest by current committers to do anything but very minor fixes to the tags. I believe this based on what I've seen over the past 1-2 years, maybe more, with regard to suggested enhancements. Every single one that I can recall, not just my own, was shot down for one reason or another, and often that reason is the policy Niall mentioned. To me, that policy can be rephrased as we're not interested in fixing or enhancing the tags any more because that's the ultimate outcome.

          I am in agreement with you that not doing anything other than critical bug fixes to anything but the HTML tags makes sense... JSTL is more than capable of taking their place. The HTML tags are a different story though, they shouldn't be allowed to stagnate, and I believe that's the course that has been choosen, again based on what I've seen.

          I am quite sure this change wouldn't break anything... it's mearly another attribute that can optionally be supplied on the tags. And I agree, this is IE7's fault, not Struts... that doesn't mean though that knowingly allowing the Struts tags to not address a concern regarding what is still the dominant browser on the market makes sense. Especially in this one particular case where the solution is as simple as allowing a new optional attribute and nothing more, it seems to be downright illogical to not want to do it.

          Let me give a concrete example here... I discovered this problem today based on testing my current project on IE7... now, in some parts of the app we used html:select, in other parts just plain select's (multiple developers unfortunately not standardizing one way or another). So, we have some selects in the app that work properly in IE7 (the plain selects) and some that don't (the html:select versions). The only solution I can see right now is what Niall proposes: create my own subclass. My contention is that's not the right answer for something that I consider a bug, albeit one caused by the browser being incorrect. Ultimately, any Struts developer trying to use the onFocus event of an html:select in IE7 will have to face this... is it right to tell them all to create their own version of the HTML tags? Why the heck are they using a framework then?

          I will indeed do a diff tonight... I only attached the full files because I did not have the ability to create a diff where I was when I opened the ticket, but I thought it important to get this opened sooner than later. Look for it here in a little while, even though I hold very little hope of anything being done with it, at least no one will be able to say I didn't supply the bits.

          Show
          Frank W. Zammetti added a comment - Interesting idea Paul... how to you envision it working? How would having a new <html:attribute> tag allow me to specify onfocusin on am <html:select> tag? Doesn't sound like a bad idea to me. Michael, my belief is that there is insufficient interest by current committers to do anything but very minor fixes to the tags. I believe this based on what I've seen over the past 1-2 years, maybe more, with regard to suggested enhancements. Every single one that I can recall, not just my own, was shot down for one reason or another, and often that reason is the policy Niall mentioned. To me, that policy can be rephrased as we're not interested in fixing or enhancing the tags any more because that's the ultimate outcome. I am in agreement with you that not doing anything other than critical bug fixes to anything but the HTML tags makes sense... JSTL is more than capable of taking their place. The HTML tags are a different story though, they shouldn't be allowed to stagnate, and I believe that's the course that has been choosen, again based on what I've seen. I am quite sure this change wouldn't break anything... it's mearly another attribute that can optionally be supplied on the tags. And I agree, this is IE7's fault, not Struts... that doesn't mean though that knowingly allowing the Struts tags to not address a concern regarding what is still the dominant browser on the market makes sense. Especially in this one particular case where the solution is as simple as allowing a new optional attribute and nothing more, it seems to be downright illogical to not want to do it. Let me give a concrete example here... I discovered this problem today based on testing my current project on IE7... now, in some parts of the app we used html:select, in other parts just plain select's (multiple developers unfortunately not standardizing one way or another). So, we have some selects in the app that work properly in IE7 (the plain selects) and some that don't (the html:select versions). The only solution I can see right now is what Niall proposes: create my own subclass. My contention is that's not the right answer for something that I consider a bug, albeit one caused by the browser being incorrect. Ultimately, any Struts developer trying to use the onFocus event of an html:select in IE7 will have to face this... is it right to tell them all to create their own version of the HTML tags? Why the heck are they using a framework then? I will indeed do a diff tonight... I only attached the full files because I did not have the ability to create a diff where I was when I opened the ticket, but I thought it important to get this opened sooner than later. Look for it here in a little while, even though I hold very little hope of anything being done with it, at least no one will be able to say I didn't supply the bits.
          Hide
          Niall Pemberton added a comment -

          Woops - page from the examples webapp was missing from the patch

          Show
          Niall Pemberton added a comment - Woops - page from the examples webapp was missing from the patch
          Hide
          Frank W. Zammetti added a comment -

          diff's for files

          Show
          Frank W. Zammetti added a comment - diff's for files
          Hide
          Paul Benedict added a comment -

          Niall nailed it. My idea was:

          <html:select onFocus="this.style.backgroundColor='#ff0000';">
          <html:attr name="onFocusIn" value="your_value" />
          </html:select>

          I believe this would satisfy Martin's objection, which Niall correctly pointed out, and mine as well. Also at least some of the big browsers are moving toward implementing the WHAT-WG (Web Hypertext Application Technology Working Group) standard, and so this allows people to move forward with progress without waiting for official support. Their work enhances HTML4 with many more attributes:

          http://www.whatwg.org/specs/web-apps/current-work/

          Show
          Paul Benedict added a comment - Niall nailed it. My idea was: <html:select onFocus="this.style.backgroundColor='#ff0000';"> <html:attr name="onFocusIn" value="your_value" /> </html:select> I believe this would satisfy Martin's objection, which Niall correctly pointed out, and mine as well. Also at least some of the big browsers are moving toward implementing the WHAT-WG (Web Hypertext Application Technology Working Group) standard, and so this allows people to move forward with progress without waiting for official support. Their work enhances HTML4 with many more attributes: http://www.whatwg.org/specs/web-apps/current-work/
          Hide
          Frank W. Zammetti added a comment -

          Thanks Niall, I do appreciate you posting that patch. I think tomorrow I'll have little choice but to go off and create my own version of the HTML taglib as you said originally, that's the most expedient option that gets me where I need to be. I just wish it was helping others too.

          One last point I want to make in reply to something you said... I know I'm arguing a long-standing policy here so I'm not going to get much traction, but is it really a good idea to make it so developers can't shoot themselves in the foot? I mean, saying that non-standard attributes won't be implemented on the tags because it will cause trouble for developers who use them seems to me to not be giving developers much credit... I think it's enough to document the attributes as being non-standard, in the TLD, in the source and in the tag docs, and if a developer goes and uses it anyway, I think it's right to have faith that they know the potential consequences. I don't believe a framework should expliticly stop you from doing something because the developers don't think its a good idea... it's different if something isn't possible just because it wasn't thought of or implemented, but here we're talking about a conscious decision to not allow something. I know I'm the minority, I know that's the policy and I know I'm not going to win this, but it just doesn't sit right with me.

          Paul, I saw your latest reply as I was typing this... that tag looks great, I think it would in fact solve my problem while still adhering to the policy, so definitely a win-win... so when will we see it committed?

          Show
          Frank W. Zammetti added a comment - Thanks Niall, I do appreciate you posting that patch. I think tomorrow I'll have little choice but to go off and create my own version of the HTML taglib as you said originally, that's the most expedient option that gets me where I need to be. I just wish it was helping others too. One last point I want to make in reply to something you said... I know I'm arguing a long-standing policy here so I'm not going to get much traction, but is it really a good idea to make it so developers can't shoot themselves in the foot? I mean, saying that non-standard attributes won't be implemented on the tags because it will cause trouble for developers who use them seems to me to not be giving developers much credit... I think it's enough to document the attributes as being non-standard, in the TLD, in the source and in the tag docs, and if a developer goes and uses it anyway, I think it's right to have faith that they know the potential consequences. I don't believe a framework should expliticly stop you from doing something because the developers don't think its a good idea... it's different if something isn't possible just because it wasn't thought of or implemented, but here we're talking about a conscious decision to not allow something. I know I'm the minority, I know that's the policy and I know I'm not going to win this, but it just doesn't sit right with me. Paul, I saw your latest reply as I was typing this... that tag looks great, I think it would in fact solve my problem while still adhering to the policy, so definitely a win-win... so when will we see it committed?
          Hide
          Niall Pemberton added a comment -

          I have some sympathy with the idea that if you want to shoot yourself in the foot then thats your choice - and in your case I know you would understand the consequences. On the other hand though there could be alot of people who could see something and assume "must be OK to use 'coz those Struts guys know what they're doing". How many complaints would we get when they find out parts of their apps don't work properly and do you think they would be satisfied when they ask us "Why the hell did you implement non-standard attributes?" and we answer "we gave you the loaded gun, but its your fault you shot yourself?"

          Show
          Niall Pemberton added a comment - I have some sympathy with the idea that if you want to shoot yourself in the foot then thats your choice - and in your case I know you would understand the consequences. On the other hand though there could be alot of people who could see something and assume "must be OK to use 'coz those Struts guys know what they're doing". How many complaints would we get when they find out parts of their apps don't work properly and do you think they would be satisfied when they ask us "Why the hell did you implement non-standard attributes?" and we answer "we gave you the loaded gun, but its your fault you shot yourself?"
          Hide
          Frank W. Zammetti added a comment -

          I understand what your saying Niall... I just have to think that if the documentation is clear, you've done about all you can, and if a developer makes a mistake... well, at some point that has to fall in the category of their problem. I think a framework can (and should) only think for you to a certain extent

          Ah well, no sense beating a dead horse here... we all seem to be saying this <html:attribute> tag is a good idea, and I think that addresses the concerns of all parties. I think there's even some interest in realizing it in 1.4... I 'll get by my current situation by subclassing I think, but the new tag gives a more general solution, which is what I was trying to provide, so that sounds good long-term.

          Show
          Frank W. Zammetti added a comment - I understand what your saying Niall... I just have to think that if the documentation is clear, you've done about all you can, and if a developer makes a mistake... well, at some point that has to fall in the category of their problem. I think a framework can (and should) only think for you to a certain extent Ah well, no sense beating a dead horse here... we all seem to be saying this <html:attribute> tag is a good idea, and I think that addresses the concerns of all parties. I think there's even some interest in realizing it in 1.4... I 'll get by my current situation by subclassing I think, but the new tag gives a more general solution, which is what I was trying to provide, so that sounds good long-term.

            People

            • Assignee:
              Unassigned
              Reporter:
              Frank W. Zammetti
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development