Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 9a3dec2946c44efcf600159d35097df89f553f3c
https://github.com/WebKit/WebKit/commit/9a3dec2946c44efcf600159d35097df89f553f3c
Author: Sammy Gill <[email protected]>
Date: 2026-02-19 (Thu, 19 Feb 2026)
Changed paths:
A LayoutTests/fast/media/media-query-with-rem-expected.html
A LayoutTests/fast/media/media-query-with-rem.html
M Source/WebCore/css/CSSToLengthConversionData.cpp
M Source/WebCore/css/CSSToLengthConversionData.h
M Source/WebCore/css/query/MediaQueryEvaluator.cpp
Log Message:
-----------
GitHub.com: Profile icons can shift on commits page of a repo when increasing
layout zoom.
https://bugs.webkit.org/show_bug.cgi?id=308172
rdar://168700141
Reviewed by Brent Fulgham.
If you go to the commits page that is associated with a repository, such
as https://github.com/WebKit/WebKit/commits/main/, it is possible that
the profile icons associated with a commit may shift around as you
increase the layout zoom of a page (e.g. using cmd + plus). This
behavior seems to occur when the author and committer associated with a
commit are different, as the two different profile icons may end up
getting separated from each other depending on the viewport width and
zoom level.
This seems to be due to some styles associated with the following types
of media queries:
@media screen and (max-width:calc(48rem - .02px)) {
....
--avatar-stack-size: var(--stackSize-narrow)
}
@media screen and (min-width:48rem) {
...
--avatar-stack-size: var(--stackSize-regular)
}
It turns out that stackSize-narrow and stackSize-regular are the exact
same value, but when we increase the scale by a certain amount, we fail to
start applying the second media query. How this is exactly happening is
described alongside the reduced test case below, but basically, it is due
to the fact that when we resolve the 48rem for the second media query, we
end up applying zoom to it when we should not (for the first media query,
we do not apply zoom).
In MediaQueryEvaluator, we create a FeatureEvaluationContext that gets
passed around during media query evaluation. This object has a
CSSToLengthConversionData that gets used when we need to evaluate length
values for the media query, such as the ones above. It seems like the
intention is to not be taking zoom into consideration at all, since
the constructor associated with the CSSToLengthConversionData has a
comment saying that it is used to ignore zoom. This is because before we
evaluate the media query, we divide the size of the RenderView by its
usedZoom value. So if you apply a page scale factor of 2, as an example,
then the width of the RenderView will get halved for the purposes of
evaluating the media query.
In order to make sure this is done properly with respect to the rem unit, we
need to make sure that the conversion data is marked as
CSS::RangeZoomOptions::Unzoomed
to make sure it does not use the computed font size, which is what causes
the bug. Since 48rem is a font relative unit and the default value for
the CSS::RangeZoomOption is Default, we will end up using the computed
font size with zoom factored in.
* LayoutTests/fast/media/media-query-with-rem-expected.html
* LayoutTests/fast/media/media-query-with-rem.html
Assuming a viewport of 800px and a root font size of 16px. When the
content is unzoomed, we get a min-width value of 320 and end up correctly
applying the media query. When we set a page scale factor of 2, the width
of the RenderView ends up becoming 400, and the value associated with the
media query ends up becoming 720, which is incorrect since we end up
using the computed font size with zoom.
Canonical link: https://commits.webkit.org/307845@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
