Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1.1
    • Fix Version/s: 2.4
    • Component/s: Accessibility, Gradebook
    • Labels:
    • Testing Instructions:
      Hide

      Log in as the administrator and use the keyboard only to navigate through the following select boxes:

      • The report picker on grade/report/grader/index.php
      • The language picker in the top right hand corner.
      • "Add a block" selector on any page.
      • The group selector in any activity
      • The filter admin screen

      Try the following:

      1. Tab into the box.
      2. Use the arrow keys to scroll through the options.
      3. Tab out of the box. (Tabbing out of the select box when using Chrome on Windows will result in a page redirect)
        [TEST] - none of these actions should cause the page to redirect to the selected option.
      4. When ready hit enter to go to the selected option.

      Try using the mouse to select an option
      [TEST] - make sure that only clicking the button will result in being redirected to an option.

      Please test:

      • On Linux, Mac and Windows
      • with these browsers: Firefox, Chrome, Internet Explorer 8 and 9, Opera, and Safari.
        For added authenticity try using a screen reader to navigate around the pages.
      Show
      Log in as the administrator and use the keyboard only to navigate through the following select boxes: The report picker on grade/report/grader/index.php The language picker in the top right hand corner. "Add a block" selector on any page. The group selector in any activity The filter admin screen Try the following: Tab into the box. Use the arrow keys to scroll through the options. Tab out of the box. (Tabbing out of the select box when using Chrome on Windows will result in a page redirect) [TEST] - none of these actions should cause the page to redirect to the selected option. When ready hit enter to go to the selected option. Try using the mouse to select an option [TEST] - make sure that only clicking the button will result in being redirected to an option. Please test: On Linux, Mac and Windows with these browsers: Firefox, Chrome, Internet Explorer 8 and 9, Opera, and Safari. For added authenticity try using a screen reader to navigate around the pages.
    • Affected Branches:
      MOODLE_21_STABLE
    • Fixed Branches:
      MOODLE_24_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      wip-MDL-30912-master
    • Rank:
      33920

      Description

      The report view selection menu is an unlabelled jump menu. We need to add an appropriate label to the form element and make a "Go" button to execute the selection in the menu

        Issue Links

          Activity

          Hide
          Adrian Greeve added a comment -

          Just an idea on how we might be able to toggle the go button on and off with a new accessibility setting.

          Show
          Adrian Greeve added a comment - Just an idea on how we might be able to toggle the go button on and off with a new accessibility setting.
          Hide
          Ankit Agarwal added a comment -

          Hi,
          Had a chat with Adrian and here is the summary:-

          • This new setting will control the behavior of dropdowns in multiple places besides just grade. A issue will be created and linked to list such places. (incase its decided to bring in this feature and if its decided not to bring in this feature, IMHO this issue can be closed.)
          • MDL-30843 will take care of the labeling issue.

          Thanks

          Show
          Ankit Agarwal added a comment - Hi, Had a chat with Adrian and here is the summary:- This new setting will control the behavior of dropdowns in multiple places besides just grade. A issue will be created and linked to list such places. (incase its decided to bring in this feature and if its decided not to bring in this feature, IMHO this issue can be closed.) MDL-30843 will take care of the labeling issue. Thanks
          Hide
          Adrian Greeve added a comment -

          Sorry Greg, we just need a bit more information from you about accessibility on this issue. Do people that use screen readers normally have JavaScript enabled? Currently if JavaScript is disabled on Moodle then "go" buttons will appear next to all drop down menus which would usually automatically redirect to another page. Is this a serious issue that many people encounter?

          Show
          Adrian Greeve added a comment - Sorry Greg, we just need a bit more information from you about accessibility on this issue. Do people that use screen readers normally have JavaScript enabled? Currently if JavaScript is disabled on Moodle then "go" buttons will appear next to all drop down menus which would usually automatically redirect to another page. Is this a serious issue that many people encounter?
          Hide
          Greg Kraus added a comment -

          The only real data we have comes from this survey

          http://webaim.org/projects/screenreadersurvey3/#javascript

          where it says 98% of screen reader users have JavaScript enabled. From anecdotal evidence, I also believe the vast majority of screen reader users have JavaScript enabled. Screen reader users uniformly disabling JavaScript is from a bygone Web era, if it ever existed at all.

          It's not only an issue for screen reader users, but also for keyboard-only users. If you only use a keyboard to navigate (using the Tab key) then if you navigate through the select element items to read them, when you tab off of the select element, the action will be fired whether you want it to or not.

          Show
          Greg Kraus added a comment - The only real data we have comes from this survey http://webaim.org/projects/screenreadersurvey3/#javascript where it says 98% of screen reader users have JavaScript enabled. From anecdotal evidence, I also believe the vast majority of screen reader users have JavaScript enabled. Screen reader users uniformly disabling JavaScript is from a bygone Web era, if it ever existed at all. It's not only an issue for screen reader users, but also for keyboard-only users. If you only use a keyboard to navigate (using the Tab key) then if you navigate through the select element items to read them, when you tab off of the select element, the action will be fired whether you want it to or not.
          Hide
          Michael de Raadt added a comment -

          Carrying over to new sprint.

          Show
          Michael de Raadt added a comment - Carrying over to new sprint.
          Hide
          Adrian Greeve added a comment -

          This patch uses the screen reader setting in the user profile. It will disable all the jump menus and display go buttons for each one.

          Show
          Adrian Greeve added a comment - This patch uses the screen reader setting in the user profile. It will disable all the jump menus and display go buttons for each one.
          Hide
          Greg Kraus added a comment -

          The one issue with attaching this to the screen reader user profile setting is this is not a screen reader only issue. The jump menu problem impacts all non-mouse users. If you try to tab to a select element and read through its options, as soon as you tab off of the select menu the action fires.

          Show
          Greg Kraus added a comment - The one issue with attaching this to the screen reader user profile setting is this is not a screen reader only issue. The jump menu problem impacts all non-mouse users. If you try to tab to a select element and read through its options, as soon as you tab off of the select menu the action fires.
          Hide
          Tim Hunt added a comment -

          We should not be using the screen-reader profile setting here at all. (If fact, MDL-30901 has my vote. We should be trying to remove that profile setting, not use it more.)

          We should fix the JavaScript so that it does the right thing. That means:

          1. When the user enters the select menu, the JavaScript should note the currently selected options.
          2. When the user leaves, the JavaScript should only trigger the automatic submit if the user has changed the selection. (And not if they have changed it to Choose...)
          3. When initialising the page (adding the event handlers) we should add some appropriate class="accesshide" text to make it clear that this meny auto-submits.

          Greg, can you confrim that would meet the accessibility requirements.

          Show
          Tim Hunt added a comment - We should not be using the screen-reader profile setting here at all. (If fact, MDL-30901 has my vote. We should be trying to remove that profile setting, not use it more.) We should fix the JavaScript so that it does the right thing. That means: When the user enters the select menu, the JavaScript should note the currently selected options. When the user leaves, the JavaScript should only trigger the automatic submit if the user has changed the selection. (And not if they have changed it to Choose...) When initialising the page (adding the event handlers) we should add some appropriate class="accesshide" text to make it clear that this meny auto-submits. Greg, can you confrim that would meet the accessibility requirements.
          Hide
          Adrian Greeve added a comment -

          I've made some alterations to the JavaScript file that controls the jump menus. I've removed one of the functions as it does the exact same thing as the function above and just pointed the reference in code to that function instead. This patch fixes the menu getting selected from tabing out of the select box. The only problem is that Chrome and Safari don't work i.e. they still do exactly what they did before. I was considering creating a new issue for fixing this in those browsers.

          Show
          Adrian Greeve added a comment - I've made some alterations to the JavaScript file that controls the jump menus. I've removed one of the functions as it does the exact same thing as the function above and just pointed the reference in code to that function instead. This patch fixes the menu getting selected from tabing out of the select box. The only problem is that Chrome and Safari don't work i.e. they still do exactly what they did before. I was considering creating a new issue for fixing this in those browsers.
          Hide
          Tim Hunt added a comment -

          Adrian, before trying to review your patch, what I would like to see are your testing instructions. That would help us understand the behaviour that your patch is trying to implement. Then someone like Greg could review the expected behaviour in the testing instructions, and confirm that they meet normal expectations.

          Can I ask, do you ever navigate web pages just using the keyboard, not your mouse? Have you ever experimented using a screen-reader to see what it is like?

          Show
          Tim Hunt added a comment - Adrian, before trying to review your patch, what I would like to see are your testing instructions. That would help us understand the behaviour that your patch is trying to implement. Then someone like Greg could review the expected behaviour in the testing instructions, and confirm that they meet normal expectations. Can I ask, do you ever navigate web pages just using the keyboard, not your mouse? Have you ever experimented using a screen-reader to see what it is like?
          Hide
          Tim Hunt added a comment -

          Also, in what sense does the init_url_select function do the same thing as init_select_autosubmit? init_url_select sends the user to a particular URL on submit, even if there is not a form in the HTML, init_select_autosubmit submits the form that the SELECT is in.

          Show
          Tim Hunt added a comment - Also, in what sense does the init_url_select function do the same thing as init_select_autosubmit? init_url_select sends the user to a particular URL on submit, even if there is not a form in the HTML, init_select_autosubmit submits the form that the SELECT is in.
          Hide
          Adrian Greeve added a comment -

          A comment that Sam made:

          One thing I would consider (and it is you working on this not me) I would look to rewrite processchange and paramobject stuff into a self servicing object that behaved in the following way
          1. On call of the method an object is initialised and as part of its initialisation it attaches a focus event that calls newobject.focusin (like the drug on the simpsons)
          2. When focusin gets called it attaches a listener for the enter key and when fired calls this.submit
          3. It also attaches a listener to change/click/whatever which when fired calls this.change, this.change can then do any necessary validation and if appropriate calls this.submit
          4. Finally a blue event gets attached to the select that calls this.focusout
          5. this.submit then stops event propogation, removes all listeners, and submits the form
          6. this.focusout stops event propogration, and removes all listeners (cleans up)

          Show
          Adrian Greeve added a comment - A comment that Sam made: One thing I would consider (and it is you working on this not me) I would look to rewrite processchange and paramobject stuff into a self servicing object that behaved in the following way 1. On call of the method an object is initialised and as part of its initialisation it attaches a focus event that calls newobject.focusin (like the drug on the simpsons) 2. When focusin gets called it attaches a listener for the enter key and when fired calls this.submit 3. It also attaches a listener to change/click/whatever which when fired calls this.change, this.change can then do any necessary validation and if appropriate calls this.submit 4. Finally a blue event gets attached to the select that calls this.focusout 5. this.submit then stops event propogation, removes all listeners, and submits the form 6. this.focusout stops event propogration, and removes all listeners (cleans up)
          Hide
          Adrian Greeve added a comment -

          Test instructions have now been included.

          I've managed to find a solution to the problem that I was having with Chrome. I had a talk to Sam about why we have two functions for select boxes that both redirect to a url. He suggested that somewhere in the history of development that two different people wrote a solution each and that over time the code became similar and they were both kept for backwards compatibility. With this solution all the select menus that need to redirect to a url go through the one function and the same checks.

          Show
          Adrian Greeve added a comment - Test instructions have now been included. I've managed to find a solution to the problem that I was having with Chrome. I had a talk to Sam about why we have two functions for select boxes that both redirect to a url. He suggested that somewhere in the history of development that two different people wrote a solution each and that over time the code became similar and they were both kept for backwards compatibility. With this solution all the select menus that need to redirect to a url go through the one function and the same checks.
          Hide
          Tim Hunt added a comment -

          Removing myself as peer reviewer. I think someone better qualified should do it.

          Show
          Tim Hunt added a comment - Removing myself as peer reviewer. I think someone better qualified should do it.
          Hide
          Sam Hemelryk added a comment -

          Hi Adrian.

          Really looks like this is shaping one.
          Just one thing I noticed that needs to be fixed up.
          You are adding two key events presently, you're assigning both to eventkeypress which isn't good as it means you lose the first event handle.
          Can that not be done with just a single key event btw?

          Rest looks spot on thanks.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Adrian. Really looks like this is shaping one. Just one thing I noticed that needs to be fixed up. You are adding two key events presently, you're assigning both to eventkeypress which isn't good as it means you lose the first event handle. Can that not be done with just a single key event btw? Rest looks spot on thanks. Cheers Sam
          Hide
          Adrian Greeve added a comment -

          Hi Sam,

          Thanks for the comments. I had another look at the code and it seems that I don't really need the 'key' event, so I removed it. I tested the code out with IE 8, Firefox and Chrome and didn't encounter any issues. It will probably need testing in other browsers to be really sure that everything is working well.

          Thanks again.

          Show
          Adrian Greeve added a comment - Hi Sam, Thanks for the comments. I had another look at the code and it seems that I don't really need the 'key' event, so I removed it. I tested the code out with IE 8, Firefox and Chrome and didn't encounter any issues. It will probably need testing in other browsers to be really sure that everything is working well. Thanks again.
          Hide
          Sam Hemelryk added a comment -

          Cool thanks for tidying that up Adrian. Putting this up for integration immediately.

          Show
          Sam Hemelryk added a comment - Cool thanks for tidying that up Adrian. Putting this up for integration immediately.
          Hide
          Dan Poltawski added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Dan Poltawski added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Adrian Greeve added a comment -

          Rebased and ready to go.

          Show
          Adrian Greeve added a comment - Rebased and ready to go.
          Hide
          Adrian Greeve added a comment -

          Rebased, hoping that after the madness of 2.3 settles down that this might get looked at.

          Show
          Adrian Greeve added a comment - Rebased, hoping that after the madness of 2.3 settles down that this might get looked at.
          Hide
          Michael de Raadt added a comment -

          Carrying over to new sprint.

          Show
          Michael de Raadt added a comment - Carrying over to new sprint.
          Hide
          Dan Poltawski added a comment -

          Is this targeted at 2.3 only?

          Show
          Dan Poltawski added a comment - Is this targeted at 2.3 only?
          Hide
          Adrian Greeve added a comment -

          Yes, I don't think that this change should be back ported to other branches. It's more of an improvement than anything else.

          Show
          Adrian Greeve added a comment - Yes, I don't think that this change should be back ported to other branches. It's more of an improvement than anything else.
          Hide
          Dan Poltawski added a comment -

          Integrated into 23 and master.

          I had a play with this and I really like this solution, seems like we have the best of all worlds.

          Show
          Dan Poltawski added a comment - Integrated into 23 and master. I had a play with this and I really like this solution, seems like we have the best of all worlds.
          Hide
          Frédéric Massart added a comment -

          The test passed, except for Opera but we decided to raise a separate issue (MDL-34162).

          Also, Greg, that would be great if you could test it with your screen reader.

          Thanks guys!

          Show
          Frédéric Massart added a comment - The test passed, except for Opera but we decided to raise a separate issue ( MDL-34162 ). Also, Greg, that would be great if you could test it with your screen reader. Thanks guys!
          Hide
          Dan Poltawski added a comment -

          Hi, I just noticed this is breaking the admin/filter.php, so failing this!

          Show
          Dan Poltawski added a comment - Hi, I just noticed this is breaking the admin/filter.php, so failing this!
          Hide
          Dan Poltawski added a comment -

          This is in Version 20.0.1132.47, it doesn't automatically submit. If i use arrow keys and dowuble press enter it submits.

          Show
          Dan Poltawski added a comment - This is in Version 20.0.1132.47, it doesn't automatically submit. If i use arrow keys and dowuble press enter it submits.
          Hide
          Sam Hemelryk added a comment -

          Hi Dan can you please clarify what you are seeing here.

          I've been testing things this morning but have been unable to replicate anything other than the noted Opera bug.
          I've used the following browsers when testing:

          Opera v12
          Firefox v13
          Chrome v20.0.1132.47

          On admin/filters.php I've tried the following:

          1. Click and select a different value for both the Active and Apply To select boxes. Expected to redirect back with changes
          2. Click and select the current value for both. Expected no action taken.
          3. Tab to the select, arrow down to a different value and hit enter. Expected to redirect back with changes.
          4. Tab to the select, arrow down to a different value and hit tab to move focus. Expected to redirect back with changes.
          5. Tab to the select, arrow down to a different value, use the mouse and select a third (different value). Expected to redirect back with changes for item selected by mouse.
          6. Tab to the select, arrow down to a different value, use the mouse and select the original element. Expected no action taken.

          The only browse that I had trouble with was Opera.

          Was there something specific I had to do to trigger the issue, or could it perhaps be an OS specific thing perhaps (I'm running Ubuntu 12.04)?

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Dan can you please clarify what you are seeing here. I've been testing things this morning but have been unable to replicate anything other than the noted Opera bug. I've used the following browsers when testing: Opera v12 Firefox v13 Chrome v20.0.1132.47 On admin/filters.php I've tried the following: Click and select a different value for both the Active and Apply To select boxes. Expected to redirect back with changes Click and select the current value for both. Expected no action taken. Tab to the select, arrow down to a different value and hit enter. Expected to redirect back with changes. Tab to the select, arrow down to a different value and hit tab to move focus. Expected to redirect back with changes. Tab to the select, arrow down to a different value, use the mouse and select a third (different value). Expected to redirect back with changes for item selected by mouse. Tab to the select, arrow down to a different value, use the mouse and select the original element. Expected no action taken. The only browse that I had trouble with was Opera. Was there something specific I had to do to trigger the issue, or could it perhaps be an OS specific thing perhaps (I'm running Ubuntu 12.04)? Cheers Sam
          Hide
          Dan Poltawski added a comment -

          Hi,

          I thought this was resolved by xml strict headers problem I was having, but it is not.

          Just did some debugging. It seems that the problem is Chrome on the Mac 10.7.4 and it is not limited to filters, its all the select boxes including the language one. It seems that the click event doesn't fire. The keydown does.

          Looks like it is one of these chrome issues:
          http://code.google.com/p/chromium/issues/detail?id=36518
          http://code.google.com/p/chromium/issues/detail?id=98274
          http://code.google.com/p/chromium/issues/detail?id=117701

          And now I look at the patch there is also the hack for MDL-23224 which we removed.

          Show
          Dan Poltawski added a comment - Hi, I thought this was resolved by xml strict headers problem I was having, but it is not. Just did some debugging. It seems that the problem is Chrome on the Mac 10.7.4 and it is not limited to filters, its all the select boxes including the language one. It seems that the click event doesn't fire. The keydown does. Looks like it is one of these chrome issues: http://code.google.com/p/chromium/issues/detail?id=36518 http://code.google.com/p/chromium/issues/detail?id=98274 http://code.google.com/p/chromium/issues/detail?id=117701 And now I look at the patch there is also the hack for MDL-23224 which we removed.
          Hide
          Sam Hemelryk added a comment -

          Righto thanks for clarifying Dan.

          I think given we are working towards to getting everything cleared for the minor release and that this is an accessibility issue that we are best to revert these changes for the time being and focus on them after the release.

          How does everybody else feel about this?

          Show
          Sam Hemelryk added a comment - Righto thanks for clarifying Dan. I think given we are working towards to getting everything cleared for the minor release and that this is an accessibility issue that we are best to revert these changes for the time being and focus on them after the release. How does everybody else feel about this?
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Reverted (23 and master). Let's address this again after release, paying specially attention to MDL-23224.

          Reopening, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Reverted (23 and master). Let's address this again after release, paying specially attention to MDL-23224 . Reopening, ciao
          Hide
          CiBoT added a comment -

          Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

          Show
          CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
          Hide
          Adrian Greeve added a comment -

          Issue size: XL

          Show
          Adrian Greeve added a comment - Issue size: XL
          Hide
          Adrian Greeve added a comment -

          Hi

          Things that I've done to this version of my patch:

          • I've removed the code for preventing bubbling as it was preventing the redirect when using a mouse.
          • Extensive testing of various variations of click, blur, change, key, keydown, mousedown, and mouseup events with different browsers on different operating systems.

          Please note - I managed to get almost everything working apart from Chrome and Safari on Windows. It seems that the Y.UA.webkit doesn't recognise the 'click' method when a select is being made. 'change' unfortunately will also fire when using the keyboard. This means that tabbing out of the select box will result in a redirect. I considered the option of trying to pick up if a key had been pressed or a mouse clicked, but it seems that YUI has a bug where these events will always come up as 'undefined' so currently there is no way of distinguishing between the two. Perhaps we can leave this as is for the moment (the functionality in this respect hasn't changed) until further improvements are made in YUI.

          Show
          Adrian Greeve added a comment - Hi Things that I've done to this version of my patch: I've removed the code for preventing bubbling as it was preventing the redirect when using a mouse. Extensive testing of various variations of click, blur, change, key, keydown, mousedown, and mouseup events with different browsers on different operating systems. Please note - I managed to get almost everything working apart from Chrome and Safari on Windows. It seems that the Y.UA.webkit doesn't recognise the 'click' method when a select is being made. 'change' unfortunately will also fire when using the keyboard. This means that tabbing out of the select box will result in a redirect. I considered the option of trying to pick up if a key had been pressed or a mouse clicked, but it seems that YUI has a bug where these events will always come up as 'undefined' so currently there is no way of distinguishing between the two. Perhaps we can leave this as is for the moment (the functionality in this respect hasn't changed) until further improvements are made in YUI.
          Hide
          Aparup Banerjee added a comment -

          Hi Adrian, you may want to check out the possibility of defining a custom event (or reusing) .. see 1e22cd351f7cdd36115201329634f76f36da7091

          Show
          Aparup Banerjee added a comment - Hi Adrian, you may want to check out the possibility of defining a custom event (or reusing) .. see 1e22cd351f7cdd36115201329634f76f36da7091
          Hide
          Adrian Greeve added a comment -

          Thanks Apu for the comment. I've had a look at that code, and reading through the documentation for synthetic events gave the idea on how to solve the chrome on windows problem that I was having.

          Now that I have everything working in all browsers I'm submitting for integration review.

          Show
          Adrian Greeve added a comment - Thanks Apu for the comment. I've had a look at that code, and reading through the documentation for synthetic events gave the idea on how to solve the chrome on windows problem that I was having. Now that I have everything working in all browsers I'm submitting for integration review.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Eloy Lafuente (stronk7) added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Dan Poltawski added a comment -

          I've tested and looking better to me on chrome on mac.

          Integrated to master only (let me know if you want more).

          Show
          Dan Poltawski added a comment - I've tested and looking better to me on chrome on mac. Integrated to master only (let me know if you want more).
          Hide
          Adrian Greeve added a comment -

          Thanks Dan,

          Just on the master branch please.

          Show
          Adrian Greeve added a comment - Thanks Dan, Just on the master branch please.
          Hide
          Frédéric Massart added a comment -

          Failing for discussion.

          This did not work on Opera (Ubuntu, I did not test the other platforms) but as it is not supported it is fine. And Chrome on Windows jumps on soon as an arrow is pressed.

          Show
          Frédéric Massart added a comment - Failing for discussion. This did not work on Opera (Ubuntu, I did not test the other platforms) but as it is not supported it is fine. And Chrome on Windows jumps on soon as an arrow is pressed.
          Hide
          Michael de Raadt added a comment -

          This worked for me on Chrome under Windows.

          Show
          Michael de Raadt added a comment - This worked for me on Chrome under Windows.
          Hide
          Adrian Greeve added a comment -

          It seems to be working fine on Chrome under Windows for me as well. Michael said that some mention was made of Opera in 2.3 somewhere, so I guess that should be investigated further.

          Show
          Adrian Greeve added a comment - It seems to be working fine on Chrome under Windows for me as well. Michael said that some mention was made of Opera in 2.3 somewhere, so I guess that should be investigated further.
          Hide
          Dan Poltawski added a comment -

          How does it fail in Opera? We don't really officially support it, but if it makes thing totally unusable then i'm not sure about it.

          Show
          Dan Poltawski added a comment - How does it fail in Opera? We don't really officially support it, but if it makes thing totally unusable then i'm not sure about it.
          Hide
          Frédéric Massart added a comment -

          On Opera the navigation in the dropdowns cannot be done using the keyboard as it jumps when using the arrow keys.

          Show
          Frédéric Massart added a comment - On Opera the navigation in the dropdowns cannot be done using the keyboard as it jumps when using the arrow keys.
          Hide
          Dan Poltawski added a comment -

          Passing, as opera still works the same as it did before in opera. It just doesn't work with keyboard.

          Show
          Dan Poltawski added a comment - Passing, as opera still works the same as it did before in opera. It just doesn't work with keyboard.
          Hide
          Dan Poltawski added a comment -

          Congratulations, you've done it!

          Thanks, this change is now in the latest weekly release!

          Join the crowds of people tomorrow from 8am and download this Moodle release from your local apple store!

          Show
          Dan Poltawski added a comment - Congratulations, you've done it! Thanks, this change is now in the latest weekly release! Join the crowds of people tomorrow from 8am and download this Moodle release from your local apple store!

            People

            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: