1863246 - Copy and Paste context menu entries are sometimes disabled when they should not be

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[Alice0775 White]

+++ This bug was initially created as a clone of Bug #1860426 +++

When I test Bug 1860426.
I can to reproduce it in Nightly 121.0a1 Windows 10 x64.

Steps to reproduce:

1. Set Bookmarks Toolbar to Always Show(to simplify the procedure)

2. Bookmark https://www.google.com/ as Google. And place it on the bookmark toolbar.

3. Copy any text to clipboard (to simplify the reprocedure)

4. Close and reopen Firefox.

5. Click on Getting Started(I don't think it's limited to this one) in the Bookmarks Toolbar

6. Click on Google in the Bookmarks Toolbar

7. Right mouse click on Google's input field

OR

1. Open https://www.google.com/ in a tab
2. Open https://ftp.mozilla.org/pub/firefox/nightly/ in the same tab
3. Click on Go back button (or Alt+Left Arrow)
4. Click on Go forward button (Alt+Right Arrow)
5. Select some text
6. Right click

Actual Results:
Edit context menu are disabled

Expected Results:
At least, Copy and Paste menus should be enabled.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=383986e2f5cb835a55c47bbd6e15d81035ca0784&tochange=d6e8528f0a936df88369c71f4e390e31a4d621a1

Comment 1

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

Set release status flags based on info from the regressing bug 1732358

:nika, since you are the author of the regressor, bug 1732358, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Nika Layzell [:nika] (ni? for response)]

The regressing bug here is enabling Fission, meaning that this is likely a behaviour change in our clipboard enable/disable logic caused by process switches. Redirecting to :masayuki for some insight from the editor side as to what might be going on?

There's also a chance this is an issue with APZ and input event targeting, given that this is intended to be a context menu on an input field.

Comment 3

[Alice0775 White]

Ok,
Regression window w/ fission.autostart = true:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=11dde99936308be30fee9fe4237028d71c86e905&tochange=7070b63e60c8667cffa051f8ea946118a961c0ca

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

From the editor module point of view, it's not enabled if there is no copy event listener in inclusive ancestor of the exposed root (<input> or <textarea>) when Selection is collapsed.

On the other hand, pasting does not require Selection check nor paste event listener check.

Additionally, if the editor does not focus, they should be always enabled.

So I guess that the command state manager asked wrong document, but looks like the <input> of Google search is not in a sub-document. So I have no idea where is wrong.

Comment 5

[Andreas Farre [:farre]]

Masayuki, could you assign a severity?

Comment 7

[:Gijs (he/him)]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #4)

So I guess that the command state manager asked wrong document, but looks like the <input> of Google search is not in a sub-document. So I have no idea where is wrong.

Did you see bug 1860426 comment 6? And does that help at all?

