Brain-hand response is not the same thing as a perceived delay.

Once latency becomes greater than 50ms, it becomes human noticeable -- aka "not instant."

Given that UI response isn't used to trigger human reflexes, you are just misunderstanding the intent.

From my first hand experience in FPS gaming in non-amateur settings the vast majority of average users will not be able to notice a (say) 50 ms difference in UI responsiveness. I covered that when talking about network latency in my previous post.

Of course this is just my experience, scientific findings may very well dispute my ignorance.

Correction, the vast majority of users will not be able to explain that they feel a responsiveness issue, but they do indeed feel it. Less hardcore gamers will often just blame other things -- loose controls, or ignored button presses, or what not.

I see it pretty regularly in playtests and such. Anyway, it's not something someone can simply say "Hey, this app took longer than 50ms to respond!" It's more of a gut feeling that something about it is slow.

They are likely aiming at the 50ms threshold because that's the point at which you really can't notice it, most of the time. At > 50ms, it becomes more and more noticeable, and by just 100ms people actively start complaining about the slowness of response.

edit:

As for the FPS gaming issue, the reality is that you don't notice it in FPS gaming because the games are built to hide it from you -- when you press your fire button, your gun fires, regardless of net latency. And that has been true for a very long time. I think the last game to really wait for server response before doing anything was Quake 3, and probably some of the Quake 3 engine games.

I could never stand Quake 3 for that reason, if you had anything higher than 30-40ms it started feeling like you weren't controlling the game.

Old hardcore quake3 player here. Q3 didn't wait for a server response, but the net-code was not that great and the interpolation did iirc not really take into account server responses. You could end up with players teleporting because of network issues. OSP was the first mod iirc that tried to fix it and it was somewhat successful.

The one mod that made great strides to fix the issues with the Q3 net-code was CPM (www.promode.org). 50-70ms to the server felt like 20-30ms in Vanilla Q3 and when you hit 20-30ms in CPM it felt like LAN play in VQ3. It fixed the niggling issues of lost packages (caused players to warp) as well. You even had some players that intentionally downloaded things in the background to cause dropped/delayed packets so that they would warp.

Eventually the net-code in CPM got so good the community even had cross-Atlantic competitions. The team I played in had 100-120 ping vs west-coast American teams on NYC servers and it was actually playable to the point where you could have fairly fair fights with them. Except against Team Abuse... :p. Man what a schooling in team-play and lock-downs of maps they gave my team.

"Correction, the vast majority of users will not be able to explain that they feel a responsiveness issue, but they do indeed feel it."

That sits well with me. Upvoted! It is true that "clunkiness" is a valid complain, but i've always attributed it to a combination of all latency-inducing factors.

Musicians will start to notice anything greater than about 7-10ms between keypress and sound. Below the threshold of consciously noticing the delay, it's still possible to make an instrument or UI feel subjectively "snappier" by reducing the delay further. If the browser is to host any audio-related applications, the minimum latency needs to be much lower than 50ms.

The 200ms braind-hand response time you are refering to is the time it takes to see a change on the screen, brain reacting and sending a signal to the hand and then to actually press the button. What the firefox roadmap is talking about is from the time the button was pressed until something changes on the screen. These are two different things and they actually add up. Then there's also the final delay between the changes happening on the screen and the brain recognizing this.

So the user experience delay is the sum of three different sub-delays. Firefox wants to improve it by reducing the middle part.

Brain-hand response isn't what it's about here: it's about synchronicity, the notion that clicking the mouse and effects on screen occurring at the same time. It's quite easy to see (and hear) relatively small differences between two events that are supposed to happen simultaneously.

For example, of my two monitors, one is lagged by one frame. I can see this easily by taking a white window against a black desktop, moving it so that it straddles both monitors, and moving it rapidly up and down: the monitor that's a frame slower makes the window look a bit like it's made of rubber, that it's bent away from the direction of motion. And that's just a 17ms difference in two events that are supposed to be simultaneous, an order of magnitude less than your factoid of 200ms.

In addition to the other points, you need some engineering buffer anyhow. Whatever system they are testing this number on, it probably won't be the bottom of the line they want Firefox to run on, and even if it is you still want good responsiveness anyhow. Because of the wide variance in the systems that run Firefox, this is probably less a principled number coming out of extensive research than a line in the sand. But a line in the sand is fine.

I think you have it backward. It's not about how long after you think of clicking do the action happen, it's how long after you did click can your brain start to see the result on screen. With that 100 ms you mention, and let's add another 100ms by the software, you get 200 ms between the time your brain wants to click and the time it start receiving a visual response (assuming that part is immediate, which it is not). It is actually a big selling point of google chrome, while a lot of it isn't really that much faster, it do seems instant and firefox does not (at least for some people, including me).

This might be a good read for such things: http://www.useit.com/papers/responsetime.html