Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bugzilla.mozilla.org

Post reply on HN
Print view View original

61–70 of 99 posts

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

#61

Post by teruakohatu »

db48x wrote: post #7
462436347 wrote: post #2

Specifically the right-click menu option, which is often greyed out for no apparent reason. This happens on both Windows and Linux. Ctrl+C still works, but how does Firefox break something as basic as the right-click menu and copy in 2024?

Because the bug involves sending and receiving messages to multiple other processes. Each webpage you visit is potentially in a different process, and each of those processes maintains its own selection state (that state is visible to javascript running in the page, and you don't want to leak what you copy on this page to any other, so it would be hard to put it anywhere else). There is only one context menu though (…

I hear what you are saying but the entire architecture is build around IPC message passing. A lot of user interaction will work the same way. There is nothing inherently more difficult about this scenario than many others within Firefox.

If it has such a convoluted code path that it cannot even be debugged then that’s an issue with the architecture, not that the user has a crazy difficult edge case which every other browser seems to manage.

Judging by the comments a lot of people in this thread have been affected by this issue.

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

#62

Post by photonthug »

db48x wrote: post #7
462436347 wrote: post #2

Specifically the right-click menu option, which is often greyed out for no apparent reason. This happens on both Windows and Linux. Ctrl+C still works, but how does Firefox break something as basic as the right-click menu and copy in 2024?

Because the bug involves sending and receiving messages to multiple other processes. Each webpage you visit is potentially in a different process, and each of those processes maintains its own selection state (that state is visible to javascript running in the page, and you don't want to leak what you copy on this page to any other, so it would be hard to put it anywhere else). There is only one context menu though (…

> maintains its own selection state

This is the real bug. Why is it not global?

Probably related to how if you go to google, leave the browser for terminal or ide, you still get a google hover text that brands everything else on your desktop depending on where your mouse was when you left the browser.

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

#64

Post by hunter2_ »

heavyset_go wrote: post #59
wizzledonker wrote: post #51

Earlier quoted context omitted.

I can reproduce. Firefox 127.0 under wayland, arch linux

Which compositor? I'm trying on 127.0.2 and can't seem to do it, and I'm on kwin_wayland.

There's a joke somewhere in here about trying it locally, but I can't quite... Nevermind.

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

#65

Post by riffic »

krsdcbl wrote: post #49
gessha wrote: post #23

Earlier quoted context omitted.

No good browser.

its a conundrum. WebKit is a great engine, but nearly all good implementations are provided by Corps who's interests have very little to do with providing a good browser, and lots to do with what you do with that browser. Firefox in turn might be one of the last major alternative Engines that is maintained by a company who's mission indeed is in a large parts to provide you with a good browser, but seems to progressi…

*whose mission

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

#66

Post by tavavex »

I get that maintaining browsers is hard, but it feels like Firefox has been slowly falling behind in terms of supporting and expanding on its core functionality. I experienced this copy bug for a long while now (for some reason, visiting Wikipedia seems to trigger it most often), and any such hitches seem to take months to resolve. It took five months[1] for Mozilla to fix an issue that made YouTube borderline unusable, especially on higher resolutions. Features like HDR video support have been requested for years and are seemingly not coming despite every other browser supporting it for ages. And yet, there's no viable non-Chromium alternatives.

[1] - https://bugzilla.mozilla.org/show_bug.cgi?id=1878510

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

#67

Post by kibwen »

teruakohatu wrote: post #61
db48x wrote: post #7

Earlier quoted context omitted.

Because the bug involves sending and receiving messages to multiple other processes. Each webpage you visit is potentially in a different process, and each of those processes maintains its own selection state (that state is visible to javascript running in the page, and you don't want to leak what you copy on this page to any other, so it would be hard to put it anywhere else). There is only one context menu though (…

I hear what you are saying but the entire architecture is build around IPC message passing. A lot of user interaction will work the same way. There is nothing inherently more difficult about this scenario than many others within Firefox. If it has such a convoluted code path that it cannot even be debugged then that’s an issue with the architecture, not that the user has a crazy difficult edge case which every other…

> Judging by the comments a lot of people in this thread have been affected by this issue.

I'm sincerely surprised by how many people on Hacker News are apparently copy/pasting with the context menu rather than using Ctrl+C.

PSA for some common keyboard shortcuts:

Alt+Left to navigate back (Alt+Right to navigate forward)

Ctrl+T to open a new tab (Ctrl+Shift+T to reopen previously closed tab)

Ctrl+N to open a new window (Ctrl+Shift+N to reopen previously closed window)

Ctrl+Shift+P to open a new private window

Ctrl+W to close the current tab (Ctrl+Q to close all windows)

Ctrl+R to reload the page (Ctrl+Shift+R to do a forced reload of cached assets)

Ctrl+Plus to zoom in (Ctrl+Minus to zoom out, Ctrl+Zero to reset zoom level)

Ctrl+Tab to focus the next tab in line (Ctrl+Shift+Tab for the previous tab in line)

Alt+One to focus the first tab (Alt+Two for the second tab, etc.)

Ctrl+F to search the text of the page (/ (forward slash) for quick find)

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

#68

Post by Lorin »

kelnos wrote: post #48

Not sure why this is big news, big enough to be in the #1 spot right now. From reading the comments on the bug, it seems to be an issue that's hard to reliably reproduce, and -- despite how simple it sounds from the editorialized HN title -- it involves interactions between different parts of the browser, and it's hard to track down and fix. Nonetheless, there are some proposed fixes, and I expect a near-future relea…

If anyone is curious about another 'fun' Windows only bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1856462

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

#69

Post by db48x »

photonthug wrote: post #62
db48x wrote: post #7

Earlier quoted context omitted.

Because the bug involves sending and receiving messages to multiple other processes. Each webpage you visit is potentially in a different process, and each of those processes maintains its own selection state (that state is visible to javascript running in the page, and you don't want to leak what you copy on this page to any other, so it would be hard to put it anywhere else). There is only one context menu though (…

> maintains its own selection state This is the real bug. Why is it not global? Probably related to how if you go to google, leave the browser for terminal or ide, you still get a google hover text that brands everything else on your desktop depending on where your mouse was when you left the browser.

For one thing, the selection state is visible to the webpage. For another thing, the webpage is where the text lives. Put that way it sounds funny, but think about it. You have a bunch of content processes, each of which is in charge of loading some number of webpages that the user wants to have open. There is a single UI process that the user can interact with. When the user actually initiates a copy, the UI process doesn’t know what text to put into the clipboard. The text is all in the content process! The UI process merely has to figure out which content process to send the messages to, so that the right text ends up in the clipboard. And that's more complicated than it looks because any given page you are looking at might be stored in multiple processes. A page on domain A with a frame that has content from domain B will often have a different content process for both domains, to ensure maximum separation of state between them.

The bug appears to be a race condition in how the state of which content process has the most recent selection is synchronized with the UI process. The patch at the end of the bug report changes it so that when the user unloads a page no message is sent to delete that state. Instead, only whatever page gets loaded or switched to next will send a message to replace the state. This should eliminate the problem.

Left–over tooltips are a completely different kind of problem.

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

#70

Post by tavavex »

Cerium wrote: post #53

I can't believe so many people on HN use the right click copy menu.

Most websites I interact with use the mouse only (writing text aside) - navigation alone can always be done with just the mouse. So, it's often easier and faster to use the context menu if your other hand isn't already on the left side of the keyboard.
Post reply on HN