[db48x]

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 (in the main process), so it has to send a message to the content process to find out if anything is selected or not. It seems that somehow the message is going to the wrong content process, to a page where nothing is selected. The context menu itself then displays exactly the right thing, based on the data it got back.

[teruakohatu]

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.

[kstenerud]

It's a caching issue, so it's by definition as tricky and elusive as a sasquatch.

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

[kibwen]

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

[fourteenfour]

A person selecting text on a webpage is usually using the mouse already. It's reasonable to use the same device to choose the copy command.

[wormius]

Sometimes people gotta jerk, and that leaves only one hand free, which means. Mouse for interaction, Obviously.

But more seriously - FF isn't vim and no I'm not installing vim keybindings. And I do use the keyboard a lot (I've had to teach coworkers the tips for tab navigation for example), when in "type/entry" mode (oh maybe VIM is the right metaphor hmm).

Anyways, sometimes you're just chilling with a few tabs and wanna pop back and forth between a few, and not be in type mode... So mouse it is. And if you're using mouse and hand off the keyboard it's far easier to just use the right click (I've only started doing this the past year or two... likewise I've taken to right click, back from the popup menu instead of dragging mouse across to the back arrow. (but if on keyboard yeah I alt-arrow it).

What i love is how everyone just demands everyone use the interface the exact same way for all purposes and times.

I do get frustrated at my roomie who won't just do it my way, when I ask her to search for something or I'm trying to help with something technical and she's in control of her laptop... though, and in those times I'm 100% right and legit. That's the only exception to my paragraph above.

[photonthug]

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

[db48x]

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.