WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
307933
workspaces.xyz: (Regression:
305212@main
) Hovering on menu makes it to be jumpy
https://bugs.webkit.org/show_bug.cgi?id=307933
Summary
workspaces.xyz: (Regression: 305212@main) Hovering on menu makes it to be jumpy
Ahmad Saleem
Reported
2026-02-14 22:04:25 PST
Hi Team, While looking into random websites, I noticed that with Safari Technology Preview 237, the below website menu is jumpy on hover on items. *** Steps to Reproduce *** 1. Go to
https://www.workspaces.xyz/
2. From header, hover on `Setups` and then hover on items in the menu list *** Expected Result *** No jump on animation while hovering on items. *** Actual Result *** Items jump while hovering on the items. **** Regression **** Does not reproduce on Safari 26.3. **** Other Browsers **** Does not reproduce on Chrome Canary 147. Just raising, so we can fix it. Thanks!
Attachments
Reduced Test Case
(332 bytes, text/html)
2026-02-16 12:12 PST
,
Sam Weinig
no flags
Details
Slightly different Reduced Test Case
(436 bytes, text/html)
2026-02-17 15:24 PST
,
Sam Weinig
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2026-02-14 22:04:44 PST
<
rdar://problem/170412045
>
Sam Weinig
Comment 2
2026-02-16 12:12:02 PST
Created
attachment 478378
[details]
Reduced Test Case
Sam Weinig
Comment 3
2026-02-17 10:47:03 PST
As far as I can tell, this is technically the correct behavior. Animations and Transitions are defined in terms of computed value, and since the definition of the border-width computed value changed due to
https://github.com/w3c/csswg-drafts/issues/11494
, the new behavior here is correct. That said, it is clearly unexpected, and not all that useful. I filed
https://github.com/w3c/csswg-drafts/issues/13511
with the CSSWG to discuss updating the specs to specify using the used values for animation and transitions. For now, I think we should switch to use the used values for checking for a transition property change, as that resolves the regression here and seems to be what at least Firefox is doing.
Sam Weinig
Comment 4
2026-02-17 11:12:00 PST
Pull request:
https://github.com/WebKit/WebKit/pull/58863
Sam Weinig
Comment 5
2026-02-17 15:24:07 PST
Created
attachment 478391
[details]
Slightly different Reduced Test Case
Sam Weinig
Comment 6
2026-02-17 15:43:19 PST
So, it turns out my install of Firefox was a bit old, so my analysis of it is wrong. As Emilio Cobos Álvarez pointed out in the CSSWG issue, Firefox behaves the same as ToT WebKit here, so Chrome is really the odd one out here. It might make more sense not to make this change right now, or implement this as a quirk for this website, if we feel it's that important. We should probably also reach out to the website.
Simon Fraser (smfr)
Comment 7
2026-02-17 16:37:48 PST
I think we should quirk this site.
Karl Dubost
Comment 8
2026-02-17 23:04:28 PST
I made a first attempt at contacting the website owner Ryan Gilbert through linkedin
Antti Koivisto
Comment 9
2026-02-18 06:24:24 PST
Pull request:
https://github.com/WebKit/WebKit/pull/58927
EWS
Comment 10
2026-02-18 10:21:49 PST
Committed
307770@main
(aeac793ec439): <
https://commits.webkit.org/307770@main
> Reviewed commits have been landed. Closing PR #58927 and removing active labels.
Antti Koivisto
Comment 11
2026-02-18 10:42:53 PST
So this was fixed with a site-specific quirk. The spec/Firefox compliant behavior remains.
EWS
Comment 12
2026-02-19 03:49:33 PST
Committed
305413.318@safari-7624-branch
(d93666fe0672): <
https://commits.webkit.org/305413.318@safari-7624-branch
> Reviewed commits have been landed. Closing PR #4505 and removing active labels.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug