Closed Bug 1659155 (CVE-2021-43531) Opened 3 years ago Closed 2 years ago

contextMenus.onClicked: info.srcUrl is the final URL (after redirects) instead of the <img src> value.


(WebExtensions :: General, defect, P1)



(firefox-esr78 wontfix, firefox-esr91- wontfix, firefox92 wontfix, firefox93 wontfix, firefox94+ fixed, firefox95+ fixed)

95 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox-esr91 - wontfix
firefox92 --- wontfix
firefox93 --- wontfix
firefox94 + fixed
firefox95 + fixed


(Reporter: robwu, Assigned: robwu)




(4 keywords, Whiteboard: [addons-jira][adv-main94+])


(3 files)

Since bug 1406253, the info.srcUrl field of the contextMenus.onClicked event returns the URL after redirects, instead of the URL of the image request.

Prior to that bug, and also in Chrome, the info.srcUrl field was the image's src element.


  1. Load attached extension, which opens a tab with an image.
  2. Right-click on the image and click on the extension's context menu.

Expected (Chrome 84):

  • A dialog with a URL ending with "before-redirect".

Actual (Firefox 81):

  • A dialog with a URL ending with "after-redirect"

I'm inclined to resolve the bug as follows:

  • Update MDN to clarify that info.srcUrl may differ from the <img>'s src attribute. In Chrome, this is always the URL of the initial request. In Firefox, this is the final URL (after any redirects). EDIT: The alternative is preferred, see comment 2 and comment 3.
  • Add a unit test to make sure that the behavior continues to be as documented.

The alternative is to let info.srcUrl be the initial URL again. This would result in consistent behavior between Firefox and Chrome. I guess that few users cared either way, since nobody has filed a bug about this (I only discovered this when I investigated a report about DownThemAll not working on Twitter).

Some extensions (including DownThemAll) use info.srcUrl to identify the element to which the context menu is anchored from a content script. Since there is a superior alternative (info.targetElementId + browser.menus.getTargetElement), I would recommend extension authors to use that API to really identify the target element without having to traverse the whole DOM to find the image element of interest.

I'll wait till the next bug triage, and if the team agrees, I'll add dev-doc-needed to the bug.

Or maybe dev-doc-complete after updating the documentation myself, at

See Also: → 1621249
Type: task → enhancement
See Also: 14528191406253

I'm a bit on the fence here.

Writing cross browser compatible code would be nice, thus srcUrl being consistent with (probably) the rest of the browsers implementing this api is preferable. As well, while targetElementId is superior for the purpose, it's not cross browser.

Having the final url in srcUrl is probably useful for some, but I'm not sure it outweighs the compatibility.

In retrospect we should have kept srcUrl compatible, and introduced finalSrcUrl. It feels like doing that at this point just muddies the water.

I think we'd probably be better off if this were compatible at least in V3, and it probably makes sense to have it compatible in V2 to lower the V2->V3 transition.

During the triage we decided that info.srcUrl should be the original URL, before redirects. This is because the final URL (after redirects) is normally not exposed to the web platform, and the original URL is usually expected. It's also more compatible with Chrome.

The doubts about final URL vs current URL is not limited to extensions, there is a similar discussion going on in bug 1644802. That bug and this bug may be able to share the same solution.

FYI, the property is internally called .mediaURL, and used by video, audio and images. For video and audio, it's already the pre-redirect URL. For images, it's somehow the final URL:

Severity: -- → S3
Type: enhancement → defect
Priority: -- → P3
See Also: → 1644802
See Also: → CVE-2021-43532

The reason it's the post-redirect URL was also web extensions :-( This was done in bug 1406253 (and causing other problems, see bug 1719203)

In the case of a redirected image this reveals information to an extension that the Same-origin policy forbids unless it has WebRequest access to the hosts in order to follow the redirect chain.

