Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-9089

PM message title box not accessible via Tab key

    Details

    • Type: Bug
    • Status: Unverified Fix
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.x, 3.0.9
    • Fix Version/s: 3.0.11-RC1
    • Component/s: Styles
    • Labels:
      None

      Description

      Procedure to reproduce:

      1) Enter a recipient name in the textarea
      2) Press tab key repeatedly.

      You go from the textarea to the icons to the message textarea. I've not taken the time to fully diagnose this one yet. Tested on FF3.

        Activity

        Hide
        Oleg Oleg [X] (Inactive) added a comment -

        Possible fix: add tabindex=1 to username list.

        Show
        Oleg Oleg [X] (Inactive) added a comment - Possible fix: add tabindex=1 to username list.
        Hide
        Oleg Oleg [X] (Inactive) added a comment -

        I think the patch should be committed.

        The other branch (non-pm) in the template uses tabindex=1, so current behavior between pm and non-pm modes is inconsistent.

        I had one opportunity to type a pm and tried tabbing from the recipients field; current tabbing order is not helpful and adding tabindex=1 would not make anything worse.

        I read the spec on tabindex and my understanding of it is that the browser builds a page-wide ordering of all input controls based on their tabindexes. Without tabindex=1 the recipient input is placed after all tabindexed controls, and following the recipient input are other controls without tabindex like smilies.

        Show
        Oleg Oleg [X] (Inactive) added a comment - I think the patch should be committed. The other branch (non-pm) in the template uses tabindex=1, so current behavior between pm and non-pm modes is inconsistent. I had one opportunity to type a pm and tried tabbing from the recipients field; current tabbing order is not helpful and adding tabindex=1 would not make anything worse. I read the spec on tabindex and my understanding of it is that the browser builds a page-wide ordering of all input controls based on their tabindexes. Without tabindex=1 the recipient input is placed after all tabindexed controls, and following the recipient input are other controls without tabindex like smilies.
        Hide
        narqelion narqelion [X] (Inactive) added a comment -

        AJD:

        Procedure to reproduce: <snipped>


        It is important to note that I think you are actually missing an important step, which is adding a user in the address (To field which is necessary since only one user can be added at a time using the 'Add' button. Upon actually adding a user the tab will correctly send you to the subject field. This behavior is consistent across FF versions 3.0.x/3.5/3.6 & Google Chrome.

        Sequence of keystrokes once compose PM window is open and cursor is in 'To:'

        type user name -> Tab -> (takes you to 'Find a member' -> Tab -> (takes you to 'Add') -> Enter (Adds the user as a recipient) -> Tab (takes you to the subject field) -> Enter a subject -> Tab (takes you to message body)

        Show
        narqelion narqelion [X] (Inactive) added a comment - AJD: Procedure to reproduce: <snipped> It is important to note that I think you are actually missing an important step, which is adding a user in the address (To field which is necessary since only one user can be added at a time using the 'Add' button. Upon actually adding a user the tab will correctly send you to the subject field. This behavior is consistent across FF versions 3.0.x/3.5/3.6 & Google Chrome. Sequence of keystrokes once compose PM window is open and cursor is in 'To:' type user name -> Tab -> (takes you to 'Find a member' -> Tab -> (takes you to 'Add') -> Enter (Adds the user as a recipient) -> Tab (takes you to the subject field) -> Enter a subject -> Tab (takes you to message body)
        Hide
        A_Jelly_Doughnut A_Jelly_Doughnut added a comment -

        I produce the same behavior.

        However, the "add" button is not required when adding a single recipient, which is the way the majority of PMs I write or receive are structured.

        tabindexes are a pain. :?

        Show
        A_Jelly_Doughnut A_Jelly_Doughnut added a comment - I produce the same behavior. However, the "add" button is not required when adding a single recipient, which is the way the majority of PMs I write or receive are structured. tabindexes are a pain. :?
        Hide
        narqelion narqelion [X] (Inactive) added a comment -

        AJD:

        However, the "add" button is not required when adding a single recipient, ...


        Actually it is if you want to work around another bug, which I learned back in 2008. Without actually hitting the 'Add' button to place the recipient in the field, the subsequent use of "Submit" will not actually send the message, instead it sends you to 'Preview'. The only way to avoid that is to actually enter the recipient yourself before submit then everything works the way a keyboardist like myself expects. I do believe the submit returning preview was previously submitted as a bug at some point, perhaps multiple times. My aging brain cells recall a distant conversation (aka debate) with a developer who said that was the intended behavior in the case of no recipients being added (by 'Add') that the preview was returned @ submit as a check because the recipient field was being entered by the 'Submit' rather than the 'Add'. I disagreed with that assessment because submit should mean submit not preview but alas I just adapted to using the 'Add' in my tab sequence.

        Ah yes here is a link to one of the many reports over the same bizarre behavior...
        http://www.phpbb.com/bugs/phpbb3/40755

        Such a tangled web you weave...

        Show
        narqelion narqelion [X] (Inactive) added a comment - AJD: However, the "add" button is not required when adding a single recipient, ... Actually it is if you want to work around another bug, which I learned back in 2008. Without actually hitting the 'Add' button to place the recipient in the field, the subsequent use of "Submit" will not actually send the message, instead it sends you to 'Preview'. The only way to avoid that is to actually enter the recipient yourself before submit then everything works the way a keyboardist like myself expects. I do believe the submit returning preview was previously submitted as a bug at some point, perhaps multiple times. My aging brain cells recall a distant conversation (aka debate) with a developer who said that was the intended behavior in the case of no recipients being added (by 'Add') that the preview was returned @ submit as a check because the recipient field was being entered by the 'Submit' rather than the 'Add'. I disagreed with that assessment because submit should mean submit not preview but alas I just adapted to using the 'Add' in my tab sequence. Ah yes here is a link to one of the many reports over the same bizarre behavior... http://www.phpbb.com/bugs/phpbb3/40755 Such a tangled web you weave...
        Hide
        nickvergessen Joas Schilling added a comment -

        The buttons (add and bbc) should be added to the tabindex aswell.
        Subsilver2 is missing.

        Show
        nickvergessen Joas Schilling added a comment - The buttons (add and bbc) should be added to the tabindex aswell. Subsilver2 is missing.
        Hide
        imkingdavid David King added a comment - - edited

        In reference to the page reloading to check on un-verified recipients, how about this:
        -Check all intended recipients
        – If all are valid recipients, do not load the preview; add them as recipients automatically and send the PM right away
        – If some or all are invalid, keep current behavior (load preview and add valid recipients while notifying about invalid recipients)

        This saves times when all recipients are valid users and can receive PMs.

        On second thought, though, when AJAX is implemented, users should be added to recipient lists without page reload to make things even easier.

        EDIT: But in response to this ticket, I think adding a tabindex value would make it work properly otherwise.

        Show
        imkingdavid David King added a comment - - edited In reference to the page reloading to check on un-verified recipients, how about this: -Check all intended recipients – If all are valid recipients, do not load the preview; add them as recipients automatically and send the PM right away – If some or all are invalid, keep current behavior (load preview and add valid recipients while notifying about invalid recipients) This saves times when all recipients are valid users and can receive PMs. On second thought, though, when AJAX is implemented, users should be added to recipient lists without page reload to make things even easier. EDIT: But in response to this ticket, I think adding a tabindex value would make it work properly otherwise.

          People

          • Assignee:
            nickvergessen Joas Schilling
            Reporter:
            A_Jelly_Doughnut A_Jelly_Doughnut
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development