Open Bug 1863246 Opened 9 months ago Updated 8 hours ago

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

Categories

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

Firefox 97
Desktop
Windows 10
defect

Tracking

()

ASSIGNED
Tracking Status
firefox-esr115 --- wontfix
firefox119 --- wontfix
firefox120 --- wontfix
firefox121 --- wontfix
firefox122 --- wontfix
firefox123 --- wontfix
firefox124 --- wontfix
firefox125 --- wontfix
firefox126 --- wontfix
firefox127 --- wontfix
firefox128 --- wontfix
firefox129 --- wontfix
firefox130 --- affected

People

(Reporter: alice0775, Assigned: sefeng)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

+++ 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

Summary: Copy and Past Bug → Copy and Past context menu are disabled in some case

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.

Flags: needinfo?(nika)
Summary: Copy and Past context menu are disabled in some case → Copy and Paste context menu are disabled in some case

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.

Flags: needinfo?(nika) → needinfo?(masayuki)
Component: DOM: UI Events & Focus Handling → DOM: Navigation
Regressed by: 1720990
No longer regressed by: 1732358

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.

Flags: needinfo?(masayuki)

Masayuki, could you assign a severity?

Flags: needinfo?(masayuki)
Duplicate of this bug: 1860426

(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.

No longer depends on: 1860426

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

Flags: needinfo?(masayuki)

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

Flags: needinfo?(hsivonen)

(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.

See Also: → 1761430

(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.

Flags: needinfo?(hsivonen)

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

Flags: needinfo?(peterv)

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.

(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.

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.

Duplicate of this bug: 1857054

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

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.

Assignee: nobody → peterv
Status: NEW → ASSIGNED
Flags: needinfo?(peterv)
Duplicate of this bug: 1866650
Severity: -- → S3
Severity: S3 → S2

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

Duplicate of this bug: 1868548

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.

@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.

(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).

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.

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.

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.

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.

Duplicate of this bug: 1871049

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

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

Thanks for the clarification. No argument here.

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?

Flags: needinfo?(peterv)

Any progress will be posted here.

Flags: needinfo?(peterv)

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.

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

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/

(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)

Duplicate of this bug: 1880880
No longer blocks: 1879778
Duplicate of this bug: 1879778

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"
Summary: Copy and Paste context menu are disabled in some case → Copy and Paste context menu entries are sometimes disabled when they should not be
Duplicate of this bug: 1887229

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

Flags: needinfo?(peterv)

Also here same bug (like from video).

Duplicate of this bug: 1890688

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

Flags: needinfo?(sefeng)
Flags: needinfo?(sefeng)
Priority: -- → P2

(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.

Flags: needinfo?(peterv)

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!

Duplicate of this bug: 1898865

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.

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.

Restrict Comments: true

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!

Assignee: peterv → sefeng

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.

Duplicate of this bug: 1909127
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: