Use of less than secure random numbers for 'a' during an SRP proof of password With Secure Remote Password protocol SRP6a random numbers are used for s, a and b. Where s is the salt registered with the user, a and b are random one time ephemeral keys of the user and host respectively. What would be the risk of letting some clients (old webbrowsers which don't have the WebCryptoAPI secure random numbers) perform a password proof using a which is less random than a good secure source. Lets say that they use the web browsers insecure Math.random and that is seeded with a timestamp. 

Superficially if a was simply a nonce, not even a weak random, then an attacker can gain very little. With each login attempt a unique B is sent by the server which can always use secure random numbers. This random B is used with the nonce a to create a new S, then from that a new M1 and M2 proof of a new shared key. 

Or is it the case that a being less than a high quality secure random would compromise the security of either the client or the server.  

(Edit: Note that sending a from the server opens you up to a server sending a crafted a, s and B to attack the password using a dictionary lookup of M1 to give the password so that is not something that anyone should consider doing. The question is about whether a needs to be truly random not a question about suggested sources of secure random numbers for a)
It seems like a better solution would be to have the server that is providing the Javascript file, also provide a random seed.  The Javascript can then use that random seed (and anything other maybe-random bits it can scrounge up, such as the output from Math.random()) to see a cryptographic PRNG, and then use the output of that crypto-PRNG for generating s, a, b.  After all, the server who sends you the Javascript has to be trusted anyway, so you might as well trust it to give you some random numbers, too.

See https://security.stackexchange.com/a/34425/971 for more on this.