2015305 - (CVE-2026-2777) Compromised content process installs arbitrary WebExtensions or homepage hijacks (1-click) via AboutMessagePreviewParent IPC

Status: RESOLVED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Richard Belisle]

Attachment: submission_messagepreview.md

Howdy. Found something more interesting while poking around. Missing remoteTypes on AboutMessagePreviewParent (its sibling AboutWelcome has remoteTypes: ["privilegedabout"]) allows a compromised content process to reach SpecialMessageActions.handleAction() with no action-type restriction. This exposes 46 privileged actions including INSTALL_ADDON_FROM_URL (uses SystemPrincipal, bypasses site doorhanger) and SET_PREF (homepage hijack, 0-click).

Meets sec-high: "Installation and execution of an extension without user consent" and "Obtaining access to IPC endpoints with a compromised content process that have clear security impact."

Impact:

1. Arbitrary WebExtension install with Gate 1 bypassed — SystemPrincipal eliminates the "Allow this site to install?" doorhanger. User sees only the "Add" prompt (1 click). Attacker controls the InfoBar text for social engineering.
2. Homepage hijack (0-click) — browser.startup.homepage is on the SET_PREF allowlist. A single InfoBar button click sets the homepage to an attacker URL.
3. Full SpecialMessageActions table exposed — 46 action types including DISABLE_DOH, PIN_FIREFOX_TO_TASKBAR, SET_DEFAULT_BROWSER, MULTI_ACTION.

The matches check (which IS enforced parent-side) is bypassable from a compromised content process via RecvUpdateDocumentURI — IsHttpOrHttpsAndCrossOrigin() returns false for about: URIs, allowing documentURI spoofing to about:messagepreview. The about:messagepreview page runs in the web remote type (same as attacker content), not privilegedabout.

Full chain tested on Firefox ESR 140.7.0. Confirmed still present in mozilla-central (Firefox 147.0.3 stable).

How was this issue discovered? Include the steps, tools, Firefox version, operating system version, or other information that will help reproduce and diagnose the issue:

Systematic audit of JSWindowActor registrations in DesktopActorRegistry.sys.mjs for missing remoteTypes. Found AboutMessagePreview has no remoteTypes while AboutWelcome (same SpecialMessageActions dispatch pattern) has remoteTypes: ["privilegedabout"].

Traced the IPC path from content process through the parent actor to SpecialMessageActions and verified INSTALL_ADDON_FROM_URL uses SystemPrincipal. Confirmed the matches check is bypassable via RecvUpdateDocumentURI by reviewing IsHttpOrHttpsAndCrossOrigin (only validates http/https URIs).

Built and tested PoC using Marionette automation. Confirmed Gate 1 bypass (SystemPrincipal eliminates site doorhanger) and Gate 2 bypass (mainAction.callback() auto-accepts permission prompt from chrome JS).

Verified code is still vulnerable in mozilla-central as of February 2026. See attached for full PoC and details. Please let me know if you have any questions.

Comment 1

[Andrew McCreight [:mccr8]]

If I load about:messagepreview directly, it goes in a "web" process, not webIsolated or privilegedAbout. I'm not sure how we'll normally load this.

I'm not sure how legit this is, and the long rambling test case doesn't really help matters, but this does seem like it should get some further investigation.

Comment 2

[:Gijs (he/him)]

Emily, could you (find someone) to help take a look? Some context about the purpose of about:messagepreview and if we need to ship it would also help understand how we might mitigate this.

Comment 3

[Andrew McCreight [:mccr8]]

Could you please provide a new proof of concept that only involves modifying code in a child process? It looks like all of the code here is running in the parent process via Marionette, which makes it more difficult to evaluate the severity. It is okay if the PoC does not actually click on the addon installation info bar.

Also, there does not seem to be a PoC for the SET_PREF issue, though that does sound plausible so it would be good if you could provide a PoC for that, also one that is not just running all of its code in the parent process.

As I said, one way to make a PoC that mostly runs in the child process would be to provide a patch of code that runs in the parent process. Another way to do that would be to write a Firefox mochitest browser chrome and have the attack code run within SpecialPowers.spawn.

