Closed Bug 1369592 Opened 7 years ago Closed 7 years ago

After opening a new blank tab, ^z doesn't fill the address bar with the URL of the previous tab.

Categories

(Firefox :: Address Bar, defect)

55 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 - wontfix

People

(Reporter: fyrenmoo, Unassigned)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170601030206

Steps to reproduce:

1. Have a page loaded in the current tab
2. Hit ^t to open a new tab
3. Hit ^z


Actual results:

^z does nothing.


Expected results:

Before, hitting ^z would fill the address bar with the URL from the previous tab.

Using mozregression, someone else narrowed the change down to:

INFO: Last good revision: 92c5898618c21d80d8cccd49bc08ec5fc8924a45
INFO: First bad revision: 029d3143f52d17a218cd7dcb33ec3003fe5a8d9d
INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=92c5898618c21d80d8cccd49bc08ec5fc8924a45&tochange=029d3143f52d17a218cd7dcb33ec3003fe5a8d9d
INFO: Looks like the following bug has the  changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1358025

I don't actually know if the previous behavior was intended, but I did use it.
Component: Untriaged → Location Bar
Makoto, could you check why undo is disabled in this case.
Blocks: 1358025
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
Flags: needinfo?(m_kato)
Keywords: regression
(In reply to Loic from comment #1)
> Makoto, could you check why undo is disabled in this case.

As textbox, this is expected behavior (all browsers are same behavior).  Because setting to about:blank etc isn't user operation (it means that user doesn't input it).

If comment #0's step is expected as product design / spec, we can use setUserInput instead of input.value setter.  setUserInput  works on chrome and urlbar is on chrome.
Flags: needinfo?(m_kato)
(In reply to Makoto Kato [:m_kato] from comment #2)
> If comment #0's step is expected as product design / spec, we can use
> setUserInput instead of input.value setter.  setUserInput  works on chrome
> and urlbar is on chrome.

Who would make the call on that?
Flags: needinfo?(m_kato)
(In reply to Julien Cristau [:jcristau] from comment #3)
> Who would make the call on that?

Marco, who is owner of location bar spec?
Flags: needinfo?(m_kato) → needinfo?(mak77)
I think in general comment 2 is right, so this is a wontfix. Opening a new tab should clear the transaction history, since the location bar appears inside the tab, so the context is a different one.

That said, if there is some common use-case that may have be widespread and is now broken, we're open to evaluate those and issue specific fixed for them. But we need specific bugs for the use-case to be able to evaluate.

Regarding this specific case "open a new tab and ^Z to go the url of the previous tab", it sounds exotic and breaks the above assumption about separate contexts. Thus is imo a wontfix. you can ctrl+drag a tab to create a dupe of it. I agree it's not great from the keyboard, but ^C,^T,^V is still usable, we could eventually evaluate Ctrl+Enter doing the same when canonization (adding www.*.com) doesn't apply to the value.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mak77)
Resolution: --- → WONTFIX
looks like it's *fixed* by bug 1386222 and now history is shared.
You need to log in before you can comment on or make changes to this bug.