| Hmm, it seems like what I've observed (I only tried MacOS so far) is what's supposed to happen, and what you got is bugged; hopefully they'll fix that soon. In the case when the button does light up the instant it becomes clickable, I don't get the perception of ‘I've moved the mouse too far’ — instead, it's easier to see why the highlight isn't bigger: I don't just get a “hint of the area I can target”, I see exactly a standard-sized button, which I'm aiming for — but when I miss a bit, there's also a bonus area where the click still works. Without the immediate feedback, the highlight seems ‘off’ (in the sense of displaced) in some arbitrary way. But really it's way more sophisticated (an overly pedantically detailed elaboration follows; I promise this is not apologetics on behalf of the Firefox UI designers, but illustrating a point I will attempt to make in the end and that I couldn't be bothered to put in fewer paragraphs out of sheer laziness): 1) There's a bonus area to the left. It's nice to have when you happened to click a bit too far to the left. But how far off you can be in that direction depends on the exact circumstances: E.g. in my case, in windowed mode I can approach the edge to within 1 or 2 px before the mouse cursor switches to ‘resize window’, whereas in fullscreen mode, I can go to 0 px, but pushing beyond that triggers the dock which otherwise lingers beyond that edge of the screen. So that's why it's a bonus area: It'll try to do the right thing, but it's not a promise that clicking there will work. And by directing your focus to the standard-sized button that would ordinarily be all you can click, it's more likely that you'll hit the intended target. 2) There's no bonus area to the right. Because the forward button is to the right. Instead of extending the standard-sized click target, hoping that this is what you meant to do, the GUI refuses to interpret your click as something that could be the exact opposite of what you meant to do. 3) There's a bonus area upwards. On MacOS, moving up even farther gets you to the buttons for closing and minimising the window, but they're a good few px away from the bottom of the title/tab bar, so we can approach that border all the way without risking a wrong click. 4) There's no bonus area downwards. Because that's where the web page you're viewing is, and making the top left corner of the page a link (e.g. to the home page of the site) is really common, so ignoring ambiguous clicks wins out over risking doing something you didn't want. Thank you for your attention — you made it to the end where I attempt to make a point: AFAICT, the click target is the exact same it has always been. I understand that it can be annoying that they removed the circle when you're used to the circle being there; but I assure you, the circle never was the actual clickable area — it was just the visual target you were aiming for. You want ”the limits of the button drawn”? The circle doesn't do that. The button is a rectangle, and the clickable area is another rectangle that is almost the same, but a bit more generous in exactly those cases where the extra leeway can't do any harm. > Wait, It's All Ohio? Always Has Been refers to an exploitable template in which two astronauts are in space. One looks at Earth and realizes the entire Earth is made up of something other than what is expected, and asks "Wait, it's all X?" The other astronaut, preparing a gun, says "Always has been." — https://knowyourmeme.com/memes/wait-its-all-ohio-always-has-... |
https://postimg.cc/ThCLM7mK
The button area is visible as soon as one hovers with the mouse over the button.
Above: when the new code is turned on.
Below: when the new code is turned off.
The problem is: the area covered on hover should match the clickable area. If left of the button can't be clicked, the button is wrongly positioned. If it is intentionally bigger, the visual feedback should match it. The new code doesn't do that.