Group: firefox-core-security
Regressed by: 1406253
Has Regression Range: --- → yes
Keywords: regression

Depending on the implementation, fixing bug 1719203 would resolve this bug and also bug 1644802

(In reply to Rob Wu [:robwu] from comment #6)

Depending on the implementation, fixing bug 1719203 would resolve this bug and also bug 1644802

There's a patch up in 1719203 now, is more work needed here or not?

Flags: needinfo?(rob)

Yes, more work is needed.

The extension framework implementation reads the URL from contextData.srcUrl :

srcUrl is currently set to mediaURL at

To fix this bug, we would have to replace srcUrl: this.mediaURL with srcUrl: this.originalMediaURL (introduced in the patch for bug 1719203), plus a unit test for this scenario. The fix is trivial, the tests are most of the work. I could take care of that once the patch for bug 1719203 lands.

Assignee: nobody → rob
Depends on: CVE-2021-43532
Flags: needinfo?(rob)
Whiteboard: [addons-jira]

Once this bug gets fixed, the change should be documented in the release notes.

And the documentation of srcUrl on MDN should clarify that the URL is the pre-redirect URL, but that it was the post-redirect URL from Firefox 59 (bug 1406253) up until Firefox 95 (fixed in this bug) (or maybe even 94, if we decide to uplift this bug for consistency with the behavior in bug 1719203).

Keywords: dev-doc-needed
Group: firefox-core-security → core-security-release
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
Flags: in-testsuite+

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

Priority: P3 → P1

The patch landed in nightly and beta is affected.
:robwu, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(rob)

Comment on attachment 9244718 [details]
Bug 1659155 - Use pre-redirect URL as srcUrl in contextMenus API

Beta/Release Uplift Approval Request

  • User impact if declined: It would be nice if the two related secbugs were fixed in the same release (this bug and bug 1719203). Otherwise there is inconsistent behavior.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Why potentially risky: This changes the behavior of the extension API in some cases.
    Why not risky: The new behavior is consistent with user expectations in other situations (bug 1719203), and identical to the behavior of the same extension API in Chromium.
  • String changes made/needed:
Flags: needinfo?(rob)
Attachment #9244718 - Flags: approval-mozilla-beta?

Comment on attachment 9244718 [details]
Bug 1659155 - Use pre-redirect URL as srcUrl in contextMenus API

Approved for 94.0b5.

Attachment #9244718 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Should we take this and bug 1719203 on ESR91?

Flags: needinfo?(rob)

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

Should we take this and bug 1719203 on ESR91?

I'd put this question in the other bug (there is already a question from the reporter, but nobody was needinfo'd).

The change to the extension API is a behavioral change, which has some (small) risk of affecting extensions.

The change to the context menu implementation (bug 1719203) affects user behavior.

The main question is whether we consider the sec issue severe enough to warrant uplifting to ESR. I'm 50/50 divided on this one, I'd be fine with uplifting, but also fine if we did not. I'll put a needinfo on the other bug.

Flags: needinfo?(rob)
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify-

Sounds like this is wontfix for ESR91 based on the last comments in bug 1719203.

Whiteboard: [addons-jira] → [addons-jira][adv-main94+]
Attached file advisory.txt

Could I get some clarification here:

  • the documentation for srcUrl is rather cryptic, what image is it referring to?
  • what is the difference between the pre-redirect URL and post-redirect URL?
Flags: needinfo?(rob)

It's the image (e.g. <img> or a background image) under the pointer where the context menu has been opened.

The "pre-redirect" URL is the initial URL, e.g. the value of an <img>'s src attribute (or the value of the url() CSS function in case of background-image).

After a redirect (e.g. HTTP 302 by a server), the final URL (post any redirects) is the ultimate redirection target, likely different from the initial URL.

Flags: needinfo?(rob)

Posted reviews.

Flags: needinfo?(rob)
Keywords: dev-doc-needed
Alias: CVE-2021-43531
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.