Cero

@Vlad done

Has been fixed in the latest version, thank you!

Yeah that's a less confusing way of describing it lol.

saul Accessibility wise, yes it makes total sense. However (correct me if I'm wrong), with accessibility you aren't supposed to be confused as to whether it is a bug or not. If the intention is what you speak of, the bug doesn't exactly lie in the existence of the animation, but the animation itself. Instead of being a clear indicator that the focus has moved to the text, or even suggesting that the text is already focused, it just flashes the text moving back to center implying that it is glitching trying to un-focus the text.
I understand how this is working too (it is not intended).

When you click anything other than the LocationBarTextView it tries to change the focus of the search bar to being in idle (ie: No one is gonna be typing in it) However, where you're clicking matters because clicking the LocationBar changes the state of the search bar to focused. The problem is that two animations are trying to go at once, and the optimal call stack will cause the search bar to lose focus first. That causes the one triggered by the LocationBar to be invalidated, and instead of the properties being animated back to the side, it just teleports there as the time in the animation context has passed anyways.

I can't see this as being intended anyways as it requires you to click in obscure places to trigger.

All of this is up for speculation but that's just my opinion.

I can't reproduce this on the same version. The only thing I noticed was that it has a bit of lag when loading it as a top-hit, but that's not really an issue. Here's a screenshot:

Upon further inspection, this website suffers from this issue as well. But it may not be the exactly as I described it.

The overlap in this case occurs from the same issue. The property is set like so: min-width: 16px; while the actual width is 24px. Now, there is something that I should note that I didn't see at first, but that is the padding. If the width of the button was 20, that would make sense, as the left and right padding is set to four, but instead it is 24 which means that the actual left and right padding is 8 if the issue is with that and not with the min-width. What disproves my theory with it being a padding thing (if I have my facts straight) is that the padding is normal when adding enough characters to affect the size. As an example, I see the correct amount of space in between the span content and the border when I change the number to 100.

(Ignore the overlap for this as it is not an issue, just a side effect from having 100 notifications apparently LOL)

With this all in mind, I hope that the information has assisted you in finding the root cause of this.

Steps to reproduce:

Visit https://github.com and visit a repository from Orion. While doing the same on another browser of your choice, notice how the buttons are circles with around a width of 21.9-22 px on Firefox, exactly 20 px on Safari, but 34 px on Orion; The height is exactly 20 px on all three.

Expected behavior:

The expectancy is that the CSS matches up on all the browsers and the difference is minimal to a point where it isn't noticeable.

Orion, OS version; hardware type:

• Version 0.99.110-beta (WebKit 613.1.12)
• MacOS 12.0.1

Image/Video:

Before disabling min-width:

After disabling min-width

Have tested on the same person of Orion and can confirm that this issue is present. My guess is that the WKBackForwardList isn't saved with the current page when a tab is closed. The issue however, is with the restoration of the WKBackForwardList as it is not implemented on the WKWebView object as get/set. This shouldn't be an issue though since they use a custom build of webkit anyways. Nice find!

Steps to reproduce:

1. Click on the search field
2. When in focus, click in the empty space in between the bottom of the field and the LocationBarTextView (aka: the text)

Expected behavior:
Nothing. Possibly however the text could be selected at the mouse's x position or the cursor gets placed there. That would either require the bounds of the LocationBarTextView to stretch across the entire search field, or some wacky event listening. The former would also break text centering so idk.

Orion, OS version; hardware type:

MacOS 12.0.1

Image/Video:

Here you can see where exactly to click. Anything that isn't highlighted in blue will trigger the focus animation

PS: In safari, the text of the UnifiedFieldEditor is properly aligned to the vertical center of the search field. Here it is not.

Steps to reproduce:

1. Install the "Top Sites Button" extension.
2. Open it for the first time in a new window
3. Close the extension window and open it again

Expected behavior:

The expected behaviour from what I know would be for the size of the extension popover window to stay consistent.

Orion, OS version; hardware type:

MacOS 12.0.1, iMac 2020

Image/Video:

First Open in new window:

What it changes to:

Firefox screenshot (Size never changes):