Moodle
  1. Moodle
  2. MDL-36838

Firefox 17 useragent detected has old Gecko version

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.2.6, 2.3.3, 2.4
    • Fix Version/s: None
    • Component/s: MNet
    • Labels:
    • Testing Instructions:
      Hide

      Establish mnet between a moodle & mahara. Add the network servers block to the main page in moodle.
      In firefox 17 log in to the moodle as a user who is permitted to SSO to mahara.
      Click the link in the network servers block to jump to mahara.
      Observe failure.
      Apply this patch to Moodle, and try clicking the link again.
      Observe success.

      Show
      Establish mnet between a moodle & mahara. Add the network servers block to the main page in moodle. In firefox 17 log in to the moodle as a user who is permitted to SSO to mahara. Click the link in the network servers block to jump to mahara. Observe failure. Apply this patch to Moodle, and try clicking the link again. Observe success.
    • Workaround:
      • Upgrade to the latest stable version of Moodle
      • Disable the complexOverride.moodle in Firefox
    • Affected Branches:
      MOODLE_22_STABLE, MOODLE_23_STABLE, MOODLE_24_STABLE
    • Pull Master Branch:
      MDL-36838-FF17-MNETSSO-MASTER
    • Rank:
      46360

      Description

      When trying to jump by mnet from moodle to mahara, the hashes for the useragent are not matching and thus the jump fails.

      Upon investigation I noted that the Moodle useragent string is:
      "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0"

      But the Mahara (and other things) useragent string is:
      "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0"

      This is how it shows in the apache access logs too.

      The Mahara-detected useragent is, as best I can tell, the expected result.

      This of course means that the hash passed from Mahara to Moodle fails to match, and an mnet jump can't succeed.

      This was originally reported to Mahara at:
      https://bugs.launchpad.net/mahara/+bug/1082416

      This is happening in spite of MDL-35469

        Activity

        Hide
        Dan Poltawski added a comment -

        I'm going to comment on the launchpad issue about this..

        Show
        Dan Poltawski added a comment - I'm going to comment on the launchpad issue about this..
        Hide
        Melissa Draper added a comment -

        This is a patch for the Moodle to ignore the UA when checking for sessions.

        Show
        Melissa Draper added a comment - This is a patch for the Moodle to ignore the UA when checking for sessions.
        Hide
        Melissa Draper added a comment -

        This is the patch for the Mahara. Attaching here so people don't have to go hunting through the LP bug

        Show
        Melissa Draper added a comment - This is the patch for the Mahara . Attaching here so people don't have to go hunting through the LP bug
        Hide
        Matthew N added a comment - - edited

        Note that this issue also applies for Moodle-to-Moodle MNet SSO:
        1) Clear cookies for dev.moodle.org
        2) Login at moodle.org
        3) Visit https://moodle.org/network/ which will list the other Moodle installs that are connected with Moodle.org via MNet
        4) Click on "Moodle Developer Courses" (http://dev.moodle.org)

        Expected result:
        You should automatically be signed into http://dev.moodle.org

        Actual result:
        Ooops! Your MNET communication has failed! Here's that error message to pass on to your administrator: Authorisation failed: the mnet session does not exist…

        Now that you have a MoodleSession* cookie set on http://dev.moodle.org, subsequent MNet SSO attempts will work until the cookie expires. This is because the override in Firefox only takes effect if a MoodleSession* cookie exists.

        Show
        Matthew N added a comment - - edited Note that this issue also applies for Moodle-to-Moodle MNet SSO: 1) Clear cookies for dev.moodle.org 2) Login at moodle.org 3) Visit https://moodle.org/network/ which will list the other Moodle installs that are connected with Moodle.org via MNet 4) Click on "Moodle Developer Courses" ( http://dev.moodle.org ) Expected result: You should automatically be signed into http://dev.moodle.org Actual result: Ooops! Your MNET communication has failed! Here's that error message to pass on to your administrator: Authorisation failed: the mnet session does not exist… Now that you have a MoodleSession* cookie set on http://dev.moodle.org , subsequent MNet SSO attempts will work until the cookie expires. This is because the override in Firefox only takes effect if a MoodleSession* cookie exists.
        Hide
        Dan Poltawski added a comment -

        Urgh.

        Show
        Dan Poltawski added a comment - Urgh.
        Hide
        Peter Bulmer added a comment -

        Melissa & I have been talking about her proposed patch above. She has asked me to contribute our discussion here.

        Her patch above looks good to me for SingleSignOn, but there needs a little bit more for SSOut.

        I've improved this patch for master, and pushed it to my github account.
        I'm just about to test this on a site here, against an also-patched mahara & will update with my results then. Shouldn't be too long.

        This is a fairly minimal patch, it should maintain compatibility with older Moodles, Maharas & other apps for non-FF17 users.

        Show
        Peter Bulmer added a comment - Melissa & I have been talking about her proposed patch above. She has asked me to contribute our discussion here. Her patch above looks good to me for SingleSignOn, but there needs a little bit more for SSOut. I've improved this patch for master, and pushed it to my github account. I'm just about to test this on a site here, against an also-patched mahara & will update with my results then. Shouldn't be too long. This is a fairly minimal patch, it should maintain compatibility with older Moodles, Maharas & other apps for non-FF17 users.
        Show
        Peter Bulmer added a comment - https://github.com/peterbulmer/moodle/tree/MDL-36838-FF17-MNETSSO-MASTER
        Hide
        Peter Bulmer added a comment -

        The "Pull Master Diff URL" above isn't quite right. That's a slightly old version of the patch. The current patch is the same, with one extra line of diff (a comment).

        Show
        Peter Bulmer added a comment - The "Pull Master Diff URL" above isn't quite right. That's a slightly old version of the patch. The current patch is the same, with one extra line of diff (a comment).
        Hide
        Hugh Davenport added a comment -

        Added a comment to petes github branch.

        Cheers,

        Hugh

        Show
        Hugh Davenport added a comment - Added a comment to petes github branch. Cheers, Hugh
        Hide
        Peter Bulmer added a comment -

        Full discussion had with Hugh, but no further changes planned as a result.

        Show
        Peter Bulmer added a comment - Full discussion had with Hugh, but no further changes planned as a result.
        Hide
        Dan Poltawski added a comment -

        What are your thoughts on a 1.9 version? Technically we do not support 1.9 for non-security fixes, however we did get enough votes to include the useragent check fix. We could ask for votes for this too.

        Show
        Dan Poltawski added a comment - What are your thoughts on a 1.9 version? Technically we do not support 1.9 for non-security fixes, however we did get enough votes to include the useragent check fix. We could ask for votes for this too.
        Hide
        Peter Bulmer added a comment -

        Should be dead simple. Working on that at the moment.

        Show
        Peter Bulmer added a comment - Should be dead simple. Working on that at the moment.
        Hide
        Melissa Draper added a comment -

        Dan,

        If my opinion counts for Moodle things at all, I'd be considering the previous useragent check fix incomplete because of this bug and this fix as the logical conclusion of it.

        We/Mahara are likely to get the majority of the bug reports from 1.9 sites since the error is displayed on the Mahara landing page and the users/admins may not realise it's Moodle, so I may be biased

        -M

        Show
        Melissa Draper added a comment - Dan, If my opinion counts for Moodle things at all, I'd be considering the previous useragent check fix incomplete because of this bug and this fix as the logical conclusion of it. We/Mahara are likely to get the majority of the bug reports from 1.9 sites since the error is displayed on the Mahara landing page and the users/admins may not realise it's Moodle, so I may be biased -M
        Hide
        Peter Bulmer added a comment -

        Sounds like Melissa is voting for a fix for 1.9 too.

        Link to my branch with the 1.9 patch:
        https://github.com/peterbulmer/moodle/tree/MDL-36838-FF17-MNETSSO-19

        Link to the diff page:
        https://github.com/peterbulmer/moodle/commit/8d033c2d9e55367eb2b90b5458a07992ec46c23e

        I've tested this on a 1.9 to 2.0 moodle-moodle mnet connection with FF17, (where both moodles have my patches applied), and everything seemed to work nicely.

        I'm not sure if I can do a new integration review request while there is still one active, or if that could slow down progress on the 2.x branches. Possibly best to sort 1.9 after the patch has landed in the 2.x branches.

        Thoughts?

        Show
        Peter Bulmer added a comment - Sounds like Melissa is voting for a fix for 1.9 too. Link to my branch with the 1.9 patch: https://github.com/peterbulmer/moodle/tree/MDL-36838-FF17-MNETSSO-19 Link to the diff page: https://github.com/peterbulmer/moodle/commit/8d033c2d9e55367eb2b90b5458a07992ec46c23e I've tested this on a 1.9 to 2.0 moodle-moodle mnet connection with FF17, (where both moodles have my patches applied), and everything seemed to work nicely. I'm not sure if I can do a new integration review request while there is still one active, or if that could slow down progress on the 2.x branches. Possibly best to sort 1.9 after the patch has landed in the 2.x branches. Thoughts?
        Hide
        David Mudrak added a comment -

        Hi guys. Thanks for your work on this. I just left a comment at https://github.com/peterbulmer/moodle/commit/1c65f683dc0a52e47fdf68e952c832d7c63e03a0

        I agree with Melissa, this is a clear regression of a patch that landed in 1.9. It would not be fair to ignore this IMHO.

        Show
        David Mudrak added a comment - Hi guys. Thanks for your work on this. I just left a comment at https://github.com/peterbulmer/moodle/commit/1c65f683dc0a52e47fdf68e952c832d7c63e03a0 I agree with Melissa, this is a clear regression of a patch that landed in 1.9. It would not be fair to ignore this IMHO.
        Hide
        Dan Poltawski added a comment -

        My +1 for 1.9 too.

        But, this isn't a regression of the 1.9 patch, that doesn't make any difference. Its a regression of the hack from firefox

        Show
        Dan Poltawski added a comment - My +1 for 1.9 too. But, this isn't a regression of the 1.9 patch, that doesn't make any difference. Its a regression of the hack from firefox
        Hide
        Michaela Blomberg added a comment -

        thanks für the fix for 1.9, works perfect!

        Show
        Michaela Blomberg added a comment - thanks für the fix for 1.9, works perfect!
        Hide
        Peter Bulmer added a comment -

        Michaela,
        *Thanks for taking the time to report a successful test

        Pete

        Show
        Peter Bulmer added a comment - Michaela, *Thanks for taking the time to report a successful test Pete
        Show
        Dan Poltawski added a comment - https://bugzilla.mozilla.org/show_bug.cgi?id=815446
        Hide
        Dan Poltawski added a comment -

        So, the proposal is to fix this in:

        1.9.x, 2.1.x, 2.2.x, 2.3.x & 2.4.

        Show
        Dan Poltawski added a comment - So, the proposal is to fix this in: 1.9.x, 2.1.x, 2.2.x, 2.3.x & 2.4.
        Hide
        Dan Poltawski added a comment -

        Thanks, i've integrated this to 1.9.19+, 2.1.10, 2.2.7, 2.3.4 and 2.4

        Show
        Dan Poltawski added a comment - Thanks, i've integrated this to 1.9.19+, 2.1.10, 2.2.7, 2.3.4 and 2.4
        Hide
        Dan Poltawski added a comment -

        However, after I integrated this. Eloy raised the point about your comment on github, which i'd like to bring here:

        Peter, you say:

        > When the session is selected, or updated, it is done so while respecting that only the session with the same UA hash should be selected/updated.

        But on logout, it looks like we don't pay any attention to hash at all and all sessions related to that user are logged off. In many ways that seems like desireably behaviour, but it does seem different behaviour?

        Show
        Dan Poltawski added a comment - However, after I integrated this. Eloy raised the point about your comment on github, which i'd like to bring here: Peter, you say: > When the session is selected, or updated, it is done so while respecting that only the session with the same UA hash should be selected/updated. But on logout, it looks like we don't pay any attention to hash at all and all sessions related to that user are logged off. In many ways that seems like desireably behaviour, but it does seem different behaviour?
        Hide
        Peter Bulmer added a comment -

        Argh.
        Yes, that is different behaviour.

        I have also just realised that the "kill_children" function can be called either locally, or over mnet.
        I had thought that that was only called locally, and made some assumptions based on that. Still digesting the implications there.

        Pete.

        Show
        Peter Bulmer added a comment - Argh. Yes, that is different behaviour. I have also just realised that the "kill_children" function can be called either locally, or over mnet. I had thought that that was only called locally, and made some assumptions based on that. Still digesting the implications there. Pete.
        Hide
        David Mudrak added a comment -

        Well. Let us admit that the situation with two separate sessions in two browsers is not really typical use case and was raised more as a theoretical question. Also, killing all sessions on one logout can actually be seen as an expected/requested behaviour. Better to kill a session in the other browser than to forget about it at the end of a lesson in the school computer lab (when bad boys from the other class are already waiting outside the room, looking forward to seek for stations with active logins to Facebook and Mahara). If I understand the situation correctly, I personally do not see it as an issue.

        What caught my eyes is the other comment:

        I've tested this on a 1.9 to 2.0 moodle-moodle mnet connection with FF17, (where both moodles have my patches applied), and everything seemed to work nicely.

        I think this should be also tested against Mahara and eventually unpatched Moodle 1.9/2.x too. To at least know how it behaves. There was a plan discussed that we could revert FF 17 hack and send the same UA string as the other side sees (be it unpatched Moodle or Mahara). Is this still a to do task? Or was it dropped?

        Show
        David Mudrak added a comment - Well. Let us admit that the situation with two separate sessions in two browsers is not really typical use case and was raised more as a theoretical question. Also, killing all sessions on one logout can actually be seen as an expected/requested behaviour. Better to kill a session in the other browser than to forget about it at the end of a lesson in the school computer lab (when bad boys from the other class are already waiting outside the room, looking forward to seek for stations with active logins to Facebook and Mahara). If I understand the situation correctly, I personally do not see it as an issue. What caught my eyes is the other comment: I've tested this on a 1.9 to 2.0 moodle-moodle mnet connection with FF17, (where both moodles have my patches applied), and everything seemed to work nicely. I think this should be also tested against Mahara and eventually unpatched Moodle 1.9/2.x too. To at least know how it behaves. There was a plan discussed that we could revert FF 17 hack and send the same UA string as the other side sees (be it unpatched Moodle or Mahara). Is this still a to do task? Or was it dropped?
        Hide
        Dan Poltawski added a comment -

        FYI: Firefox have now decided to reverse their UA change globally in 17.0.1, so this issue sort of goes away (see https://bugzilla.mozilla.org/show_bug.cgi?id=815446). They point out that the UA is still the new style for their mobile browsers (so MDL-35469 is still worthwhile).

        However, we've committed the changes now, so we need find a way forward with these changes!

        Show
        Dan Poltawski added a comment - FYI: Firefox have now decided to reverse their UA change globally in 17.0.1, so this issue sort of goes away (see https://bugzilla.mozilla.org/show_bug.cgi?id=815446 ). They point out that the UA is still the new style for their mobile browsers (so MDL-35469 is still worthwhile). However, we've committed the changes now, so we need find a way forward with these changes!
        Hide
        Dan Poltawski added a comment -

        Pete: with this in mind, it'd be good to hear what you think the best way forward is with this. (Leaving the UA relaxation, or reverting)

        Show
        Dan Poltawski added a comment - Pete: with this in mind, it'd be good to hear what you think the best way forward is with this. (Leaving the UA relaxation, or reverting)
        Hide
        Peter Bulmer added a comment -

        Been talking to DanP, and Hugh Davenport (Mahara).
        Summary:

        Scenario: a user who has two browsers open (FF & IE), logged in to Moodle1 with the same username on both, and both mnet sso to Moodle2. User clicks logout on the Moodle1 in Chrome, our change will mean that they are logged out everywhere, not just the instances in chrome.

        As DavidM says above, not a typical use case.
        As an educated user of webapps, this isn't what I would expect to happen. Dunno about Jo-average-user.

        To further complicate things is the scenario of one user being logged into two computers in a computer lab. Even with unpatched Moodles/Maharas they click logout on one computer, they will be logged out of their mnet sessions on the other if their useragents match. (which is quite common where there is good patch management going on). This is potentially much more common than the two browsers with different useragents on one computer.

        So, that said, should we be keep these patches? I think so. Keen to hear others views.

        For certain, I think that the mnet session info should be linked from the user's session file, not driven off user agent.

        Show
        Peter Bulmer added a comment - Been talking to DanP, and Hugh Davenport (Mahara). Summary: Scenario: a user who has two browsers open (FF & IE), logged in to Moodle1 with the same username on both, and both mnet sso to Moodle2. User clicks logout on the Moodle1 in Chrome, our change will mean that they are logged out everywhere, not just the instances in chrome. As DavidM says above, not a typical use case. As an educated user of webapps, this isn't what I would expect to happen. Dunno about Jo-average-user. To further complicate things is the scenario of one user being logged into two computers in a computer lab. Even with unpatched Moodles/Maharas they click logout on one computer, they will be logged out of their mnet sessions on the other if their useragents match. (which is quite common where there is good patch management going on). This is potentially much more common than the two browsers with different useragents on one computer. So, that said, should we be keep these patches? I think so. Keen to hear others views. For certain, I think that the mnet session info should be linked from the user's session file, not driven off user agent.
        Hide
        Peter Bulmer added a comment -

        .. but thats a change for another day.

        As mentioned above kill_children can be called over mnet, but hasn't yet received a change.

        This can have an effect in the following scenario:

        User on FF17.0.0, logs in to MoodleA, roams to MoodleB, back to MoodleA, then on to Mahara. Clicks logout on Mahara. User will be logged out on Mahara, and MoodleA, but not MoodleB. (even if everything is patched with current patches).

        It's a small extension of the patch to get kill_children to ignore useragent too. Not sure what the process is if I do further changes to branches - new integration request? I shouldn't bother if we want to revert patches.

        Again, thoughts?

        Show
        Peter Bulmer added a comment - .. but thats a change for another day. As mentioned above kill_children can be called over mnet, but hasn't yet received a change. This can have an effect in the following scenario: User on FF17.0.0, logs in to MoodleA, roams to MoodleB, back to MoodleA, then on to Mahara. Clicks logout on Mahara. User will be logged out on Mahara, and MoodleA, but not MoodleB. (even if everything is patched with current patches). It's a small extension of the patch to get kill_children to ignore useragent too. Not sure what the process is if I do further changes to branches - new integration request? I shouldn't bother if we want to revert patches. Again, thoughts?
        Hide
        Hugh Davenport added a comment -

        Just to add to Pete's comment.

        I agree that it should be based on the users session not the user agent, because you could potentially use the same browser user agent on two different computers (or even the same with "pr0n" mode on).

        That said, I'm aware that MNet may DIAF sometime soon (any idea when? so we can judge what to do on the mahara side).

        Cheers,

        Hugh

        Show
        Hugh Davenport added a comment - Just to add to Pete's comment. I agree that it should be based on the users session not the user agent, because you could potentially use the same browser user agent on two different computers (or even the same with "pr0n" mode on). That said, I'm aware that MNet may DIAF sometime soon (any idea when? so we can judge what to do on the mahara side). Cheers, Hugh
        Hide
        Dan Poltawski added a comment -

        Hi Hugh

        > That said, I'm aware that MNet may DIAF sometime soon (any idea when? so we can judge what to do on the mahara side).

        No timescales at the moment - when we've worked with you guys for an alternate solution, is the short answer.

        Show
        Dan Poltawski added a comment - Hi Hugh > That said, I'm aware that MNet may DIAF sometime soon (any idea when? so we can judge what to do on the mahara side). No timescales at the moment - when we've worked with you guys for an alternate solution, is the short answer.
        Hide
        Frédéric Massart added a comment -

        Assigning to Mark as he has the environment set up for this.

        Show
        Frédéric Massart added a comment - Assigning to Mark as he has the environment set up for this.
        Hide
        Mark Nelson added a comment -

        Hi Guys, this patch does indeed fix this issue. I only tested on master but I spoke to Dan and he said that this was fine.

        Show
        Mark Nelson added a comment - Hi Guys, this patch does indeed fix this issue. I only tested on master but I spoke to Dan and he said that this was fine.
        Hide
        Eloy Lafuente (stronk7) added a comment - - edited

        While it's true that relying on the UA as session identifier is far from perfect, at least it allows the same user, using different browsers, to have multiple sessions opened and close them independently (note I don't know if there is a reason for that use case, but it's possible).

        With the patch, necessary because of the UA change only, we assumed that the only solution was to close all the sessions together (breaking the use case commented above).

        So, if the UA has been reverted by FF people, I vote about to revert this too, to keep the use case working at it was before. That said assuming that this issues was not fixing anything else but the FF's UA thing.

        +1 to revert

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - - edited While it's true that relying on the UA as session identifier is far from perfect, at least it allows the same user, using different browsers, to have multiple sessions opened and close them independently (note I don't know if there is a reason for that use case, but it's possible). With the patch, necessary because of the UA change only, we assumed that the only solution was to close all the sessions together (breaking the use case commented above). So, if the UA has been reverted by FF people, I vote about to revert this too, to keep the use case working at it was before. That said assuming that this issues was not fixing anything else but the FF's UA thing. +1 to revert Ciao
        Hide
        Dan Poltawski added a comment -

        OK, based on discussion we have decided to revert and reopen this.

        Show
        Dan Poltawski added a comment - OK, based on discussion we have decided to revert and reopen this.
        Hide
        Dan Poltawski added a comment -

        I'm reopening this and I propose that we close this wont-fix.

        Does anyone think it should be left open?

        Show
        Dan Poltawski added a comment - I'm reopening this and I propose that we close this wont-fix. Does anyone think it should be left open?
        Hide
        Dan Poltawski added a comment -

        Thanks a lot for all the work on this issue everyone!

        I think firefox outcome is probably the least evil overall solution for everyone.

        Show
        Dan Poltawski added a comment - Thanks a lot for all the work on this issue everyone! I think firefox outcome is probably the least evil overall solution for everyone.
        Hide
        Hugh Davenport added a comment -

        Dependant on when MNet dies, and when FF decide to reimplement the UA change. FF is discussing between a year, or longer. If MNet is likely to outlive that, then shouldn't be wontfix, and instead we should come up with a workable solution that doesn't involve UA checking.

        Cheers,

        Hugh

        Show
        Hugh Davenport added a comment - Dependant on when MNet dies, and when FF decide to reimplement the UA change. FF is discussing between a year, or longer. If MNet is likely to outlive that, then shouldn't be wontfix, and instead we should come up with a workable solution that doesn't involve UA checking. Cheers, Hugh
        Hide
        Matthew N added a comment -

        I agree that if MNet isn't going to die soon, the MNet code should be improved to not rely on the UA string at all and instead use sessions.

        Show
        Matthew N added a comment - I agree that if MNet isn't going to die soon, the MNet code should be improved to not rely on the UA string at all and instead use sessions.
        Hide
        Dan Poltawski added a comment -

        Hi Hugh,

        My understanding is that this firefox change will be in a matter of days, not a year!!

        Show
        Dan Poltawski added a comment - Hi Hugh, My understanding is that this firefox change will be in a matter of days, not a year!!
        Hide
        Matthew N added a comment -

        Hugh was referring to dropping the useless date from the UA string again in a few years (the change that was just reverted because of broken websites).

        Show
        Matthew N added a comment - Hugh was referring to dropping the useless date from the UA string again in a few years (the change that was just reverted because of broken websites).
        Hide
        Hugh Davenport added a comment -

        Hi Dan,

        That is for the revert of that change, but they plan to put that change back in some future release. https://bugzilla.mozilla.org/show_bug.cgi?id=815743 comments 33, 34, 36 are relevant

        Show
        Hugh Davenport added a comment - Hi Dan, That is for the revert of that change, but they plan to put that change back in some future release. https://bugzilla.mozilla.org/show_bug.cgi?id=815743 comments 33, 34, 36 are relevant
        Hide
        Dan Poltawski added a comment -

        Ah well, in a few years the UA hack for Moodle shouldn't be necessary because everyone has updated and so we shouldn't have a problem then?

        If they reintroducing it needing to add a UA hack again would seem kinda stupid

        Show
        Dan Poltawski added a comment - Ah well, in a few years the UA hack for Moodle shouldn't be necessary because everyone has updated and so we shouldn't have a problem then? If they reintroducing it needing to add a UA hack again would seem kinda stupid
        Hide
        Hugh Davenport added a comment -

        Anything else reliant on the user agent apart from the text editor?

        course/dndupload.js line 745,923 maybe?
        quite a bit in lib/yuilib depends on tests such as UA.gecko < 1.9
        lib/typos3 seems to use useragent

        lib/tests have a lot of stuff with the old gecko useragent, should this be updated/expanded?

        These were just at a quick look at `git grep -i -E user_?agent` and `git grep -i gecko`

        Cheers,

        Hugh

        Show
        Hugh Davenport added a comment - Anything else reliant on the user agent apart from the text editor? course/dndupload.js line 745,923 maybe? quite a bit in lib/yuilib depends on tests such as UA.gecko < 1.9 lib/typos3 seems to use useragent lib/tests have a lot of stuff with the old gecko useragent, should this be updated/expanded? These were just at a quick look at `git grep -i -E user_?agent` and `git grep -i gecko` Cheers, Hugh
        Hide
        Eloy Lafuente (stronk7) added a comment -

        About the tests, if I'm not wrong, they are there to verify that we are sniffing the browser properly, no matter if it's using the new (now reverted) or the old UA. So there are cases for all them, verifying they lead to the correct result.

        About the other cases, I don't know much, ciao

        Show
        Eloy Lafuente (stronk7) added a comment - About the tests, if I'm not wrong, they are there to verify that we are sniffing the browser properly, no matter if it's using the new (now reverted) or the old UA. So there are cases for all them, verifying they lead to the correct result. About the other cases, I don't know much, ciao
        Hide
        Dan Poltawski added a comment -

        Hugh, we have a another bug about that: http://tracker.moodle.org/browse/MDL-36316

        Show
        Dan Poltawski added a comment - Hugh, we have a another bug about that: http://tracker.moodle.org/browse/MDL-36316
        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
        Dan Poltawski added a comment -

        Hi,

        I'm closing this as won't fix as now firefox have completely reverted this UA switch (and the workaround) so it shouldn't be a problem any more.

        Show
        Dan Poltawski added a comment - Hi, I'm closing this as won't fix as now firefox have completely reverted this UA switch (and the workaround) so it shouldn't be a problem any more.

          People

          • Votes:
            6 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: