Edit context menu items are incorrectly disabled/broken after searching with searchfox.org, or www.basschouten.com
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
People
(Reporter: alice0775, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: nightly-community, regression)
User Story
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
Attachments
(2 files)
Reproducible: Sometimes. No reliable steps to reproduce is known.
Steps to reproduce(no reliable steps):
- Open google search results page
- Select some text in input area of the page
- 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.
Reporter | ||
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Odd, I cannot reproduce it with 100.0a1 (2022-03-24) (64-bit) on Windows.
Comment 2•3 years ago
|
||
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•3 years ago
|
||
I can't reproduce either on linux.
Comment 4•3 years ago
|
||
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?
Reporter | ||
Comment 5•3 years ago
|
||
I found a concrete steps to reproduce with new profile.
It is 100% reproducible.
Steps to reproduce:
- Start Nightly with new profile
- Open a new tab
- Visit http://searchfox.org/
- Type
Firefox
in input area at the top of the page. And wait for load page. - Type
mozilla firefox
in address bar and hit Enter to google search and wait for load google results page. - Select text using the mouse in the input area at the top of the page.
- Right click on the selected text
Comment 6•3 years ago
|
||
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 :/
Reporter | ||
Comment 7•3 years ago
|
||
FYI, Disabling fission seems to solve the problem.
Updated•3 years ago
|
Reporter | ||
Comment 8•3 years ago
|
||
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•3 years ago
|
||
: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•3 years ago
|
||
Set release status flags based on info from the regressing bug 1720990
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Comment 11•3 years ago
|
||
Setting fission.bfcacheInParent to false seems to fix this.
Reporter | ||
Comment 12•3 years ago
|
||
(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:
- Start Nightly with new profile
- Open a new tab
- Visit http://searchfox.org/
- Type
Firefox
in input area at the top of the page. And wait for load page.- Type
mozilla firefox
in address bar and hit Enter to google search and wait for load google results page.- Select text using the mouse in the input area at the top of the page.
- 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
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 13•3 years ago
|
||
[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:
- 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
- And then open https://www.basschouten.com/blog1.php in the same tab
- Right click on the page and choose
Select All
--- nothing happens - 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•3 years ago
|
||
(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:
- 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
- And then open https://www.basschouten.com/blog1.php in the same tab
- Right click on the page and choose
Select All
--- nothing happens- Select some text and right click on the page and choose
Copy
--- Nothing copiedActual results:
Context Area Context Menu items are broken.
I have a hard time reproducing this. I still not managed to see this issue...
Reporter | ||
Comment 15•3 years ago
|
||
Screencast https://youtu.be/ca9-4IaKx1g
Comment 16•3 years ago
|
||
I also haven't been able to reproduce this.
Reporter | ||
Comment 17•3 years ago
|
||
If you don't reproduce, repeat from step 2-7 of comment #5 or repeat from step 1-4 of comment #13.
Reporter | ||
Comment 18•3 years ago
|
||
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•3 years ago
|
||
(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 isATOK 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•3 years ago
|
||
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•3 years ago
|
||
I confirmed that I am able to reproduce this following comment 18, with a new profile. I was using Windows Narrator.
Comment 22•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 23•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 24•2 years ago
|
||
I finally managed to reproduce, only on Windows with Windows Narrator enabled and only with the steps from comment 5.
S3 on the logic that a workaround (keyboard shortcuts, ctrl-c, ctrl-v, etc.) exists.
Comment 26•2 years ago
|
||
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•2 years ago
|
||
[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.
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Comment 28•2 years ago
|
||
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?
Updated•2 years ago
|
Comment 29•2 years ago
|
||
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.
Updated•2 years ago
|
Description
•