'Go back one page' button is greyed out
Categories
(WebExtensions :: Android, defect)
Tracking
(Not tracked)
People
(Reporter: flynparker824, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36
Firefox for Android
Steps to reproduce:
I opened a new tab (via right click -> open link in new tab) and WHILE (crucial!) the targeted site (lets call it http://www.deanstank.net/) is being connected to, I hit a bookmark button from another site (lets call it www.xyz.com) that is listed in the bookmarks toolbar.
Actual results:
Firefox discontinued connecting to www.abc.com and opened www.xyz.com in the new tab instead (correct behavior) BUT it does NOT allow returning to www.abc.com (which was targeted in the first place) via the 'go back one page' button, which remains greyed out as if there had never been a previously targeted site. So just because the connection to the originally targeted site was never established, Firefox behaves as if it had never been targeted at all.
Expected results:
The 'go back one page' button should not be greyed out, one should be able to return to the previously targeted site as is the case whenever one waits until the originally targeted site is loaded and THEN hits a bookmark button. In this case, the 'go back one page' button is clickable. If this behavior is intentional (= "not a bug but a feature", an assumption supported by the fact that this behavior is relatively new to Firefox so it seems almost intentionally included) I seriously doubt the logic behind it. 'Going back one page' should always refer to the previous action of the user and not to whether a connection to the previously targeted page had been established or not.
(In reply to alexweefs from comment #0)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36
Firefox for AndroidSteps to reproduce:
I opened a new tab (via right click -> open link in new tab) and WHILE (crucial!) the targeted site (lets call it http://www.deanstank.net/) is being connected to, I hit a bookmark button from another site (lets call it www.xyz.com) that is listed in the bookmarks toolbar.
Actual results:
Firefox discontinued connecting to www.abc.com and opened www.xyz.com in the new tab instead (correct behavior) BUT it does NOT allow returning to http://www.deanstank.net/ (which was targeted in the first place) via the 'go back one page' button, which remains greyed out as if there had never been a previously targeted site. So just because the connection to the originally targeted site was never established, Firefox behaves as if it had never been targeted at all.
Expected results:
The 'go back one page' button should not be greyed out, one should be able to return to the previously targeted site as is the case whenever one waits until the originally targeted site is loaded and THEN hits a bookmark button. In this case, the 'go back one page' button is clickable. If this behavior is intentional (= "not a bug but a feature", an assumption supported by the fact that this behavior is relatively new to Firefox so it seems almost intentionally included) I seriously doubt the logic behind it. 'Going back one page' should always refer to the previous action of the user and not to whether a connection to the previously targeted page had been established or not.
|
||
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Hi alexweefs,
I was unable to reproduce this issue in Windows 10, on Firefox Nightly 94.0a1 (2021-09-24) (64-bit) and Release 92.0.1 (64-bit) versions.
Did you experience this bug in Firefox Desktop versions? If so, please share further information with us, like screenshots, screen recording, or more specific steps.
Since your User agent reads 'Firefox for Android', I set the component accordingly, in order to get the dev team involved.
'WebExtensions: Android' team: if the component is not relevant please change it to a more appropriate one.
Regards,
Jerónimo.
|
||
Comment 4•4 years ago
|
||
Hello,
I also could not reproduce the issue on the latest Nightly (94.0a1/20210926210158) or Release (92.0.1/20210922161155) on Windows 10 x64 and Ubuntu 16.04 LTS.
Hi Alex,
Thanks for confirming this issue is no longer occuring on your end.
I’ll mark this ticket as resolved. Please, feel free to reopen this bug if you have any troubles.
Regards,
Jerónimo.
Description
•