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

71–80 of 99 posts

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

#71

Post by oefrha »

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…

This post has 100 points right now and there are already 10+ people in the comments saying they have experienced it. Given the typical distribution of lurkers, I’d say a good proportion of the votes come directly from people who think they’re affected. Probably more people wrongly attribute this kind of annoyance to websites. Bugs in popular software just affect more people, hard to reproduce or not.

Not sure why you’re so defensive and eager to shut it down that you have to post a barrage of comments to this thread, including saying roughly the same things in three comments.

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

#72

Post by dyauspitr »

I try to use Firefox a lot. One of the main issues I have is 4K video on YouTube gets stuck and skips a lot of the time on Windows 11 when using Firefox. I’ll then just play it on chrome and it plays flawlessly. It’s not the internet connection (1 Gbps) and not the graphics card (4080). Anyone else having this issue?

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

#73

Post by throwup238 »

hunter2_ wrote: post #64
heavyset_go wrote: post #59

Earlier quoted context omitted.

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.

It works on my machine!

Repeating that joke over and over again is key to a full career in software engineering.

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

#74

Post by hunter2_ »

throwup238 wrote: post #73
hunter2_ wrote: post #64

Earlier quoted context omitted.

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

It works on my machine! Repeating that joke over and over again is key to a full career in software engineering.

Ah! Perfect. On 127.0.0.1 it works just fine.

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

#75

Post by tssge »

dyauspitr wrote: post #72

I try to use Firefox a lot. One of the main issues I have is 4K video on YouTube gets stuck and skips a lot of the time on Windows 11 when using Firefox. I’ll then just play it on chrome and it plays flawlessly. It’s not the internet connection (1 Gbps) and not the graphics card (4080). Anyone else having this issue?

I've had a similar issue with YouTube and it turned out to be AV1. You seem to have quite new GPU compared to me so I guess AV1 isn't a likely culprit, but perhaps Firefox is unable to offload AV1 to the GPU even if supported?

For me this caused YouTube to use CPU for AV1 decoding (as my GPU has no decoding support), resulting in stuttering, dropped frames etc. I disabled AV1 support in my browser so that YouTube is "forced" to serve me VP9 and after that video decoding was offloaded to my GPU resolving the issue.

YouTube started serving AV1 by default rather recently for the higher bitrate quality settings.

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

#76

Post by 462436347 »

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…

I don't agree. This is something so basic that there isn't, from a Q&A standpoint, a justification for it ending up broken for 2/3rds of a year, and where the kind of hard-line stance Linus takes against certain kinds of regressions is warranted. Also consider that a lot of users have been unhappy for years with how the foundation is running and spending money (e.g., more and more on things unrelated to FF, like this: https://blog.mozilla.org/en/mozilla/introducing-mozilla-ai-i...).

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

#77

Post by kstenerud »

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…

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.

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

#78

Post by sgc »

wizzledonker wrote: post #51
gchamonlive wrote: post #6

From the bug report: 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 It doesn't seem like it's a website doing something it shouldn't be and breaking RFC. It's really a bug in firefox. Also, the scope is very specific and kinda…

I can reproduce. Firefox 127.0 under wayland, arch linux

I can reproduce as well using FF 127.0.2 on x11, ubuntu. But I can make it even odder. Select the text, right click, copy is grayed out. Hit the back button without any other interaction, then go forward again from google.com and the text will still be selected. Hit right click again, and copy is now possible. Select any other text, and it is working as expected.

So I opened dev tools and saw there were network requests for google.com and play.google.com on the ftp page when it loaded even though there is nothing in the page source that would make those requests. When I force reload with cache disabled, these requests are not present. This looks like bad behavior by google.com somehow leaking into the next page.

So I found another random ftp page, and I can reproduce all of this there: https://ftp.wildfire.gov/public/incident_specific_data/

Is it the lack of js, not something more arcane in the ftp templating on those sites? I can reproduce all of this at http://motherfuckingwebsite.com/ which is js free, and also at https://news.ycombinator.com/, which has js (be careful to select something like "### points" below a post, which has no hyperlink)

EDIT: I guess my theory was wrong, because I read at the bottom of the bugzilla:

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.

Based on the comments there, by setting BFCacheInParent to false in about:config, this bug is gone for me.

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

#79

Post by fourteenfour »

kibwen wrote: post #67
teruakohatu wrote: post #61

Earlier quoted context omitted.

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 wind…

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.
Post reply on HN