1745595 - (CVE-2022-34479) Resize Popup Window Will Also Render Over the Address Bar leads to Address Bar Spoofing

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[Irvan Kurniawan [:sourc7]]

Attachment: spoof.bundle.html

After resize popup window using window.sizeToContent() on page with large margin top, surprisingly the address bar UI will pushed up and replaced with HTML5 page content, therefore it possible to spoof the address bar.

I can only reproduce this on Linux (X11 and Wayland) and WebRender enabled. But I couldn't reproduce this on WebRender (Software) or gfx.webrender.software set to true.

Tested on:

• Firefox Nightly 97.0a1 (2021-12-11) (64-bit) using Arch Linux KDE (X11 and Wayland) on Intel i5-1035G1 (1920x1080 DPI 125% and DPI 100%)
• Firefox Nightly 97.0a1 (2021-12-11) (64-bit) using Arch Linux KDE (X11) on AMD Ryzen PRO 4650G (2560x1440 DPI 125%)
• Firefox ESR 91.4.0esr (64-bit) using Arch Linux KDE (X11) on AMD Ryzen PRO 4650G (2560x1440 DPI 125%)

Steps to reproduce:

1. Visit attached spoof.bundle.html
2. Click "1920x1080" or "2560x1440"
3. Address bar is now spoofed with HTML5 page content

(Try to increase the marginTop on the testcase if Firefox popup address bar UI still appear on your display.)

Comment 1

[Irvan Kurniawan [:sourc7]]

Attachment: Firefox - window.sizeToContent() resize leads to address bar spoofing.mp4

Comment 2

[:Gijs (he/him)]

Moving to graphics given this is behaving differently on webrender software vs. general webrender.

Comment 3

[Daniel Veditz [:dveditz]]

The popup is in an odd security state: even though the url is https://bug1745595.bmoattachments.org/etc -- there's a "document" icon (neither a locked lock, or a "not secure") and when clicked it claims the document is "about:blank" and no TLS/cert info. That would be independent of the graphics issue.

The above was on Mac where I can't reproduce the problem in this bug -- I see the real URL bar. Guess we should spin off a separate bug for that.

Tyson tried on Ubuntu Linux (Gnome) and couldn't reproduce. Unique to KDE? Unique to Arch linux? We need to narrow that down. Calling "moderate" for now because the target audience seems limited, but we can revise if we learn more.

Comment 4

[Irvan Kurniawan [:sourc7]]