(In reply to Neil Deakin from bug 1860426 comment #6)

I can reproduce this fairly reliably. It looks like nsFocusManager::GetActiveBrowsingContextInChrome is returning null for some reason.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I just commented from the editor side (as requested). I'm not familiar with the focus management between content processes.

Comment 9

[Andreas Farre [:farre]]

Henri, you did work on the Fission focus handling. Do you have an idea of what's going on?

Comment 10

[Mark Datysgeld]

Is this the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1761430?

Comment 11

[:Gijs (he/him)]

(In reply to Mark Datysgeld from comment #10)

Is this the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1761430?

Probably. Let's wait for the needinfo to decide what to do.

Comment 12

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

(In reply to Andreas Farre [:farre] from comment #9)

Do you have an idea of what's going on?

Not beyond:

I can reproduce this fairly reliably. It looks like nsFocusManager::GetActiveBrowsingContextInChrome is returning null for some reason.

That is, I don't have an idea of why active browsing context tracking in the parent process gets out of sync.

Comment 13

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Hmm. Considering what the regressor is, perhaps we fail to restore the activeness status properly when a page comes out of the bf cache?

Comment 14

[lexlexlex]

I noticed that an easy workaround when this happens is to click the address bar to change selection focus, then interact with the page again. After that, the "Copy" entry in the context menu works again without reopening the tab. Maybe this can give a hint about what might be causing it.

Comment 15

[Mark Datysgeld]

(In reply to lexlexlex from comment #14)

I noticed that an easy workaround when this happens is to click the address bar to change selection focus, then interact with the page again. After that, the "Copy" entry in the context menu works again without reopening the tab. Maybe this can give a hint about what might be causing it.

I can confirm that this workaround is valid for me in Win11 latest.

Comment 16

[lexlexlex]

To clarify, I am running Manjaro XFCE with X11, so along with Mark's confirmation above, it sounds like this workaround is confirmed for both Linux and Windows. Therefore, I expect that we can conclude that this issue and its specific manifested behavior is not platform-specific.

Comment 18

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

Set release status flags based on info from the regressing bug 1720990

Comment 19

[arsdn]

In a rather unexpected turn of events, I discovered that the bug on my Mac was resolved perfectly once I disabled uBlock Origin. I suspect it has something to do with anti-tracking features, or something along those lines. As someone who's not particularly tech-savvy, that's just my guess.

Comment 21

[Peter Van der Beken [:peterv]]

I still haven't been able to reproduce this. I tried the STR from this bug, the duplicates and bug 1761430.

Comment 23

[tgn-ff]

A few days ago that I reproduced it, I noticed that, the text seemed to be successfully copied to the clipboard, as it was listed in both klipper (KDE) and fcitx5 (IME; its clipboard manager). I just wasn't able to paste it anywhere, Firefox or other software, through, either the context menu or the shortcut.

I have two clipboard-related prefs in non-default states: dom.event.clipboardevents.enabled:false and clipboard.autocopy:false.

Comment 24

[lexlexlex]

@tgn-ff is describing some other bug, because their described behavior is not this bug's observed behavior. This bug is simply the context menu entries being disabled, with a workaround of focusing the address bar.

I have no clipboard-related prefs in non-default states and this bug manifests for me once or twice per day. I use multiple Firefox windows, each with many tabs.

Comment 25

[arsdn]

(In reply to arsdn from comment #19)

In a rather unexpected turn of events, I discovered that the bug on my Mac was resolved perfectly once I disabled uBlock Origin. I suspect it has something to do with anti-tracking features, or something along those lines. As someone who's not particularly tech-savvy, that's just my guess.

After several days of browsing, I noticed that this bug still occurred once or twice a day, even after turning off all extensions, including uBlock Origin. So, I have now proven my initial guess wrong. Also, my browser version is 120.0.1 (64-bit).

Comment 26

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I am finally able to reproduce this issue, but still not reliably, and it's happening probably once out of tens of attempts.
I followed STRs in https://bugzilla.mozilla.org/show_bug.cgi?id=1860426#c2 ; I seemed to have to select texts from a bookmark page quickly enough, right after I navigated from homepage to the bookmark page, and before the bookmark page was completely loaded.

Comment 27

[lexlexlex]

I believe this is not caused by the bookmark system, since I see it often and almost never use bookmarks. I never have the bookmarks bar enabled, either. I may use a bookmark once per 2 months, yet this bug manifests multiple times per week.

Comment 28

[Peter Cassidy]

I cleared browsing & download, cache and form & search histories then opened and closed Firefox 10 times. Each time I went to the bookmarks menu. I used three different websites for the test, giving the website sufficient time to load. Then selected non-linked text. On the context menu copy was grayed out 4 times out of those ten times. I opened a new tab then went back to the first tab and copy was no longer grayed out.
I tested with all extensions, theme, custom settings and userchrome.css enabled.

Comment 29

[Neil Deakin]

Debugging shows that the focus manager for the process for the page being unloaded is receiving WindowHidden() which clears the mActiveBrowsingContextInChrome field. The focus manager for the process for the page being loaded is receiving WindowRaised() which sets the mActiveBrowsingContextInChrome field.

On success, the two processes perform those steps in that order. On failure, they perform those steps in the reverse order. There's a bunch of code in ProcessPendingActiveBrowsingContextActionId that is supposed to handle these calls being out of order, but I can't figure out what it is trying to do, but it seems to fail in this case.

I can reproduce with the steps in https://bugzilla.mozilla.org/show_bug.cgi?id=1860426#c2 about 20-30% of the time, but I don't need to exit each time; it is sufficient at step 2 to just open a new window.

Comment 31

[me]

I've reported a similar problem here https://bugzilla.mozilla.org/show_bug.cgi?id=1871049

This one affects the file and context menu in Firefox on MacOS

Comment 32

[sysdadmin]

this bug is extremely frustrating, happens on all my devices (windows 11 and arch linux kde), on random websites multiple times a day, it's not related to any extension as far as i can see, on linux i have it both on X11 and Wayland, i just hope it gets some priority since it really drives me insane

Comment 33

[Leonard Ratliff]

Can confirm I too have same issue. Intermittent grayed out Copy on context menu that nevertheless function works fine with keyboard shortcuts.

Comment 34

[quimnuss]

I can reproduce this reliably by googling something, opening a result and without switching focus, right-clicking. Firefox 121.0 (64-bit) on linux Mint

Can confirm that disabling ublock origin fixes it
Can confirm that the addon https://addons.mozilla.org/en-US/firefox/addon/absolute-enable-right-click/ fixes it
Can confirm swithcing focus fixes it

I've narrowed it down to ublock origin -> Settings -> Build-ins -> Badware Risks

So I think it's not a Firefox issue but probably an uBlock Origin one. I'll report if I experience it again with those filters disabled.

Comment 35

[Leonard Ratliff]

I too have ublock origin installed, so you're probably right about it being relevant. I also have the option for "set focus to the web page instead of the address bar" enabled in the New tab override add on, so not sure if that's something others have installed too but could potentially be relevant.

Comment 36

[Leonard Ratliff]

However, had both ublock and new tab override installed in previous versions of Firefox and never had this issue until a few months ago.

Comment 37

[Alice0775 White]

I am original reporter.
This bug is reproduced with new profile(i.e. no addons installed).

Comment 38

[Leonard Ratliff]

Thanks for the clarification. No argument here.

Comment 39

[quimnuss]

Can confirm it still happens, albeit way more less frequently with the ublock badware risks disabled. I guess something changed in firefox that now causes this.

Comment 40

[Peter Cassidy]

The first two workarounds mentioned by quimnuss do not work in Windows 10 for me. Neither does turning off uBlock filters – Badware risks in the Filter Lists tab in uBlock Origin. Changing focus does work. The bug is now 100% reproducible for me. Previously it was 40% reproducible.

Comment 41

[Ed]

See also https://support.mozilla.org/en-US/questions/1435956#answer-1628767.

Comment 42

[elitedevx]

I'm able to reproduce this bug without any extensions installed on a brand new profile (Firefox 121 on Linux 6.6.10).

The only workaround is to click into the address bar, swap tabs or just play around with random UI and then right click the selected text again.

This is a pretty annoying bug that affects a core functionality of the UX, any updates on a patch or fix?

Comment 43

[Peter Van der Beken [:peterv]]

Any progress will be posted here.

Comment 44

[Mista]

Same problem here with latest Windows 10 64 bit and latest firefox.
What I noticed: When I allow googletagmanager.com in ublock, then copy and paste with the mouse works flawlessly.

Comment 45

[lexlexlex]

That sounds unrelated. Since the issue is worked around simply by switching input focus, which would happen when opening the ublock origin configuration and focusing its allow list editor, the workaround would happen. A simpler workaround is to click the address bar.

Comment 46

[Leonard Ratliff]

Doesn't matter anyhow, it's already been 100% determined that the problem happens WITHOUT Ublock even installed. So, references to Ublock are a waste of time now. This is purely a FF problem. On five systems, of varying age, some running Windows 10 and some on 11, and one on 8.1, I can repeat the problem on ALL of them, with or without Ublock installed. All of which have FF and none of which display the problem on Chrome or any of the Chromium variants.

Comment 47

[elitedevx]

For what it's worth, I added googletagmanager.com to uBlock allow list and it does indeed correct the issue -- obviously, it's not the proper fix, but it does work as workaround for the time being... for whatever reason.

Comment 48

[Leonard Ratliff]

No, actually it does not. Besides which you yourself said you were able to reproduce the problem with NO extensions installed at all. We assume that includes Ublock, so this is not helpful in any meaningful way since Ublock cleary ISN'T the problem.

Comment 49

[elitedevx]

Instead of getting so aggressive, go ahead and try it for yourself.

For the record, I am able reproduce this problem perfectly and I still am able to reproduce it by removing the rule and or extension. With the extension installed, and the rule in place, the issue is completely mitigated. Perhaps it's caused by some Google advertising JavaScript or something or an interaction with it. I don't know, but I do know this works 100% at mitigating the issue.

Also, I never said that Ublock is the problem -- I'm just confirming for anyone that is experiencing this issue, this is a workaround until someone can properly fix the root cause.

Comment 50

[sysdadmin]

(In reply to elitedevx from comment #49)

Instead of getting so aggressive, go ahead and try it for yourself.

For the record, I am able reproduce this problem perfectly and I still am able to reproduce it by removing the rule and or extension. With the extension installed, and the rule in place, the issue is completely mitigated. Perhaps it's caused by some Google advertising JavaScript or something or an interaction with it. I don't know, but I do know this works 100% at mitigating the issue.

Also, I never said that Ublock is the problem -- I'm just confirming for anyone that is experiencing this issue, this is a workaround until someone can properly fix the root cause.

i don't know how you say that, your workaround DOES NOT fix anything, please stop spreading nonsense, this bug is already annoying enough without people giving false advice

Comment 51

[Peter Cassidy]

The easiest and simplest workaround of all and surprisingly has not been mentioned and which I find works is to highlight text and press Ctrl-C.

Comment 52

[elitedevx]

(In reply to sysdadmin from comment #50)

i don't know how you say that, your workaround DOES NOT fix anything, please stop spreading nonsense, this bug is already annoying enough without people giving false advice
I'm not going to continue arguing with you (or anyone), it's not nonsense. I don't understand why you're so militant while "assuming" it doesn't work when it's already been confirmed 3 or 4 other times in this thread that there's an identified interaction between this bug and Ublock extension. I'm not just pulling things out of my ass, I tried it, and the issue is completely mitigated. I cannot reproduce it at all anymore, under any situation. With the extension disabled (or enabled with tag manager blocked) I can reproduce it 100% perfectly.
And for the last time, I'll state that this isn't the CAUSE or the FIX, this is a WORKAROUND until this can be properly fixed.

Comment 53

[[e-mail]]

I added googletagmanager.com to uBlock allow list and it does indeed correct the issue

What exactly are you referring to with "allow list"? There is nothing labeled as this in uBO.

If you are referring to the "Trusted sites" pane, adding googletagmanager.com to it would accomplish absolutely nothing since the trusted site directives concern only the URLs appearing in the address bar, nothing else.

Comment 54

[Mista]

I have to correct myself:
I didn't alow googletagmanager.com in ublock, but in NoScript addon.
Sorry, my mistake.

Comment 55

[keysephiroth]

Got the same problem, all add-ons deactivated and the context menu option "copy" is still greyed out. Had the same problem since at least two Firefox versions ago.
As the others have stated, the only way to temporarily fix it is by unfocusing (switching tab, clicking the adress bar, clicking on Firefox UI elements / toolbar).

Firefox version: 122.0 (64-bit)
OS: Linux Mint 21.3 Cinnamon ver. 6.0.4

Comment 56

[me]

If it helps fellow sufferers or those working on this bug the Copy/Paste Plaintext add-on does not suffer from this issue

https://addons.mozilla.org/en-GB/firefox/addon/copy-plaintext/

Comment 57

[Tron.Tronix]

(In reply to me from comment #56)

If it helps fellow sufferers or those working on this bug the Copy/Paste Plaintext add-on does not suffer from this issue

https://addons.mozilla.org/en-GB/firefox/addon/copy-plaintext/

Ich kann jetzt nicht genau sagen ab welcher Version es anfing aber ab Ende 2023 war es nach ein Update von Firefox auf einmal da leider sehr sporadisch aber es nervt echt schon.

Für mich war es zum Schluss nicht mehr brauchbar („11.2023“) weil wenn es drauf ankommt was zu Kopieren der Menüpunkt grau hinterlegt ist, bin zur ESR Version ausgewichen was einbandfrei läuft.

Jetzt nach ihren Beitrag mit dem Copy/Paste Plaintext add-on habe ich es noch mal versucht in der 122.0.1 (64-Bit) und ja („Copy Plain Text == add-on“) geht auch wenn Kopieren in Menüpunkt grau hinterlegt ist, das ist zwar nicht die Lösung aber man kann wieder mit der Version von Firefox arbeiten.

Ich hoffe sehr dass man den Fehler ("Bugs") noch findet.

System:
Firefox Version: 122.0.1 (64-bit) Menüleiste und Lesezeichen-Symbolleiste
OS: Windows 10 (64-bit)

Comment 59

[github]

hi i still have the same problem, very frustrating. 122.0.1 (64-Bit)

Comment 60

[mr.twait]

I'm also experiencing this bug on the latest firefox on Windows 10

Comment 62

[lexlexlex]

Should the title of this ticket be changed to demonstrate that this ticket is the officially-acknowledged ticket for this issue? The current title's grammar makes it look unofficial or not acknowledged, so potential bug reporters searching for this issue may not realize it has been acknowledged, which may be contributing to various duplicate reports. Here are some suggestions:

• "Clipboard actions in page context menus are disabled in some cases"
• "Clipboard actions in page context menus become disabled under some circumstances"
• "Copy and paste context menu entries are sometimes disabled"

Comment 64

[Tom S [:evilpie]]

Peter, any update on this? I can actually reproduce this with the steps in bug 1887229.

Comment 65

[salvatoreN]

Attachment: Same bug: plasma 6.0.3, firefox 124.0.1, Arch with Wayland

Also here same bug (like from video).

Comment 66

[Test Test]

Hi I have the same problem with the disabled copy button. After clicking around it is enabled after some seconds. This problem came suddenly with one update.

Comment 67

[samg381]

This has happened to me 10+ times daily for the past year. How on earth is this still an issue? Fix. it.

Comment 69

[Ehatari]

I tested this on Linux and Mac.
This issue still happend in Firefox 124.0.2

Comment 70

[gigant2006]

Firefox 125.02 still is not working, looks like time to switch browser.

Comment 71

[Donal Meehan [:dmeehan]]

:sefeng could this be triaged for a priority?
It's an S2 bug

Comment 72

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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

:sefeng could this be triaged for a priority?
It's an S2 bug

Yup, it's P2. And we've got a recording of this issue and we've been debugging it.

Comment 73

[dreamer8]

Confirmed with the second steps to reproduce, but not always, try these steps:

• copy to clipboard https://www.bbc.com/future/article/20240521-these-wildlife-corridors-help-grizzly-bears (do not open this site in other tab)
• open https://www.google.com/ in a tab
• at the same tab (google), click the address bar and press Ctrl+V and Enter
• click on Go back button (or Alt+Left Arrow)
• click on Go forward button (Alt+Right Arrow)
• double click any word to select it, e.g. tunnels
• right click

If the "copy" item is available, repeat these steps 5 - 10 times:

• press Esc key
• Alt+Left Arrow
• Alt+Right Arrow
• double click any word to select it, e.g. tunnels
• right click

Workaround - toggle reader view, press F9 twice, this fixes it for me, always.

The only issue is, that reader view is not available at all sites.

Another workaround - duplicate tab.

Firefox 126.0 (64-bit) (portable), Windows 10 22H2 64-bit.

Tested also in private browsing window, where all extensions are disabled, I can reproduce it too, but not every time either.

Confirmed also in Firefox Nightly, latest version 128.0a1 (2024-05-24) (64-bit), default settings, no extensions!

Comment 75

[lexlexlex]

Workaround - toggle reader view, press F9 twice, this fixes it for me, always.

The only issue is, that reader view is not available at all sites.

Another workaround - duplicate tab.

There's an easier workaround documented in this ticket. Focusing the address bar by clicking it works around the issue immediately without needing any new tabs, reader view, or anything like that.

Comment 76

[mozillaonly]

Has there been any movement on this? I have concern that such a basic feature is broke and doesn't seem to be in any hurry to fix?

Should this ticket be reassigned?

Comment 77

[Mista]

(In reply to mozillaonly from comment #76)

Has there been any movement on this? I have concern that such a basic feature is broke and doesn't seem to be in any hurry to fix?

Should this ticket be reassigned?

Totally agree!

Comment 78

[samg381]

The fact that this hasn't been fixed is utterly hilarious. I can't think of anything more fundamental to a web browser than copy + paste, and the fact that Mozilla developers treat this issue with such little importance is extremely disturbing, and makes me question how they treat internal / undisclosed security issues / CVEs. You literally have people who have 100% reproduced and diagnosed the error in this thread right now. This is the most pathetic bug report I've ever had the displeasure of returning to. Fix. it.

Comment 79

[github]

Normally i don't think a bugtracker is the right place to get upset. But in this case i can understand it.
I'm an advocate of firefox and roll out the browser to clients and the company i work for as standard. But this bug regularly drives me up the wall. Time to switch browsers.

Comment 80

[Ryan VanderMeulen [:RyanVM]]

Per comment 72, the team responsible for this bug is working to fix it. More +1 and advocacy comments aren't helping that happen faster but are adding unnecessary noise to this bug. A reminder that there are etiquette expectations when interacting in Bugzilla - it's not a free-for-all discussion forum.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

I'm restricting comments to keep further discussion focused where it needs to be on fixing this bug and getting it into a shipping release as soon as can be reasonably done.

Comment 81

[Sean Feng [:sefeng]]

So the issue here is that when a page goes to BFCache, it'd set the active browsing context to null, and the page that is about to show would update the active browsing context to itself. And these two operations are racy because they are triggered in different processes with different actionId. We are going to explore some potential solutions.

I am first going to try to make the page that goes to BFCache to not updating the active browsing context because we know it'll be updated by the page that's about to show. I'll try this and see what breaks.

If the above doesn't work, I'll need to make they use the same actionId, so that the one that sets the active browsing context to non-null will always win. This might requires converting IsInBFCache to be an IPC message rather than synced field, so that the actionId can be passed over from parent to child.

If folks have different ideas, let me know!

Comment 82

[Sean Feng [:sefeng]]

Attachment: Bug 1863246 - Make the page that enters BFCache not asking the parent process to update the active browsing context

Currently, when a page enters BFCache, it updates the parent process
for the active BC; however, the page that is about to show will do the
same. These two operations are triggered in different processes with
different active id, they are racy and problematic.

This patch fixes the above issue by not updating the parent process
when a page enters BFCache.

This only applies to BFCacheInParent is enabled.

Comment 84

[Will]

With all due respect to the devs, this is very much a P1, not a P2

Comment 86

[Tom Schuster (MoCo)]

There doesn't seem to have been any activity on the patch for two weeks. Can you please check?

Comment 87

[Sean Feng [:sefeng]]

the patch got approved, I'll try to land the patch soon.

Comment 88

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5bbf15b6acb0
Make the page that enters BFCache not asking the parent process to update the active browsing context r=peterv,dom-core

Comment 89

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/5bbf15b6acb0

Comment 90

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

The patch landed in nightly and beta is affected.
:sefeng, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox130 to wontfix.

For more information, please visit BugBot documentation.

Comment 94

[Ryan VanderMeulen [:RyanVM]]

Given the number of dupes and high visibility of this bug, I think we probably want to uplift this to both ESR branches as well assuming the risk isn't too high.

Comment 95

[Sean Feng [:sefeng]]

Comment on attachment 9411317 [details]
Bug 1863246 - Make the page that enters BFCache not asking the parent process to update the active browsing context

Beta/Release Uplift Approval Request

• User impact if declined: The copy button in context menu may be unusable sometimes
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: I’d like to get a QA test

Steps in comment 73 should work

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch itself isn’t complex. It should be low risky as long as it passes our automated tests.
• String changes made/needed:
• Is Android affected?: Unknown

Comment 96

[Sean Feng [:sefeng]]

Comment on attachment 9411317 [details]
Bug 1863246 - Make the page that enters BFCache not asking the parent process to update the active browsing context

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This resolves a bug where the copy button in context menu is disabled sometimes.
• User impact if declined: Copy button is not usable sometimes, leads to bad UX
• Fix Landed on Version: 131
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It is not risky because the patch is trivial

Comment 97

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9411317 [details]
Bug 1863246 - Make the page that enters BFCache not asking the parent process to update the active browsing context

Approved for 130.0b8.

Comment 98

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/759c499e691d

Comment 99

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9411317 [details]
Bug 1863246 - Make the page that enters BFCache not asking the parent process to update the active browsing context

Approved for 128.2esr.

Comment 100

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/5c96a83fe717

Comment 101

[Ryan VanderMeulen [:RyanVM]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Longstanding issue with a large number of duplicate bugs filed
[Affects Firefox for Android]: No
[Suggested wording]: Fixed: Copy and Paste context menu items intermittently not enabled when expected.
[Links (documentation, blog post, etc)]: n/a

Comment 102

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9411317 [details]
Bug 1863246 - Make the page that enters BFCache not asking the parent process to update the active browsing context

Approved for 115.15esr.

Comment 103

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/92b963e31868

Comment 104

[Ciprian Georgiu, Desktop QA]

I have reproduced this issue using the alternative steps from comment 0, on an affected Firefox build, 129.0 (20240801122119).

The issue is verified as fixed on the latest builds available, latest Nightly 131.0a1, Beta 130.0b8, Esr 128.2 and 115.15. Tested with Windows 10 x64.

Comment 105

[Dianna Smith [:diannaS]]

Added to Fx130 release notes

Fixed an issue where Copy and Paste context menu items intermittently were not enabled when expected.