Comment 4

[Richard Belisle]

Attachment: test_poc.py

PoC updated as requested.

Comment 5

[Richard Belisle]

Attachment: submission_updated_poc.md

MD file for script

Comment 6

[Richard Belisle]

Howdy. Updated PoC attached. Code now runs in the content process as requested, and includes the SET_PREF demonstration.

Correction from my initial report: I claimed SET_PREF homepage hijack was 0-click. After review, all six template paths handled by AboutMessagePreviewParent.showMessage() (infobar, spotlight, cfr_doorhanger, feature_callout, bookmarks_bar_button, pb_newtab) require at least one user click. So both findings are 1-click, not 0-click. Apologies. The InfoBar appears automatically, but the action fires on button click. Attacker controls the InfoBar text for social engineering.

Findings validated in PoC:

1. SET_PREF homepage hijack (1-click) — browser.startup.homepage is on the allowedPrefs list in SpecialMessageActions.setPref(). Content process creates an InfoBar whose button sets the homepage to an attacker URL. Confirmed — pref changes after clicking.

2. INSTALL_ADDON_FROM_URL (1-click) — SystemPrincipal eliminates the "Allow this site to install?" doorhanger (Gate 1). Gate 2 still requires 1 click on the "Add" prompt, but attacker controls the InfoBar text (e.g. "A critical security update is available"). Confirmed — install mechanism fires on click.

3. Full SpecialMessageActions table exposed — 46 action types reachable including DISABLE_DOH, PIN_FIREFOX_TO_TASKBAR, SET_DEFAULT_BROWSER, MULTI_ACTION.

Let me know if you need anything else. - Richard

Comment 7

[Shane Hughes [:aminomancer]]

