[Address bar] All context menu options are disabled after undoing the URL string until the address bar is empty
Categories
(Firefox :: Address Bar, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox86 | --- | unaffected |
firefox87 | --- | unaffected |
firefox88 | --- | verified |
firefox89 | --- | verified |
People
(Reporter: emilghitta, Assigned: emilio)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression, Whiteboard: [proton-context-menus] )
Attachments
(4 files)
Affected versions
- Firefox 88.0a1 (BuildId:20210301093612)
Affected platforms
- Windows 10 64bit
- Ubuntu 20.04 64bit
- macOS 10.14
Steps to reproduce
- Launch Firefox with a clean profile.
- Open a new tab.
- Click on any of the available top sites or on one of the available articles from “Recommended by Pocket”.
- Right click on the address bar.
- Select the “Undo” option.
- Right click on the address bar again.
- Try to select the “Redo” option.
Expected result
- The “Redo” option is enabled and the address bar gets repopulated with the previous address.
Actual result
- The “Redo” option is disabled.
Regression Range
I don’t think that this is a regression. The “Redo” functionality was implemented in Bug1692339
Notes
- For further information regarding this issue please observe the attached screencast.
- This issue is not encountered while manually typing a URL address. In order to reproduce this you have to click on a link.
- This issue is encountered using both proton enabled & proton disabled.
- I took Edge for a spin (since it has the redo functionality for the address bar field as well) and I can’t reproduce this issue there.
Comment 1•3 years ago
|
||
If I undo an operation such that it empties the address bar, in fact all the items are disabled for me (this also shows up in the screenshot) - even though there is clipboard content that could be pasted. That's pre-existing - it seems to have something to do with the address bar dropdown appearing. If I focus something else and then put focus back in the address bar, the right options are enabled. Harry, do you perhaps know what's up here?
Updated•3 years ago
|
Comment 2•3 years ago
|
||
I don't think this pertains to address bar code directly. mozregression pins this down to a change to all XUL <inputs>: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9d4893cc2f992294be0a7989e9f1c67730143154&tochange=2dfddfec015339515a360fe440728538d87527a5
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
No behavior change. We were already returning false for HTML editor +
non-editable so we can simplify it a bit.
Depends on D107511
Assignee | ||
Comment 5•3 years ago
|
||
Otherwise we disable the context menu commands which seems bad. This also
matches the HTML editor.
Depends on D107512
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d4e628da5f2c Avoid to warn always. r=masayuki https://hg.mozilla.org/integration/autoland/rev/6977c659c3b4 Clean up some checks in EditorUtils. r=masayuki
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b4adaa3d8db3 Consider selection editable even if the anchor is the empty <br> element. r=masayuki
Comment 8•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d4e628da5f2c
https://hg.mozilla.org/mozilla-central/rev/6977c659c3b4
https://hg.mozilla.org/mozilla-central/rev/b4adaa3d8db3
Comment 9•3 years ago
|
||
I've reproduced the issue using Fx88.0a1 (2021-03-03).
The issue is verified fixed using Fx88.0b9 and Fx89.0a1 on Windows 10 and Ubuntu 18.04. The issue no longer occurs, the 'redo' functionality works as intended and correctly puts the website back in the URL bar.
Updated•3 years ago
|
Description
•