webPass is programmed to only trigger once per tab. You hit the login page -webPass gets notified by the browser that a page loads. It injects creds. You fail - end up back at the same url. At that point, webPass does NOT receive a notification that anything happened because it came from the cache. However the browser decides to pull the version from the cache with the creds injected (meaning it tries over and over again and webPass only got to play on the first request).

We have been seeing this happen in Chrome more than other browsers lately. It has to do with their cache.
You can usually get around this with a fake parameter. This is a parameter that you add that the website normally does not use. Sometimes, depending on how the developer of the site did their code you may have to go a little further.

An example url is https://someapp.example-cloud.com/Login_Student_PXP.aspx

Have the login page on the form be this : https://someapp.example-cloud.com/Login_Student_PXP.aspx?wn=y

The trigger will then be: https://someapp.example-cloud.com/Login_Student_PXP.aspx\?wn=y

That typically will fix the problem unless the developer of the site grabs the parameters and puts them in the submit form. If that is the case - after it fails a login, you'll see it goes right back to the wn=y version (and triggers over and over).

That is because they have a form element in the page like this: <form name="Form1" method="post" action="Login_Student_PXP.aspx?wn=y" id="Form1">

Using the script in the form, put something like this to change that action to the page without the parameter.

document.getElementById( "Form1" ).action = "Login_Student_PXP.aspx"";

That way the creds are submitted to the non wn=y page. If you fail you are on a page that shouldn't pull from the cache with credentials already in it and you should be good to go.