Clicking on Disabled Controls: What Happens?

Discussion in 'HTML' started by Gene Wirchenko, Apr 13, 2012.

  1. Hello:

    This is posted to both comp.lang.javascript and alt.html, because
    it might have to do with either JavaScript or HTML. I expect that it
    is the former, but.

    My form handler is coming along slowly, but the results are nice.
    I am now adding buttons for handling modes (adding, updating,
    deleting). When data entry is being done, only some of the controls
    are enabled. If a button or input control is disabled, it can get

    Suppose that DE is being done. Call the current input control

    If I click on something that is not enabled, the validation for
    Workpoint executes.

    If there is a validation error, an alert is issued, and the focus
    gets put back to Workpoint. (Spare me that this not how Web pages
    should work. "Sticky" focus on errors is what is needed and wanted.)

    However, if there is not a validation error, the focus goes off
    somewhere I know not where, AND I CAN NOT TELL WHERE. I want the
    focus back on Workpoint.

    The focus, despite not showing on the form, can be moved. If I
    press [Tab] immediately after this, the focus moves to the first
    enabled control on the form. This is weird.

    Ideally, I would like that when a non-enabled item is clicked on,
    that the click is ignored, that is, it is as if nothing had happened.

    If I can not have that, I would, at least, like to have the focus
    returned to Workpoint whether the validation succeeds or not.

    Unfortunately, document.currentElement does not give me a value
    that I can work with so that I can detect the weirdness. How can I
    tell where the focus is going? (I think I would then check if the
    control is disabled, and if so, set focus back to Workpoint.)


    Gene Wirchenko
    Gene Wirchenko, Apr 13, 2012
    1. Advertisements

  2. Gene Wirchenko

    Evertjan. Guest

    Gene Wirchenko wrote on 13 apr 2012 in comp.lang.javascript:
    Only if your code does not account for those states.
    I suggest you write code that incorporates all possible states.
    What is DE?
    What is Workpoint?
    Impossible, unless a higher onclick is being invoked,
    and then only in IE, not in Chrome. Try:

    <body onclick='alert("body")'>
    <input type='submit' disabled>
    What validation error?
    Of javascript or html?
    Or of a function called myValidation() ?
    What is Workpoint?
    But if the execution differs between IE and Chrome [and the other major
    browsers], that is not how web pages are supposed to work, and your code
    is incomplete or faulty in that sense.
    Only if your code does not specify where the focus should go.
    change your code to be ready for all states.

    If a text input does not have a value that is acceptable
    [is that what you mean by validation?]
    then the user should get a warning and should be returned to the state
    where he [she?] can correct that input or by his choice cancel the

    What is Workpoint?
    That depends on the browser, focus should be visible it is on a form
    element that can be used for input under html.

    You should set the focus on such element if the default is not doing that
    No, that is standard, if the focus is not on an inputtable input element.
    However if it is, it works as expected.
    Try tabbing and shift-tabbing here:

    <body onload='document.getElementById("q").focus()'>
    <input id=q>
    That is blissfully ignored in Chrome,
    and outwardly doing the same in IE if you programme accordingly.

    It would be nice if we could ignore IE altogether.
    What is Workpoint, the ID of an input element??

    You can do that:

    <form onclick='document.getElementById("Workpoint").focus()'>

    or perhaps 'better':

    function myValidation(inp) {
    if (validateMe(inp))
    }; // ;-)

    There is on weirdness if your programme code is prepared for all states.
    You can tell if your code is the master, as the focus then goes wher you
    want it to go [not counting that the user sets the focus somewhere else
    by mouse pointing cum clicking or by tabbing or shift-tabbing.

    If document.currentElement cannot reliably help you here, there is no
    other javascript reachable system variable that shows the focus,
    methinks. That only zero one element can have focus is an incidental fact
    of life, as seen from the perspective of a single element.

    Programmatically then you only know the focus state of elements where an
    eventlistener signals it, I think:

    <element id='el17'
    onfocus = 'storeFocusPosition(this)'
    onblurr = 'clearFocusPosition()'
    [The onblurr being necessary, when you have not set the onfocus for all
    possible elements on the page, which seems impossible on a scale larger
    than a minimal example.]
    Evertjan., Apr 14, 2012
    1. Advertisements

  3. Gene Wirchenko

    Jeff North Guest

    That is correct because the input control has lost focus and the
    onBlur event has been triggered. It doesn't matter what you click on
    (a disabled control, a blank space on the page, another input control,
    scrollbars) the same thing will happen.
    You need to tell the browser which control is to have focus.
    Not really, the focus is where you last clicked.
    Jeff North, Apr 14, 2012
  4. He defined these:

    DE is an abbreviation for data entry, ie the user is using the web page
    for data entry, as opposed to editing/updating existing data, or just
    viewing the current data.

    Workpoint he defined as "Call the current input control Workpoint." By
    this, I assume that "workpoint" refers to the input, select or textarea
    that has just been changed.

    The he said "If I click on something that is not enabled, the validation
    for Workpoint executes." .... presumably triggered by the onchange()
    event for the element that was active and changed, ie the "workpoint"

    I suspect that what is needed at the end of the validation routine for
    any given workpoint is something like (assuming workpoint is the current
    input control):

    if ( data_validates ) {
    // set workpoint to next active input on form
    else {
    alert( "Please correct the data in the indicated element" );;

    So that the focus jumps to the next active control. Determining the best
    method of finding the next active control is beyond the scope of the OPs


    Denis McMahon
    Denis McMahon, Apr 14, 2012
  5. Gene Wirchenko

    Evertjan. Guest

    Denis McMahon wrote on 14 apr 2012 in comp.lang.javascript:
    Does not ring a bell.
    Well yes, but my questions are to prevent that we should assume and guess
    what the OP means, and possibly even probably guess wrongly.
    Wouldn't a select() also do a focus() ?? [not tested]
    Evertjan., Apr 14, 2012
  6. Feh - go back and look at the OP. He defined "workpoint" with the exact
    text and sentence I quoted:

    "Call the current input control Workpoint."
    Well yeah, but the OP defined the terms he was using pretty specifically.
    Probably, didn't test either, but in any case, whatever input element
    workpoint is pointing at afterwards gets the select to move his input
    focus to where he wants it now.

    Although thinking about it, I didn't check that the sequence:;

    in text / textarea doesn't de-select when it focuses either! Or what
    happens when you "select" on other input controls than textarea and text.
    I imagine select is valid for password and hidden, but for other input
    types and select / option list?


    Denis McMahon
    Denis McMahon, Apr 14, 2012
  7. Gene Wirchenko

    Stefan Weiss Guest

    [Followup-To set to comp.lang.javascript; I don't read alt.html]

    Don't count on it. Clicking on a disabled text input field in Firefox 11
    will not cause the current element to lose focus, nor will the change
    event fire. Other browsers handle this situation differently.
    Okay, so you're dead set on something you know will cause some criticism
    (at least in this group). Do as thou wilt, and all that, but there are
    other people reading our posts, and they should know why alert()+focus()
    is not a good way to do client side form validation.

    I'll spare you the details if you're not listening anyway, but I will
    say that I'm pretty sure you will give up your insistence on this
    "feature" at some point. I've been down that road in the past (years
    ago). The customer wanted it, I didn't see anything terribly wrong with
    it, it got developed and deployed. Three months later, we were all sick
    of the constant alerts, and I changed the form validation code to be
    less patronizing and more flexible. User makes an error -> field is
    marked as invalid, and a way to see the error message is provided for
    each field (for example, an icon which will show the error message on
    hover). The user can continue to fill out the form, but will be
    prevented from submitting it (you can show an alert then, if you must).
    In addition to avoiding the technical issues you mentioned, this will
    allow the user to fill out the form in whatever order they want.

    Consider this example: user is on the phone with an angry customer, and
    begins filling out a trouble ticket form. The first field is the
    customer name, and it's a required field. The customer doesn't know that
    and gives the error description first. User wants to tab to the text
    area to write down the details, but can't, because the focus is
    constantly reset to the first field. Maybe that's a contrived example;
    my point is that filling out forms in a random order, with temporarily
    missing/incomplete/erroneous data, should be possible with a decent web
    application (within limits). Submitting the form should not.
    Is it? When the body has focus (which it will in Chrome, for example), a
    tab will set the focus to the first available input (observing tabindex,
    if set).
    Did you try document.activeElement?

    Be sure to check for browser support with that. AFAIK, it's supported in
    the current releases of all major browsers. If you're in an intranet
    with a browser monoculture, it might do what you think you need.

    - stefan
    Stefan Weiss, Apr 14, 2012
  8. How fatuous!

    Of course, I am trying to write code that handles all possible
    cases. That is why I post questions to these newsgroups.
    A common abbreviation in the industry for "Data Entry".
    Reread the second sentence of the paragraph.


    You sure work hard to misunderstand.


    Gene Wirchenko
    Gene Wirchenko, Apr 16, 2012
  9. Not ideal for my purposes, but I understand that this is the way
    it is, at least, with IE 9.
    First, I need to detect that I have to. The onfocus for the
    disabled control (if it is a control that is clicked on) does not
    fire. If it did, I could simply check that the control was disabled,
    and if so, then push the focus back.

    Though, if the click is on something not a control, that approach
    would not work. (Maybe, there is something DOMish that would solve
    this. I do not know much about manipulating via the DOM.)

    I need to know where to put the code to set the focus back. Since
    I am unable to detect which object is getting focus, becoming active,
    or whatever it is, I do not know where to put the code.
    Actually, no. I can click on a disabled input control later on
    the form, then tab, and the focus moves to the first enabled control,
    and this is before both Workpoint and the control just clicked on.

    Just now, looking for clickdown/clickup events (which do not
    exist), I saw mouseover. I think that I may try seeing if that fires
    on a disabled control. If so, I could save that. Hmm, DE will not
    follow the mouse, but I could save the control, and if it differs from
    Workpoint and is disabled, then I know that I have to do something.

    I wish this were easier.


    Gene Wirchenko
    Gene Wirchenko, Apr 16, 2012
  10. Gene Wirchenko

    Jeff North Guest

    You are fighting the standard GUI guidelines. You will only come to
    grief with this type of thinking from both the programmers and users
    Incorrect. YOU need to keep track of what controls have the focus so
    you can return to it if there is an error or such.
    And that is standard GUI practice. If you think about it, why should a
    disabled control react to anything because if it did then it wouldn't
    be disabled.
    Try the onFocus event to store the control's name.
    And that is the way it should work. The disabled control has the
    (invisible) focus so when you press the tab key the focus moves to the
    next non-disabled control (as you have amply demonstrated).
    It is - stop fighting the GUI and your life will be much simpler.

    Have you looked at the HTML5 attributes of placeholder and required?
    Jeff North, Apr 16, 2012
  11. Gene Wirchenko

    Evertjan. Guest

    Gene Wirchenko wrote on 16 apr 2012 in comp.lang.javascript:
    But why "weird"?

    Surely it is not weird if you do not incorporate certain states.
    The results then follow whatever is the way single browser tries
    to second guess you.
    Why are again and again prescribing the confine of the responses.

    At least my responses are not answers because this is usenet, and not a
    What "the" industry?

    This is a NG for javascriipt adepts and javascript casual interested,
    not specialized for the industrious of an industry,
    though they are welnome too,
    as long as they not claim the local linguo.

    I seem to remember a similar claiming by another group,
    some transponders, on linguo, equally not done.

    You sure work hard to upset the NG-ers that try to help,
    not only you, but also or moreso others
    that think they have questions like yours.

    So prescribing we do not need to address cross-browser issues and not to
    address the user-unfriendliness of your validation-routine does not hold
    for a NG.
    Evertjan., Apr 16, 2012
  12. I do keep track of it. What I need to detect is that a disabled
    item has been clicked on. Then, I could shift focus back. I
    currently know of no way to detect this.
    Exactly, but the focus still shifts. It would make more sense to
    me if clicking on something disabled did not case a focus shift. Think
    about it for a moment. If something is disabled, why should it do
    I already know which control had the focus (Workpoint). I need
    to detect that the focus is going to go into the weeds. After all, it
    is sometimes perfectly legitimate for focus to go off a control -- A
    field's validation does succeed sometimes -- and I need to
    diferentiate the cases.
    Well, no. As I have posted, tabbing does not move to the next
    non-disabled control but rather to the FIRST non-disabled control.

    I want the GUI to work for my end users. At this point, clicking
    in weird places causes weird things. I want to avoid this. Why does
    the GUI make this so difficult?

    I also do not want the workflow messed up. If someone
    accidentally clicks on Add while updating a row, I would rather than
    nothing happened. The GUI makes this difficult.

    If worse comes to worse, I may simply give up on the disabled
    property. I could come up with two versions of CSS for each control:
    normal and pseudo-disabled. In the pseudo-disabled, the control would
    get the focus, I could detect that the control is not live, and I
    could then send the focus back where it belongs. Mind you, this would
    not solve the problem of a click where there is no control.


    Gene Wirchenko
    Gene Wirchenko, Apr 16, 2012
  13. Gene Wirchenko

    Neil Gould Guest

    Gene Wirchenko wrote:
    [big snip]
    Why is it necessary to display disabled items? I realize that you would like
    to have a stable UI for your users, but it may be possible to achieve that
    by only presenting relevant options. Two other ideas are to provide a
    bell/buzzer event for disabled items, or to use graphic elements that look
    like the disabled items but can't be clicked on and won't be part of the tab
    Neil Gould, Apr 16, 2012
  14. Gene Wirchenko

    Tim Streater Guest

    I display disabled items in order to display the data to the user. When
    they want to edit it, and have the edits be saved, they click the 'Edit'
    button, part of the effect of which is to enable all those disabled
    textareas. The user then edits, and clicks 'Save'. Part of the tidy-up
    action is then to disable the textareas again.
    Tim Streater, Apr 16, 2012
  15. IF it is disabled it cannot obtain focus so you "detect" it by detecting
    the focus is *not* on it.

    It shifts but not to the disabled control. Use tab or click and see for

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    <script type="text/javascript">
    function announce(me){
    var msg=document.getElementById('status');
    msg.firstChild.nodeValue='Focus on ' +;


    <li id="status">Status</li>
    <input type="text" name="foo" id="foo" onfocus="announce(this)">
    <input type="text" name="bar" id="bar" disabled onfocus="announce(this)">
    <input type="text" name="baz" id="baz" onfocus="announce(this)">
    <input type="text" name="bin" id="bin" onfocus="announce(this)">

    Jonathan N. Little, Apr 16, 2012
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.