Ok, let's flip the pref.

Intent to unship: https://groups.google.com/a/mozilla.org/g/dev-platform/c/jDrDstL2MGU

Backed out changeset 88f605efb204 (Bug 1764771) for causing xpcshell failures on test_mutableFileUpgrade.js.
Backout link
Push with failures <--> X5
Failure Log

https://hg.mozilla.org/mozilla-central/rev/0d9e24627e48

FYI FF102 docs work for this can be tracked in https://github.com/mdn/content/issues/16151#issuecomment-1132419424 (mostly complete)

Somehow the merge commit https://hg.mozilla.org/mozilla-central/rev/58a6343ab33d9ca296fe30e66757301d1cda705d immediately rolled the change back, so FF102 never really had this. Reverting the keyword as such.

NI'ing :aryx for comment #12. I think a merge commit should not roll anything back by itself, right?

(In reply to Kagami :saschanaz from comment #12)

Somehow the merge commit https://hg.mozilla.org/mozilla-central/rev/58a6343ab33d9ca296fe30e66757301d1cda705d immediately rolled the change back, so FF102 never really had this. Reverting the keyword as such.

Hi Kagami, so what happened here was the patch you landed in comment 4 was backed out for xpcshell failures in comment 5/6, that backout was grafted to central in order have a suitable and failure free merge candidate. Grafting that backout created a new central revision for it which was posted by Pulsebot in comment 7. The merge didn't revert anything that wasn't already backed out on autoland.
The next round of merges included your disable patch from comment 8 and was closed as fixed in comment 9.
Treeherder links of those merges are here.

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

Hi Cosmin,

The next round of merges included your disable patch from comment 8 and was closed as fixed in comment 9.

No it didn't, see what actually happened in e.g. FileHandle.webidl (and any other file in this patch): https://hg.mozilla.org/mozilla-central/log/tip/dom/webidl/IDBFileHandle.webidl

Per the log, the merge commit 58a6343ab33d9ca296fe30e66757301d1cda705d did backout the change from the second push in comment #8. That's why I had to push the same patch again in comment #14 even though there was no explicit backout after comment #9.

What's more weird is that the merge commit did not backout dom/indexedDB/test/unit/xpcshell-parent-process.ini. That's the only change that have actually reached the central branch.

So the issue is not with the first backout but with the second land in the bug (comment 8) that was partially backed out, I see now.
Revisions that modified dom/webidl/IDBFileHandle.webidl :

• central: https://hg.mozilla.org/mozilla-central/log/58a6343ab33d9ca296fe30e66757301d1cda705d/dom/webidl/IDBFileHandle.webidl
• autoland: https://hg.mozilla.org/integration/autoland/log/0d9e24627e4809ce22f67a9069b77305dc44bac5/dom/webidl/IDBFileHandle.webidl

Revisions that modified dom/indexedDB/test/unit/xpcshell-parent-process.ini

• central: https://hg.mozilla.org/mozilla-central/log/315935601dba7d57bdcb51d64ea74ad0bebf46ca/dom/indexedDB/test/unit/xpcshell-parent-process.ini
• autoland: https://hg.mozilla.org/integration/autoland/log/315935601dba7d57bdcb51d64ea74ad0bebf46ca/dom/indexedDB/test/unit/xpcshell-parent-process.ini

What happened:

• merge of first landing + grafted backout (= new revision hash to autoland)
• relanding on autoland
• mozilla-central gets merged back to autoland and mercurial automatically applies the backout again

Sorry about that.

Mitigation: Directly merge back to autoland after the merge to mozilla-central but this still leaves the risk if the relanding got pushed before the merge from autoland to mozilla-central.

Without grafting, merges would sometimes not possible (e.g. subsequent Nightlies without changes).