Skip to content

Bug 41761: Cherry-pick Moz Bug 1772170 and 1781169

Merge Info

Related Issues



  • Immediate: patchset needed as soon as possible
  • Next Minor Stable Release: patchset that needs to be verified in nightly before backport
  • Eventually: patchset that needs to be verified in alpha before backport
  • No Backport (preferred): patchset for the next major stable

(Optional) Justification

  • Emergency security update: patchset fixes CVEs, 0-days, etc
  • Censorship event: patchset enables censorship circumvention
  • Critical bug-fix: patchset fixes a bug in core-functionality
  • Consistency: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc
  • Sponsor required: patchset required for sponsor
  • Other: please explain


  • Merge to tor-browser - !fixups to tor-browser-specific commits, new features, security backports
  • Merge to base-browser - !fixups to base-browser-specific commits, new features to be shared with mullvad-browser, and security backports
    • NOTE: if your changeset includes patches to both base-browser and tor-browser please clearly label in the change description which commits should be cherry-picked to base-browser after merging

Issue Tracking


Request Reviewer

  • Request review from an applications developer depending on modified system:
    • NOTE: if the MR modifies multiple areas, please /cc all the relevant reviewers (since gitlab only allows 1 reviewer)
    • accessibility : henry
    • android : dan
    • build system : boklm
    • extensions : ma1
    • firefox internals (XUL/JS/XPCOM) : ma1
    • fonts : pierov
    • frontend (implementation) : henry
    • frontend (review) : donuts, richard
    • localization : henry, pierov
    • nightly builds : boklm
    • rebases/release-prep : dan_b, ma1, pierov, richard
    • security : ma1
    • signing : boklm, richard
    • updater : pierov
    • misc/other : pierov, richard

Change Description

I'm proposing to cherry-pick these fixes from Firefox 103 and Firefox 106 to possibly fix #41761 (closed).

From what I understand, it's a consequence of accessibility.cache.enabled.

A cypherpunk suggested us the former bug. Then, I checked the patch, and compared it with 115. In this way, I found also the latter bug, that is a fix to the former.

The two commits together make DocAccessibleParent::SelectionRanges equal to 115, so it seems pretty safe to me to get them together directly in the stable (maybe after a quick QA, I can run a build, but I could never replicate the initial crash...). We cannot check them in alpha first, since they're already there.

If we decide to merge, should we reopen 102.13, merge them, and then cherry-pick them at the beginning of the patchset with other Moz commits, since 102.14's rebase hasn't been merged, yet?
Or should we get them at the end so if things go wrong we remember that we cherry-picked them, and move them the next month?

/cc @ma1

Merge request reports