1761430 - Edit context menu items are incorrectly disabled/broken after searching with searchfox.org, or www.basschouten.com

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Alice0775 White]

Attachment: screenshot

Reproducible: Sometimes. No reliable steps to reproduce is known.

Steps to reproduce(no reliable steps):

1. Open google search results page
2. Select some text in input area of the page
3. Right click

Actual results:
Edit context menu items are incorrectly disabled, when it should be enabled.
Re-selecting text does not fix.
Switch other application and back to Firefox, then the context menu will be displayed correctly.

Expected results:
They are enabled.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Odd, I cannot reproduce it with 100.0a1 (2022-03-24) (64-bit) on Windows.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Refreshing profile does not help to reproduce this, and disabling dom.event.clipboardevents.enabled and dom.events.asyncClipboard does not help to reproduce this too.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

I can't reproduce either on linux.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Switch other application and back to Firefox, then the context menu will be displayed correctly.

Sounds like focus handling trouble, but I don't see any logical change of nsFocusManager in this year except in a shadow DOM...

If it's not a new regression in this year, it seems that bug 1735076 touched related code. Emilio, any ideas?

Comment 5

[Alice0775 White]

I found a concrete steps to reproduce with new profile.
It is 100% reproducible.

Steps to reproduce:

1. Start Nightly with new profile
2. Open a new tab
3. Visit http://searchfox.org/
4. Type Firefox in input area at the top of the page. And wait for load page.
5. Type mozilla firefox in address bar and hit Enter to google search and wait for load google results page.
6. Select text using the mouse in the input area at the top of the page.
7. Right click on the selected text

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Not really, that code should only affect focusrings and so, not other focus handling. I couldn't repro either even with comment 5, but the page I get looks different from comment 0 :/

Comment 7

[Alice0775 White]

FYI, Disabling fission seems to solve the problem.

Comment 8

[Alice0775 White]

Regression Window(with fission enabled):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cfbf53c78245c80d6e3b6d75801eb37d79647d02&tochange=089fb1e6379b180a8474e1ea22a5aec4c4ec224c

Regressed by: Bug 1720990

(Four builds between the good and bad builds were not testable because the browser crashes as soon as a Google search result is displayed. Also crashes in bing search results as well)

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

:peterv, since you are the author of the regressor, bug 1720990, could you take a look?
For more information, please visit auto_nag documentation.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 11

[Alice0775 White]

Setting fission.bfcacheInParent to false seems to fix this.

Comment 12

[Alice0775 White]

(In reply to Alice0775 White from comment #5)

I found a concrete steps to reproduce with new profile.
It is 100% reproducible.

Steps to reproduce:

1. Start Nightly with new profile
2. Open a new tab
3. Visit http://searchfox.org/
4. Type Firefox in input area at the top of the page. And wait for load page.
5. Type mozilla firefox in address bar and hit Enter to google search and wait for load google results page.
6. Select text using the mouse in the input area at the top of the page.
7. Right click on the selected text

In addition to the above str, Select All in page content area context menu is also broken.
6'. Right click on the content area
7'. Choose Select All

Actual Results:
No thing happens

Comment 13

[Alice0775 White]

[Tracking Requested - why for this release]:
Edit context menu sometimes broken.
This bug seems to have a high potential to happen on other pages as well.

Reproducible: The following str can also reproduce the bug 100%.

Another steps to re@roduce:

1. Open https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A3%E3%82%AD%E3%83%9A%E3%83%87%E3%82%A3%E3%82%A2 in new tab
2. And then open https://www.basschouten.com/blog1.php in the same tab
3. Right click on the page and choose Select All
   --- nothing happens
4. Select some text and right click on the page and choose Copy
   --- Nothing copied

Actual results:
Context Area Context Menu items are broken.

Comment 14

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Alice0775 White from comment #13)

[Tracking Requested - why for this release]:
Edit context menu sometimes broken.
This bug seems to have a high potential to happen on other pages as well.

Reproducible: The following str can also reproduce the bug 100%.

Another steps to re@roduce:

1. Open https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A3%E3%82%AD%E3%83%9A%E3%83%87%E3%82%A3%E3%82%A2 in new tab
2. And then open https://www.basschouten.com/blog1.php in the same tab
3. Right click on the page and choose Select All
   --- nothing happens
4. Select some text and right click on the page and choose Copy
   --- Nothing copied

Actual results:
Context Area Context Menu items are broken.

I have a hard time reproducing this. I still not managed to see this issue...

Comment 15

[Alice0775 White]

Screencast https://youtu.be/ca9-4IaKx1g

Comment 16

[Peter Van der Beken [:peterv]]

I also haven't been able to reproduce this.

Comment 17

[Alice0775 White]

If you don't reproduce, repeat from step 2-7 of comment #5 or repeat from step 1-4 of comment #13.

Comment 18

[Alice0775 White]

OK, I think I may have found one of the factors.

You need activate accessibility tools such as Windows Narrator to reproduce this.
In my case it is ATOK Insight of Japanese IME.

Workaround:
accessibility.force_disabled = 1
or
fission.bfcacheInParent = false

Comment 19

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Alice0775 White from comment #18)

OK, I think I may have found one of the factors.

You need activate accessibility tools such as Windows Narrator to reproduce this.
In my case it is ATOK Insight of Japanese IME.

Workaround:
accessibility.force_disabled = 1
or
fission.bfcacheInParent = false

Thank you so much for trying to get this step.

Comment 20

[James Teh [:Jamie]]

Even if having a11y enabled makes this more reproduceable, I can't see any way a11y could impact the Edit menu. A11y does add DOM selection event handlers so it can watch for selection changes, but it doesn't tweak the selection unless requested by some a11y client. My guess is that having a11y enabled changes timing which makes this more likely somehow.

Comment 21

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I confirmed that I am able to reproduce this following comment 18, with a new profile. I was using Windows Narrator.

Comment 22

[juraj.masiar]

For me the "Copy" menu can get disabled also if I move tab between two windows. Then it stays broken even after refreshing the page. I was able to reproduce it with a clean profile in 100.0b8.

Comment 23

[juraj.masiar]

Attachment: 13s long demonstration - moving tab between windows

13 sec. long demonstration - moving tab between windows breaks copy option.
I'm not sure if it's related to this specific bug but may be related.

Comment 24

[Peter Van der Beken [:peterv]]

I finally managed to reproduce, only on Windows with Windows Narrator enabled and only with the steps from comment 5.

Comment 25

[Henri Sivonen (:hsivonen)]

S3 on the logic that a workaround (keyboard shortcuts, ctrl-c, ctrl-v, etc.) exists.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the bug is marked as tracked for firefox101 (beta).
:hsinyi, could you consider increasing the severity of this tracked bug?

For more information, please visit auto_nag documentation.

Comment 27

[Hsin-Yi Tsai (she/her) [:hsinyi]]

[Tracking Requested - why for this release]:
According to comment 25 that workaround exists, and according to comment 24, the condition for reproducing this is fairly restricted, request to consider to denominate this so not tracked for release.

Peter, please feel free to chime in if you have more findings. Thank you.

Comment 28

[Donal Meehan [:dmeehan]]

Can the priority for this ticket be set?
Since it seems reproducible based on the above comments, do we plan on fixing this in an upcoming release?

Comment 29

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Setting to P3 that we don't have a concrete plan on this for an upcoming release. More related reasoning as a previous comment 27. Thanks.