(In reply to Richard Belisle from comment #0)

Howdy. Found something more interesting while poking around. Missing remoteTypes on AboutMessagePreviewParent (its sibling AboutWelcome has remoteTypes: ["privilegedabout"]) allows a compromised content process to reach SpecialMessageActions.handleAction() with no action-type restriction. This exposes 46 privileged actions including INSTALL_ADDON_FROM_URL (uses SystemPrincipal, bypasses site doorhanger) and SET_PREF (homepage hijack, 0-click).

AboutMessagePreview and AboutWelcome are not really analogous. AboutWelcome renders content solely inside the web content. It's a page intended for users to see. AboutMessagePreview is a dev tool for previewing chrome messages and has no internal content besides an easter egg illustration. But nonetheless, both have the same level of access you described, and could be exploited if the attacker is able to set prefs or convince the user to set prefs.

The message preview workflow is to enable browser.newtabpage.activity-stream.asrouter.devtoolsEnabled (users can't be hijacked unless they have this devtool pref enabled, FWIW (edit: this is not really true, it seems like there are two types of attack - one using the URL search params + this pref and one using direct function calls, but see below)), find/build a message on about:asrouter, click its Share button, then pass the generated share URL to someone else (like a product manager), which they can paste in the urlbar to trigger the message. The module then parses the URL, extracts the message, and passes it up to the parent actor, which renders it in the browser chrome (not in the page content).

remoteTypes: ["privilegedabout"] would also need corresponding load flags. Otherwise you are just disabling the module. I don't think adding the privileged about load flag would actually solve this. MPShowMessage is still exported (and as we'll see in a moment, unnecessary). about:welcome has the same IPC powers as about:messagepreview. The modules don't rely on direct interaction within the parent process, but on JSActors. (edit: I've just noticed that the script doesn't need to set the devtools pref, because that only turns off URL parsing. So there are actually two possible classes of attack here.) The content actor will already show whatever message is embedded in the URL search params in base64. That's what this about page is intended for. So if you can take the user to about:messagepreview, you can also just pass a message in the URL, and the module will handle showing the message. Building this page in Firefox builds is intentional - PMs don't often have a local dev environment, and asking them to build one seems excessive. Asking them to flip a pref is a lot more reasonable. Though build setup is certainly getting easier.

I also want to clarify that about:messagepreview's content context does not have any more access to the parent process than any other means of prompting a message. about:asrouter (the devtools proper) can also show messages. If you can get the user to enable the devtools pref, and you can take them to about pages (that's already heavily restricted, so at this point I think we're already severely compromised), you can send them to about:asrouter, modify the content of one of the message textboxes, and click() on the Show button. Same thing as about:messagepreview. And about:asrouter does load in the privileged about process, but that doesn't stop it from showing messages.

These tools do allow social engineering, but at a certain point if your attack relies on soliciting the user to change unexposed prefs (like browser.newtabpage.activity-stream.asrouter.devtoolsEnabled) to enable dev tools, there's only so much we can (or should) do. I think the same initial steps could be used to even greater effect by inciting the user to enable autoconfig or security.allow_unsafe_dangerous_privileged_evil_eval. Right? And what about enabling chrome and remote debugging?

Attackers can do the same thing via about:welcome itself. The about:messagepreview vector involves setting a pref to enable the page, then using the page to display a message that prompts the user to do something they shouldn't do. Whereas the pref browser.aboutwelcome.screens allows directly replacing the content of aboutwelcome, and the content of aboutwelcome is similarly a message, so it can contain the same INSTALL_ADDON_FROM_URL and SET_PREF calls. That doesn't necessarily vindicate about:messagepreview - perhaps instead it merely condemns about:welcome 😅 but it's important context.

I suppose about:welcome could be made more secure by removing the screens pref I mentioned and simply using a Nimbus variable. The reason it's implemented as a pref is partly because the pref predates Nimbus, and partly because the pref makes dev testing easier. But a Nimbus variable is safer, as you can't solicit the user to change it. It can only be attacked by controlling or intercepting the Nimbus server response. Or I suppose by editing the local ExperimentStoreData.json file.

Still, I think anything that relies on manipulating the user to change settings is not a big concern. What seems to be the risk is that someone gets the user to change a pref that will enable showing a message that will prompt the user to potentially click a button that will change a pref (like homepage). I'll concede that the user changing the devtools pref is a more likely scenario than the user directly changing the homepage pref, so it's not a pointless middleman. But there are so many other prefs that do so much more, aren't there? (Edit: The attack could bypass the pref if it can call MPShowMessage directly, so see my next comment. If we can make it so all attacks rely on the pref being enabled, it seems a lot safer.)

Comment 8

[Shane Hughes [:aminomancer]]

It does seem like the way the browser.newtabpage.activity-stream.asrouter.devtoolsEnabled pref check is implemented allows a subset of attacks to work even if the pref is not set. Right now, if I'm reading it correctly, the pref really only enables the URL parsing. If you can directly call MPShowMessage, then the pref doesn't matter. At the very least, we should change that - the entire page should be disabled if the devtools pref is not set.

Comment 9

[Shane Hughes [:aminomancer]]

(In reply to Richard Belisle from comment #0)

The matches check (which IS enforced parent-side) is bypassable from a compromised content process via RecvUpdateDocumentURI — IsHttpOrHttpsAndCrossOrigin() returns false for about: URIs, allowing documentURI spoofing to about:messagepreview. The about:messagepreview page runs in the web remote type (same as attacker content), not privilegedabout.

I also want to ask about this, as it didn't seem to be covered in the script. Are you sure this is true? I don't think it hurts us to enable the privileged about process. But I also don't know how to evaluate this.

So far, mitigations that seem easy and to not impact functionality are:

1. Disable the actors if the pref is not set, maybe even enablePreference: "browser.newtabpage.activity-stream.asrouter.devtoolsEnabled"
2. Load in privileged about process (load flag and remoteTypes)
3. Remove the hint that shows if the devtools pref is not set. It's not really doing much for us - employees should already be directed to set the pref when we share the message with them, and if not, they can just ask us. The hint really only makes it easier for users to wind up setting a developer pref they shouldn't be setting.

If true, that would prevent attackers from spoofing about:messagepreview and would also require them to trick the user into changing a pref in about:config.

I'll put up a draft patch and Richard, let me know if you have any other ideas.

Comment 10

[Richard Belisle]

Attachment: poc_full_chain.py

Comment 11

[Richard Belisle]

Hey there. Reverified both things you asked about. Updated PoC attached.

Pref bypass (Comment 8): MPShowMessage works with devtoolsEnabled=false, default config. Homepage hijacked without the pref ever being set.

DocumentURI spoof (Comment 9): Yeah it's real. Two paths from a compromised content process:

1. docShell.loadURI(about:messagepreview) from the content process - stays in web process type because there's no URI_CAN_LOAD_IN_PRIVILEGEDABOUT_PROCESS flag. PoC does this end-to-end.

2. RecvUpdateDocumentURI (https://searchfox.org/mozilla-central/source/dom/ipc/WindowGlobalParent.cpp#389) - IsHttpOrHttpsAndCrossOrigin() returns false for about: URIs so the spoof goes through. Alternative path at the C++ level, doesn't even need to navigate the tab.

Re about:welcome: same SpecialMessageActions.handleAction() sink (https://searchfox.org/mozilla-central/source/browser/components/aboutwelcome/actors/AboutWelcomeParent.sys.mjs - AWPage:SPECIAL_ACTION), but it's properly gated in
https://searchfox.org/mozilla-central/source/browser/components/DesktopActorRegistry.sys.mjs with remoteTypes: ["privilegedabout"] + enablePreference. PoC confirms about:welcome routes to about:home in privilegedabout process, unreachable from web content. Same two protections on about:messagepreview would close both paths.

Your mitigations look right. Happy to test the patch. take it easy.

Comment 12

[Andrew McCreight [:mccr8]]

(In reply to Shane Hughes [:aminomancer] from comment #8)

It does seem like the way the browser.newtabpage.activity-stream.asrouter.devtoolsEnabled pref check is implemented allows a subset of attacks to work even if the pref is not set. Right now, if I'm reading it correctly, the pref really only enables the URL parsing. If you can directly call MPShowMessage, then the pref doesn't matter. At the very least, we should change that - the entire page should be disabled if the devtools pref is not set.

The specific sort of attack that is being described here is that a user loads a malicious webpage into a content process, which then leverages some kind of JIT bug or whatever to take over the content process, which will allow it to send whatever kind of JS actor message it wants to the parent. As far as I can see, the only kind of checks of activity-stream.asrouter.devtoolsEnabled are happening in AboutMessagePreviewChild.sys.mjs, so they won't help, because if you can run whatever code you want in a content process, you don't have to do those checks.

If this page can be changed to only run in the privileged about process, and this is enforced by adding remoteTypes: ["privilegedabout"] to the actor registration, then we don't have to worry about this attack being done from a web content process, because our assumption is that the privileged about process never loads arbitrary web content that might take over the process.

Comment 13

[Shane Hughes [:aminomancer]]

(In reply to Andrew McCreight [:mccr8] from comment #12)

If this page can be changed to only run in the privileged about process, and this is enforced by adding remoteTypes: ["privilegedabout"] to the actor registration, then we don't have to worry about this attack being done from a web content process, because our assumption is that the privileged about process never loads arbitrary web content that might take over the process.

Got it. I was under the impression this actually required a Marionette script rather than just using one to demonstrate the exploit. I have a forthcoming patch that I think should close that gap. I suppose additional mitigations might be superfluous then, but I might as well make them while I'm here.

I'll also stop the actor from being injected when the pref is not set, since that's a one-line change and there's little reason not to.

I thought it might also make sense to remove the hint that shows up when using a share URL with the pref disabled. It baits the user into changing the pref that would enable previewing arbitrary messages, which seems like it enables an additional social engineering attack that wouldn't need control of the content process. I suppose we have the same problem with about:asrouter (it provides the same hint), but that doesn't have share URLs, so the user would have to manually prompt the message, which kinda dampens social engineering opportunities.

Comment 14

[Andrew McCreight [:mccr8]]

(In reply to Shane Hughes [:aminomancer] from comment #13)

Got it. I was under the impression this actually required a Marionette script rather than just using one to demonstrate the exploit. I have a forthcoming patch that I think should close that gap. I suppose additional mitigations might be superfluous then, but I might as well make them while I'm here.

Yeah, that's unfortunate and does make it harder to assess whether this is a real problem.

I'll also stop the actor from being injected when the pref is not set, since that's a one-line change and there's little reason not to.

Great. More hardening is a good idea. If some code is only meant to be testing, you could guard it (in the parent process) using Cu.isInAutomation(), which will only return true while we're in Mochitests etc.

I thought it might also make sense to remove the hint that shows up when using a share URL with the pref disabled. It baits the user into changing the pref that would enable previewing arbitrary messages, which seems like it enables an additional social engineering attack that wouldn't need control of the content process. I suppose we have the same problem with about:asrouter (it provides the same hint), but that doesn't have share URLs, so the user would have to manually prompt the message, which kinda dampens social engineering opportunities.

That's a good idea. Generally we probably can't do too much if an evil page tricks somebody into going into about:config and changing a pref, but not mentioning the pref in official browser chrome is a start.

Comment 15

[Shane Hughes [:aminomancer]]

Attachment: (secure)

Also fully disable the actor pair when the ASRouter admin pref is not
enabled, and delete the hint that directed users to flip the pref. Also
update the automated tests so they cover the full control flow and
behave less like unit tests. Also incidentally fixes a bug that required
us to disable one of the tests, so we can close bug 1946629.

Comment 16

[Andrew McCreight [:mccr8]]

Rating this is a bit tricky. The two actions being reported here that can be done from a compromised process are

1. set a pref from this rather long list.
2. install an addon.

Mitigating it is that it sounds like it requires that the user click on an infobar, but on the other hand I think it is a legit browser chrome infobar with attacker-controllable text so a user is more likely to fall for it than a usual spoof.

Comment 17

[Andrew McCreight [:mccr8]]

Please be sure to ask sec-approval? for the patch and we can figure out the rating.

Comment 18

[Shane Hughes [:aminomancer]]

[Tracking Requested - why for this release]: We'd like to land this patch and uplift to 148 as soon as possible. It seems like a critical security issue, and the fix is very simple, so uplift seems justified.

Comment 19

[Shane Hughes [:aminomancer]]

Comment on attachment 9543760 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: The patch itself doesn't really teach you anything about the exploit. You'd need to already know how to exploit JSActors that permit the web remote type.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: all branches; yes
• 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?: The code has not changed in a long time, so it's trivial to graft the mozilla-central patch onto the other repos. I could do that now, but I'm not sure which branches to create uplift patches for. It's too late for a 147 dot-release, and I don't know how uplifting into ESR works as I've never done it. Perhaps we can discuss with relman.
• How likely is this patch to cause regressions; how much testing does it need?: None of the code is user-facing. The issue is that a devtool (about:messagepreview) can be exploited by a malicious actor. Locking down the devtool won't change anything about the user experience, since the devtool was already hidden from users (doesn't show up on about:about, nor is it suggested by the urlbar).
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: No

Comment 20

[Ryan VanderMeulen [:RyanVM]]

As you noted, this will cherry-pick cleanly to Beta. Given that, the Lando-based uplift request flow should work fine for that. I would recommend waiting to do so until after the patch makes it to mozilla-central, however.
https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift#Requesting_Uplift_using_Lando

ESR140 and ESR115 are going to need rebasing, however. If you request ESR140 and ESR115 at the same time as Beta, Lando will give you instructions to follow for how to do the rebase locally, submit via moz-phab on the command line, and link to your already-submitted uplift request. And if you have questions or run into problems, you can ask for help in #uplift-pilot on Slack.

Comment 21

[Daniel Veditz [:dveditz]]

Comment on attachment 9543760 [details]
(secure)

sec-approval+

Comment 22

[Shane Hughes [:aminomancer]]

Per Daniel's suggestion, I've scrubbed the commit message from the patch. Here it is for future reference:

Bug 2015305 - Refactor about:messagepreview actors to use privileged about process.

Also fully disable the actor pair when the ASRouter admin pref is not
enabled, and delete the hint that directed users to flip the pref. Also
update the automated tests so they cover the full control flow and
behave less like unit tests. Also incidentally fixes a bug that required
us to disable one of the tests, so we can close bug 1946629.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/35c67d91b9a1
https://hg.mozilla.org/integration/autoland/rev/ac4c1b315f7e
r=emcminn,omc-reviewers,Gijs

Comment 24

[Donal Meehan [:dmeehan]]

:aminomancer, I noticed you added a leave-open keyword. That can be problematic.
Here's a comment from :dveditz from another bug as an example, just reusing it to explain:

What is the leave-open for? If it's for landing the tests later please don't do it that way: a lot of the processes for the release, qa, and security teams are driven by "FIXED" bugs. If you need an open bug for tracking then please clone a "land tests for bug 2014101" security bug for that. Give it a sec-other keyword because it's not a vulnerability itself, just related to one. These days a lot of people rely on the bot reminders that I'm going to add to this bug, so you can do that if you'd like.

Comment 25

[BugBot [:suhaib / :marco]]

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:aminomancer, could you consider increasing the severity of this security bug?

For more information, please visit BugBot documentation.

Comment 26

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox148 (beta) and tracked for firefox149 (nightly). However, the bug still has low severity.

:aminomancer, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 27

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

https://hg.mozilla.org/mozilla-central/rev/ac4c1b315f7e

Comment 28

[Shane Hughes [:aminomancer]]

(In reply to Donal Meehan [:dmeehan] from comment #24)

:aminomancer, I noticed you added a leave-open keyword. That can be problematic.
Here's a comment from :dveditz from another bug as an example, just reusing it to explain:

What is the leave-open for? If it's for landing the tests later please don't do it that way: a lot of the processes for the release, qa, and security teams are driven by "FIXED" bugs. If you need an open bug for tracking then please clone a "land tests for bug 2014101" security bug for that. Give it a sec-other keyword because it's not a vulnerability itself, just related to one. These days a lot of people rely on the bot reminders that I'm going to add to this bug, so you can do that if you'd like.

Hi Donal, I want the bug to stay open because I have to land custom patches for beta 148, esr 140, and esr 115. Which I'll attach to this bug. So I don't want the bug closing before that.

Comment 29

[Andrew McCreight [:mccr8]]

(In reply to Shane Hughes [:aminomancer] from comment #28)

Hi Donal, I want the bug to stay open because I have to land custom patches for beta 148, esr 140, and esr 115. Which I'll attach to this bug. So I don't want the bug closing before that.

We typically mark it FIXED to indicate that it is fixed on mozilla-central. For other branches, we track the status via the "affected" flags.

Comment 30

[Shane Hughes [:aminomancer]]

(In reply to Andrew McCreight [:mccr8] from comment #29)

We typically mark it FIXED to indicate that it is fixed on mozilla-central. For other branches, we track the status via the "affected" flags.

And there won't be any problem with me attaching patches to a closed bug? That was my worry.

Comment 31

[Donal Meehan [:dmeehan]]

(In reply to Shane Hughes [:aminomancer] from comment #30)

(In reply to Andrew McCreight [:mccr8] from comment #29)

We typically mark it FIXED to indicate that it is fixed on mozilla-central. For other branches, we track the status via the "affected" flags.

And there won't be any problem with me attaching patches to a closed bug? That was my worry.

No worry, that is the typical uplift flow

Comment 32

[Andrew McCreight [:mccr8]]

Yes, that's the normal procedure for uplifts.

Comment 33

[Donal Meehan [:dmeehan]]

You can add the uplift requests as soon as you have time. Please see the following doc if you need any info:
https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift

Comment 34

[Shane Hughes [:aminomancer]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D282533

Comment 35

[Shane Hughes [:aminomancer]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D282533

Comment 36

[Shane Hughes [:aminomancer]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D282533

Comment 37

[Shane Hughes [:aminomancer]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D282533

Comment 38

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Users of this branch will potentially be at risk of an exploit that could take control of their browser.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The about:messagepreview page is not normally exposed to users, and the changes made are very minor.
• String changes made/needed: none
• Is Android affected?: no

Comment 39

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Users of this branch will potentially be at risk of an exploit that could take control of their browser.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The about:messagepreview page is not normally exposed to users, and the changes made are very minor.
• String changes made/needed: none
• Is Android affected?: no

Comment 40

[Phabricator Automation]

firefox-esr115 Uplift Approval Request

• User impact if declined: Users of this branch will potentially be at risk of an exploit that could take control of their browser.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The about:messagepreview page is not normally exposed to users, and the changes made are very minor.
• String changes made/needed: none
• Is Android affected?: no

Comment 41

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/cf01411a02a1
https://hg.mozilla.org/releases/mozilla-beta/rev/2db92942e9b0

Comment 42

[Donal Meehan [:dmeehan]]

:aminomancer, you'll see I tagged you in the patch that the ESR140 revision does not apply cleanly.
ESR115 does apply cleanly fwiw

Comment 43

[Shane Hughes [:aminomancer]]

(In reply to Donal Meehan [:dmeehan] from comment #42)

:aminomancer, you'll see I tagged you in the patch that the ESR140 revision does not apply cleanly.
ESR115 does apply cleanly fwiw

Strange. I'm not sure what I did wrong. I checked out esr140 and ran moz-phab patch on it, like the uplift request instructions said. Didn't mention any conflicts upon patching.

I'm knocked out with the flu, so it might be a few days before I get to fixing the esr140 patch. If you're okay with the esr115 and beta patches, I would be fine if you or someone else wants to land them for me (via Lando). Otherwise I'll try to get back to the computer when I can.

Comment 44

[Donal Meehan [:dmeehan]]

There's no problem with beta and esr115, they are landed by the relman when they approve.

140.8esr builds next week.
Maybe a reviewer of the original patch could take a look at the ESR140 patch in the meantime? Gijs, could you have a look, or direct this to someone?

Comment 45

[:Gijs (he/him)]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D282533

Comment 46

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Users of this branch will potentially be at risk of an exploit that could take control of their browser.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The about:messagepreview page is not normally exposed to users, and the changes made are very minor.
• String changes made/needed: none
• Is Android affected?: no

Comment 47

[:Gijs (he/him)]

(In reply to Donal Meehan [:dmeehan] from comment #44)

There's no problem with beta and esr115, they are landed by the relman when they approve.

140.8esr builds next week.
Maybe a reviewer of the original patch could take a look at the ESR140 patch in the meantime? Gijs, could you have a look, or direct this to someone?

Couldn't update the existing uplift revision but put up a new one.

Comment 48

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/7971445ae1cf

Comment 49

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/fbfa6d03f3fb

Comment 50

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/47efd8087bf0

Comment 51

[Serban Stanca [:SerbanS]]

Reverted this because it was causing linting opt failures.

• Revert link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-ERROR | /builds/worker/checkouts/gecko/browser/components/messagepreview/actors/AboutMessagePreviewChild.sys.mjs:18:5 | Unknown lazy member property log (mozilla/valid-lazy)

Comment 52

[:Gijs (he/him)]

(In reply to Serban Stanca [:SerbanS] from comment #51)

Reverted this because it was causing linting opt failures.

• Revert link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-ERROR | /builds/worker/checkouts/gecko/browser/components/messagepreview/actors/AboutMessagePreviewChild.sys.mjs:18:5 | Unknown lazy member property log (mozilla/valid-lazy)

My fault, I didn't realize that the ESR patches were... much smaller than the m-c patches.

Can you try again with the newer patch?

Comment 53

[Donal Meehan [:dmeehan]]

Thanks, I'll try again. Keeping need-info open until I push later

Comment 54

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/9c2911cc3ac5