webcompat / web-bugs

A place to report bugs on websites.
https://webcompat.com
Mozilla Public License 2.0
747 stars 67 forks source link

www.security.online-banking.hsbc.com.cn - "Continue" button functionality is broken #63200

Open seemebreakthis opened 3 years ago

seemebreakthis commented 3 years ago

URL: https://www.security.online-banking.hsbc.com.cn/gsa/SECURITY_LOGON_PAGE/

Browser / Version: Firefox 83.0 Operating System: Windows 10 Tested Another Browser: Yes Chrome

Problem type: Site is not usable Description: Buttons or links not working Steps to Reproduce: after entering a username, you are supposed to hit "continue" and it either shows a "user not found" or continue with password prompt. But on firefox the "continue" button simply does nothing.

Browser Configuration
  • None

From webcompat.com with ❤️

softvision-oana-arbuzov commented 3 years ago

Thanks for the report, I was able to reproduce the issue. URL: https://www.security.online-banking.hsbc.com.cn/gsa/SECURITY_LOGON_PAGE/ NoError image

Note: The issue is not reproducible on Chrome 87.0.4280.88.

Console: image

After disabling ETP: image

Tested with: Browser / Version: Firefox Nightly 85.0a1 (2020-12-07) Operating System: Windows 10 Pro

Moving to Needsdiagnosis for further investigation.

wisniewskit commented 3 years ago

This one is a doozy. There are a lot of red-herrings here, but ultimately the problem is that somehow, the Dojo require call in their form-submission handler never fires in Firefox, but does in Chrome:

function onSubmit(token) {
    require(['dojo/topic'],function(topic){       // Firefox gets here
        topic.publish("loader/show", token);  // but never gets here
    }); 
}

This is the callback which reCAPTCHA calls, and there is a token being passed in, so this doesn't seem to be related to reCAPTCHA itself, but their callback.

If I pause on all exceptions after onSubmit is called (before the request is called), I see this being called in their app_login.js, but failing:

runMapProg = function(targetMid, map){
    // search for targetMid in map; return the map item if found; falsy otherwise
    if(map){
        for(var i = 0; i < map.length; i++){
        if(map[i][2].test(targetMid)){ // TypeError: map[i][2].test is not a function
            return map[i];
        }
    }
    }
    return 0;
},

Chrome does not fail there, because it never even calls that function in the first place after the user clicks the "continue" button. It seems that the require call only needs to fetch anything in Firefox. It therefore makes sense that it only fails in Firefox, because this is the map array (along with the other variables):

map = [
    ​​"group/gpib/services/bijit/change_limits/templates/ChangeLimitsPrintFriendly.html",
    ​​"group/gpib/services/bijit/change_limits/cn/templates/ChangeLimitsPrintFriendly.html",
    ​​/^group\/gpib\/services\/bijit\/change_limits\/templates\/ChangeLimitsPrintFriendly\.html(\/|$)/
    80
​​​]
i = 0
targetMid = "dojo/topic"

Of course a string's second character has no test method, since it's not a regular expression. So this require call is doing something nonsensical. It appears that they are expecting map to be a list of entries like the one above, rather than one of them, but I can't see why they would expect that from their code.

This is the stack trace for when it reaches that code:

Dojo
  runMapProg
  getModuleInfo_
  getModuleInfo
  getModule
  contextRequire
  req
onSubmit    102:(index)
S       recaptcha__en.js:677
(etc)

But it's difficult to pin down why in such complicated code. Since Chrome isn't hitting this code, perhaps it's just an oversight? Altering runMapProg to handle that case seems to fix this:

runMapProg = function(targetMid, map){
    // search for targetMid in map; return the map item if found; falsy otherwise
    if(map){
        if (map.length > 2 && map[2].test) { // single-element case
            if(map[2].test(targetMid)){
                return map;
            }
        } else {
            for(var i = 0; i < map.length; i++){
            if(map[i][2].test(targetMid)){
                return map[i];
            }
        }
    }
    }
    return 0;
},

And since I don't see anything "wrong" with that, and Firefox is the only browser hitting that code, I wonder if this is just a coding oversight?

karlcow commented 3 years ago

@nileshprasad137 if you are still working for HSBC, could you help Mozilla find the right contact at HSBC to fix their login form currently not working in Firefox?

Thanks