Hacker News new | ask | show | jobs
by gchamonlive 714 days ago
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 justifies it being low priority. Maybe.

Note that there is another reproduction step sequence that I chose not to put in this comment for the sake of simplicity.

9 comments

It's not generalizable to any arbitrary pair of websites X and Y. Or even X and ftp.mozilla.org. Which I suppose makes sense if it's been in the wild this long without everyone noticing it.
I am able to reproduce this but I noticed that Ctrl+C, Ctrl+V still work even though the `Copy` menu item was disabled. So it is a visual glitch, at least on my machine.
I've noticed this randomly lately. I think it's this bug anyways. The copy and paste menu items are disabled but ctrl-c/v works. On websites that make no sense to have it disabled.
I can't reproduce this at all.
Confirmed on Windows 10 64-bit with Firefox 127.0.2. After right-clicking, the Copy menu entry is disabled. Switching to another tab and back fixes the issue.
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.
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.
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.

I'm able to reproduce this on vanilla Linux Mint, FF version 127.0.2.
I've recently switched from Firefox to Edge until they fix this bug. Every now and then I go back to Firefox hoping it'll be fixed, and then it bites me again.
Now you have 10 problems. But it's always a matter of choosing the problems you want, I guess.

I might argue that this is quite minor in the face of... well... a Microsoft controlled browser, but what do I know

Can't reproduce it on Wayland