(In reply to [Back in January] Daniel Veditz [:dveditz] from comment #3)

Tyson tried on Ubuntu Linux (Gnome) and couldn't reproduce. Unique to KDE? Unique to Arch linux? We need to narrow that down. Calling "moderate" for now because the target audience seems limited, but we can revise if we learn more.

Thanks Dan for the update, it turns out it only affect window protocol x11 and xwayland.

On Arch Linux KDE (Wayland) the Firefox window protocol default to xwayland, after set environment MOZ_ENABLE_WAYLAND=1 and window protocol changed from xwayland to wayland I unable reproduce the issue.

I confirm I able to reproduce the issue on Ubuntu 21.10 after switch to "Ubuntu on Xorg" on user login or after logout.

(In reply to description)

Firefox Nightly 97.0a1 (2021-12-11) (64-bit) using Arch Linux KDE (X11 and Wayland) on Intel i5-1035G1 (1920x1080 DPI 125% and DPI 100%)

Sorry I was mistakenly think that xwayland same as wayland, turns out it's different.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Jim Mathies [:jimm]]

sec-mod, and xwayland is not a popular config. Maybe the redhat folks can take a look?

Comment 7

[Gian-Carlo Pascutto [:gcp]]

Hmm, comment 4 claims it affects x11, which is the default.

Comment 8

[Gian-Carlo Pascutto [:gcp]]

I can reproduce this on my (K)Ubuntu 21.10 in X11. I don't know if that's the default for that release (it is what I'm using!), but surely current Ubuntu LTS is using X11?

If that's the case there may be an argument this is a sec-high? Alexandre, do you have stats of the distro usage and X11 vs Wayland?

Comment 9

[Gian-Carlo Pascutto [:gcp]]

As for Wayland vs XWayland, our own builds only default to Wayland as of bug 1749174.

Fedora and Ubuntu switched to Wayland a while ago, but I think that's after the Ubuntu LTS. Fedora has no LTS so they're probably good There's this thing called RHEL :-/

Comment 10

[Gian-Carlo Pascutto [:gcp]]

Martin, I know that this probably doesn't affect Fedora (but it likely affects RHEL!). Would you or someone from your team be willing to take this with the appropriate urgency? I think you're the most familiar with this code at this point.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

I'll try some RHEL.

Comment 12

[:gerard-majax]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #8)

I can reproduce this on my (K)Ubuntu 21.10 in X11. I don't know if that's the default for that release (it is what I'm using!), but surely current Ubuntu LTS is using X11?

If that's the case there may be an argument this is a sec-high? Alexandre, do you have stats of the distro usage and X11 vs Wayland?

as shared on matrix: https://sql.telemetry.mozilla.org/queries/84095/source#208316

Comment 13

[Gian-Carlo Pascutto [:gcp]]

FWIW we publicly shared these stats today: https://www.phoronix.com/scan.php?page=news_item&px=Firefox-Wayland-X11-Stats

Comment 14

[Jan Horak [:jhorak]]

I'm unable to reproduce in RHEL 8.5/firefox 91.5.0esr. I got:
Compositing: Webrender (non software) - I had to set gfx.webrender.enabled to true to make it working
Intel driver
Window Protocol: xwayland

Comment 15

[Irvan Kurniawan [:sourc7]]

I recently checked this is still reproducible in Firefox Nightly 100.0a1 (2022-04-01) (64-bit) on Arch Linux (KDE x11). Is there any update on this?

Comment 16

[:Gijs (he/him)]

(In reply to Irvan Kurniawan (:sourc7) from comment #15)

I recently checked this is still reproducible in Firefox Nightly 100.0a1 (2022-04-01) (64-bit) on Arch Linux (KDE x11). Is there any update on this?

--> :gcp . Looks like this is now sec-high and it's been a few months. You could reproduce - do we know where to start looking for a fix?

Comment 17

[Gian-Carlo Pascutto [:gcp]]

No. (I know this is sad, but we don't have a lot of GTK skill in house right now, let alone availability)

Comment 18

[Gian-Carlo Pascutto [:gcp]]

Martin, does it affect RHEL? Are you able to assist here?

Comment 19

[Martin Stránský [:stransky] (ni? me)]

Hello Gian-Carlo,
we tested that on RHEL and it's not affected by this issue (see https://bugzilla.mozilla.org/show_bug.cgi?id=1745595#c14).
May that be something Ubuntu specific then?

Comment 20

[Irvan Kurniawan [:sourc7]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #19)

Hello Gian-Carlo,ww
we tested that on RHEL and it's not affected by this issue (see https://bugzilla.mozilla.org/show_bug.cgi?id=1745595#c14).
May that be something Ubuntu specific then?

I'm recently installed RHEL 8.5 on my machine, then set gfx.webrender.enabled to true on preinstalled Firefox 91.7.0esr.

After tweaking the testcase, finally I also able to reproduce this on RHEL 8.5, xwayland. I'll share the updated testcase soon.

Comment 21

[Irvan Kurniawan [:sourc7]]

Attachment: spoof.bundle2.html

Alright here the updated testcase. I've tested this works on RHEL 8.5 on Laptop i5-1035G1 (1920x1080) and VirtualBox Guest (1920x1080 and 2560x1440) reproduced on Firefox 91.7.0esr and Firefox Nightly 100.0a1 (Compositing: WebRender and Window Protocol: xwayland).

Hi Martin can you try the updated testcase on your machine?

If it still doesn't work, try increase the marginTop and the resize function iteration. Thanks!

Comment 22

[Irvan Kurniawan [:sourc7]]

Attachment: Screenshot_20220404_211041.png

Attached screenshot demonstration reproduced in Firefox 91.7.0esr (64-bit) WebRender enabled on RHEL 8.5 using spoof.bundle2.html.

Comment 23

[Jan Horak [:jhorak]]

With the spoof.bundle2.html I can reproduce the issue only when gfx.webrender.enabled=true. I've tried browser toolbox to locate the box with toolbar and it seems to be above the page content. I don't see any differences in position in the DOM in browser toolbox. I can do further debugging if desired, please let me know what more I can do for you.

Comment 24

[Jan Horak [:jhorak]]

I can also reproduce with upstream binary of Firefox 99.

Comment 25

[Karl Tomlinson (:karlt back Feb 10)]

I can reproduce on KDE with a single 3840x2160 monitor, echo Xft.dpi: 192.0 | xrdb -merge, and marginTop = 960 or 920 depending on whether the task bar is always visible or not.

This doesn't seem to be related to the invalidation bug often seen on presenting new windows as focus changes do not change the rendering.

This reproduces on 91.0a1 (2021-06-10), but tabs on earlier nightlies are crashing for me.

The effect is as if the window is sized too large for the display and then shrunk, but the content rendered by Firefox is not adjusted. Any subsequent resize of the window by window manager controls corrects the rendering and a scroll bar is presented.

The bug does not demonstrate the same symptoms with gfx.webrender.software:true, but the scroll bar is still not visible until a subsequent resize of the window. The difference may be that with non-software webrender the top of the window is clipped, but the bottom of the window is clipped with software webrender. Adding some text to the testcase and attempting to select the text indicates that hit testing is consistent with rendering when gfx.webrender.software:true but not when false.

Comment 26

[Karl Tomlinson (:karlt back Feb 10)]

Attachment: output from MOZ_LOG=Widget:4 mozregression --launch 2022-04-01 --process-output stdout | grep -v expose

The problem can be seen at the end of the log.
Here, the size from the configure event is dispatched to layout correctly.

configure event 6,36 -> 3828 x 2118 scale 1'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
moz_container_size_allocate [7f2fea8c5400] 0,0 -> 3828 x 2118'
nsWindow::OnSizeAllocate 0,0 -> 3828 x 2118'
nsWindow::DispatchResized() size [3828, 2118]'
GetScreenBounds 0,0 -> 3828 x 2118, unscaled 0,0 -> 3828 x 2118'
GetScreenBounds 0,0 -> 3828 x 2118, unscaled 0,0 -> 3828 x 2118'
GetScreenBounds 0,0 -> 3828 x 2118, unscaled 0,0 -> 3828 x 2118'

The browser then requests that the window be made larger, and optimistically tells layout that the window will be larger:

nsWindow::SetSizeMode 0'
    already set'
nsWindow::Resize 3840.000000 2190.000000'
nsWindow::ResizeInt x:0 y:0 -> w:3840 h:2190 aMove 0'
  ConstrainSize: w:3840 h;2190'
nsWindow::NativeMoveResize move 0 resize 1 to 0,0 -> 3840 x 2190'
nsWindow::DispatchResized() size [3840, 2190]'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'

A configure event notifies the browser that the request for a larger window was denied, but this is not passed on to layout:

configure event 6,36 -> 3828 x 2118 scale 1'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'

Comment 27

[Karl Tomlinson (:karlt back Feb 10)]

This problem of ending up with an incorrect optimistic size from a request that is never effected has shown up before.
The fix designed for that resolves the issue for attachment 9270710 [details], but does not address the whole problem: the same effect can still be produced by increasing the number and frequency of sizeToContent() calls. That's because GTK doesn't necessarily send a configure request from which to expect a configure notify event: "If the configure request has not changed, we don't ever resend it, because it could mean fighting the user or window manager."

Changing the behavior to only update widget sizes (mBounds) for managed windows after resizes are confirmed leads to many test failures in tests expecting synchronous application of sizes.

Keeping the behavior of optimistically and synchronously presuming resize sizes for resizes before the first size-allocate (but still changing behavior of later resizes) leads to a much smaller set of failures.

Comment 28

[Karl Tomlinson (:karlt back Feb 10)]

Attachment: Bug 1745595 - type ResizeInt() parameters to specify units r?stransky

Comment 29

[Karl Tomlinson (:karlt back Feb 10)]

Attachment: Bug 1745595 record window size changes from app-initiated resizes asynchronously after the first size-allocate r?stransky

This provides a consistent order of bounds changes corresponding to resize
event notifications. Previously the size reported in bounds could bounce as
requested sizes were saved, then overwritten in OnSizeAllocate() with
previously queued sizes, and then usually eventually rewritten with the final
size in OnSizeAllocate() again.

Depends on D147727

Comment 30

[Karl Tomlinson (:karlt back Feb 10)]

Attachment: Bug 1745595 wait for expected geometry after move or resize r?whimboo

The requestAnimationFrame() callback used in IdlePromise() may run sooner than
1/60 second, providing insufficient time for changes to be effected.
https://searchfox.org/mozilla-central/rev/e567185fa464270f94430e7cf62d134f4df9a69f/layout/base/nsRefreshDriver.cpp#1730-1731

Waiting for the "resize" and "MozUpdateWindowPos" events should provide
minimum wait in the common cases that the OS completes the changes requested.

This change should also resolve
https://bugzilla.mozilla.org/show_bug.cgi?id=1702255

Depends on D147728

Comment 31

[Karl Tomlinson (:karlt back Feb 10)]

Attachment: Bug 1745595 - wait for resize to complete before getting font size r?niklas

With the associated widget/gtk/nsWindow.cpp changes, this should also resolve
https://bugzilla.mozilla.org/show_bug.cgi?id=1766919 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1766991

Depends on D147729

Comment 32

[Karl Tomlinson (:karlt back Feb 10)]

Attachment: Bug 1745595 - wait for resize to complete before adding media query r?daisuke

This and the associated widget/gtk/nsWindow.cpp changes may also help with
https://bugzilla.mozilla.org/show_bug.cgi?id=1723436

Depends on D147730

Comment 33

[Karl Tomlinson (:karlt back Feb 10)]

Comment on attachment 9278899 [details]
Bug 1745595 record window size changes from app-initiated resizes asynchronously after the first size-allocate r?stransky

Security Approval Request

• How easily could an exploit be constructed based on the patch?: There are some hints here about the resize not being honored by the OS.
  What is not mentioned is that the chrome can be missing in some such situations.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Unknown
• Which older supported branches are affected by this flaw?: All
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Backports will likely need hand crafting for at least some specific branches due to frequent/recent changes in the code.
  The same approaches should be generally applicable.
• How likely is this patch to cause regressions; how much testing does it need?: This is high risk. The code has seen high turnover due to many different edge cases.

Testing would focus on X11 and Wayland Linux platforms.
Popup sizing and positioning would be tested with different chrome UI popup windows, opened from different positions and resized where possible (e.g. bookmarks popup).

Changes to other platforms involve only Geckodriver, not typical usage, and are well covered by automated tests.

• Is Android affected?: No

Comment 34

[Tom Ritter [:tjr]]

Comment on attachment 9278899 [details]
Bug 1745595 record window size changes from app-initiated resizes asynchronously after the first size-allocate r?stransky

Approved to land, and uplift if/when ready

Comment 35

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

type ResizeInt() parameters to specify units r=stransky
https://hg.mozilla.org/integration/autoland/rev/051d496ee57d98518f98a4d45c17c797b79c0c11
https://hg.mozilla.org/mozilla-central/rev/051d496ee57d

wait for resize to complete before getting font size r=niklas
https://hg.mozilla.org/integration/autoland/rev/ce93361507ded340ce9404fe947d0d01dc26dca0
https://hg.mozilla.org/mozilla-central/rev/ce93361507de

wait for resize to complete before adding media query r=daisuke
https://hg.mozilla.org/integration/autoland/rev/a647c26f9139986bd8ce1a1c66c45990b79d121b
https://hg.mozilla.org/mozilla-central/rev/a647c26f9139

record window size changes from app-initiated resizes asynchronously after the first size-allocate r=stransky
https://hg.mozilla.org/integration/autoland/rev/4102176d73ef57acb388b80ccdd9af0686ec6f2d
https://hg.mozilla.org/mozilla-central/rev/4102176d73ef

wait for expected geometry after move or resize r=whimboo,webdriver-reviewers
https://hg.mozilla.org/integration/autoland/rev/c2cd1e58dd94f78e6ed04798669635259a546964
https://hg.mozilla.org/mozilla-central/rev/c2cd1e58dd94

Comment 36

[Karl Tomlinson (:karlt back Feb 10)]

Comment on attachment 9278900 [details]
Bug 1745595 wait for expected geometry after move or resize r?whimboo

Beta/Release Uplift Approval Request

• User impact if declined: sec-high
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Use attachment 9270710 [details] with X11 Linux and 1920x1080 or 2560x1440 monitor.

Partial coverage in automated tests.

• List of other uplifts needed: None
• Risk to taking this patch: High
• Why is the change risky/not risky? (and alternatives if risky): The code has seen high turnover due to many different edge cases.
• String changes made/needed: None
• Is Android affected?: No

Beta/102 needs all patches but needs older diffs of two revisions from before rebases across recent trunk changes:
https://phabricator.services.mozilla.com/D147728?id=585997
https://phabricator.services.mozilla.com/D147729?id=587806

The easiest way to get the complete set of five changesets is

% hg pull -r 1456543b113c https://hg.mozilla.org/try
% hg rebase --rev 7ca436eeed37..1456543b113c -d <dest>

Comment 37

[Pascal Chevrel:pascalc]

Comment on attachment 9278900 [details]
Bug 1745595 wait for expected geometry after move or resize r?whimboo

Approved for 102 beta 8, thanks.

Comment 38

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/713197083c4e
https://hg.mozilla.org/releases/mozilla-beta/rev/ce43ec4f4cf2
https://hg.mozilla.org/releases/mozilla-beta/rev/17768e09997f
https://hg.mozilla.org/releases/mozilla-beta/rev/8c8cf025c410
https://hg.mozilla.org/releases/mozilla-beta/rev/6f80f48a4c78

Comment 39

[Pascal Chevrel:pascalc]

Karl, are you in contact with our QA team for the manual test or do you need me to loop in a Softvision Desktop QA person? Thanks

Comment 40

[Ryan VanderMeulen [:RyanVM]]

We're also going to need rebased patches for ESR91 by this time next week.

Comment 41

[Karl Tomlinson (:karlt back Feb 10)]

(In reply to Pascal Chevrel:pascalc from comment #39)

Karl, are you in contact with our QA team for the manual test or do you need me to loop in a Softvision Desktop QA person? Thanks

I don't have a contact. If you are able to loop someone in, that would be great, thanks.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #40)

We're also going to need rebased patches for ESR91 by this time next week.

Thanks for the detail there. I'll get onto that.

Comment 42

[Andrei Vaida [:avaida]]

Cristian will handle the work here.

Comment 43

[Cristian Baica [:cbaica], Release Desktop QA]

I've managed to reproduce the issue on Ubuntu 20.04 (1920x1080 and 2560x1440 resolutions) and Ubuntu 22.04 using the Fx 97.0a1 (2021-12-11 build).
The issue is verified fixed in the latest Fx103.0a1 build using Ubuntu 20.04 and Ubuntu 22.04 environments. For Ubuntu 20.04 the issue was verified on both 1080p and 1440p(2k resolution). This was tested with and without wayland and I'm happy to report the issue is fixed in both cases. For Ubuntu 22.04 I could only test the 1080p resolution and mentioned the issue is fixed there as well.

Waiting on Fx 102.0b8 to build and verify there as well.

Comment 44

[Cristian Baica [:cbaica], Release Desktop QA]

The issue is verified fixed in Fx102.0b8 on Ubuntu and Ubuntu Wayland (20.04). The address bar is no longer spoofed.

Comment 45

[Karl Tomlinson (:karlt back Feb 10)]

Attachment: Bug 1745595 wait for resize to complete before testing className (esr91-only) r?Mardak

This uses the same approach as in D147730.
The test was removed on newer branches by D127252.

Comment 46

[Karl Tomlinson (:karlt back Feb 10)]

Comment on attachment 9278900 [details]
Bug 1745595 wait for expected geometry after move or resize r?whimboo

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-high
• User impact if declined: sec-high
• Fix Landed on Version: 103
• Risk to taking this patch: High
• Why is the change risky/not risky? (and alternatives if risky): The code has seen high turnover due to many different edge cases.

The easiest way to get the complete set of five changesets is

% hg pull -r e3f4c1155287 https://hg.mozilla.org/try
% hg rebase --rev c3b21017a41e..e3f4c1155287 -d <dest>

D147730 attachment 9278901 [details] is not required (and not included in c3b21017a41e..e3f4c1155287), due to the test not existing on ESR91.

Comment 47

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9278898 [details]
Bug 1745595 - type ResizeInt() parameters to specify units r?stransky

Approved for 91.11esr. Thanks for rebasing.

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/e5a2f9e64dd4
https://hg.mozilla.org/releases/mozilla-esr91/rev/9ce6409adf88
https://hg.mozilla.org/releases/mozilla-esr91/rev/6a8bbdb2f763
https://hg.mozilla.org/releases/mozilla-esr91/rev/f3193a7893f3
https://hg.mozilla.org/releases/mozilla-esr91/rev/a183595253d2

Comment 49

[Cristian Baica [:cbaica], Release Desktop QA]

The issue is verified fixed using the latest Fx 102.0 ESR and Fx91.11.0 ESR on Ubuntu 20.04. Both builds were tested on 1080p and 1440p, on both wayland and 'regular' Ubuntu, with webrender enabled. The address bar was no longer spoofed.

Comment 50

[Alexandru Ionescu (needinfo me) [:alexandrui]]

(In reply to Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout) from comment #35)

wait for expected geometry after move or resize r=whimboo,webdriver-reviewers
https://hg.mozilla.org/integration/autoland/rev/c2cd1e58dd94f78e6ed04798669635259a546964
https://hg.mozilla.org/mozilla-central/rev/c2cd1e58dd94

== Change summary for alert #34402 (as of Fri, 10 Jun 2022 13:12:12 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
8%	reddit-billgates-post-2.hot fcp	linux1804-64-shippable-qr	cold fission webrender	307.05 -> 283.75
8%	reddit-billgates-post-2.top fcp	linux1804-64-shippable-qr	cold fission webrender	307.05 -> 283.75
8%	reddit-billgates-post-2.billg fcp	linux1804-64-shippable-qr	cold fission webrender	307.05 -> 283.75

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=34402

Comment 51

[Alex Finder]

== Change summary for alert #34554 (as of Fri, 17 Jun 2022 15:12:47 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
4%	twitter fcp	linux1804-64-shippable-qr	cold fission webrender	228.89 -> 220.24

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=34554

Comment 52

[Tom Ritter [:tjr]]

Attachment: advisory.txt