Address bar uses most recently entered URL, not URL in bar, after using CTRL+ENTER

VERIFIED FIXED in Firefox -esr52

Status

()

Firefox
Address Bar
P2
normal
VERIFIED FIXED
11 months ago
9 months ago

People

(Reporter: gpuleo, Assigned: mak)

Tracking

({regression})

51 Branch
Firefox 54
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox51- wontfix, firefox52+ wontfix, firefox-esr52 fixed, firefox53+ verified, firefox54+ verified)

Details

(Whiteboard: [fxsearch])

(Reporter)

Description

11 months ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Step 1: Open a tab. Navigate to any webpage, e.g., cnn.com
Step 2: Open another tab. Navigate to a different webpage, e.g., facebook.com
Step 3: Return to first tab. Hit "enter" in address bar.


Actual results:

Firefox loads the URL that was entered in the second tab (in this example, Facebook), rather than the URL in the address bar of the first tab.


Expected results:

Firefox should load the URL already listed in the address bar of the first tab (in the example, CNN).
(Reporter)

Comment 1

11 months ago
On reviewing the report-writing guidelines I realize my use of the word "navigate" is imprecise. By "navigate", I mean: type the given URL into the address bar and press Enter.

Comment 2

11 months ago
Have you run http://kb.mozillazine.org/Standard_diagnostic_-_Firefox ? I had a similiar bug caused by an add-on --> Bug 1248120
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)

Comment 6

11 months ago
gpuleo, is it reproducible:

1) in safe mode:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

2) with a fresh profile:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Component: Untriaged → Location Bar
Flags: needinfo?(gpuleo)
(Reporter)

Comment 7

11 months ago
I can reliably reproduce the bug in safe mode. I was initially able to reproduce the bug on a fresh profile (outside of safe mode), but unable to reproduce it after trying safe mode on a fresh profile, and after switching back to non-safe mode, could not reproduce the bug reliably on the fresh profile.

Comment 8

10 months ago
I'm having same bug and can also reproduce in Safe Mode.
(In reply to gpuleo from comment #0)
> Step 1: Open a tab. Navigate to any webpage, e.g., cnn.com
> Step 2: Open another tab. Navigate to a different webpage, e.g., facebook.com
> Step 3: Return to first tab. Hit "enter" in address bar.

it's missing a step here, how did you select the address bar? Just moving to a different tab doesn't focus it.
(Reporter)

Comment 10

10 months ago
(In reply to Marco Bonardo [::mak] from comment #9)
> (In reply to gpuleo from comment #0)
> > Step 1: Open a tab. Navigate to any webpage, e.g., cnn.com
> > Step 2: Open another tab. Navigate to a different webpage, e.g., facebook.com
> > Step 3: Return to first tab. Hit "enter" in address bar.
> 
> it's missing a step here, how did you select the address bar? Just moving to
> a different tab doesn't focus it.

I have observed this bug both when clicking in the address bar to select it, and when using Ctrl-L to select the address bar.
It would be nice to have a way to reproduce this easily, as it is sounds like something really intermittent, and I've never hit it.
Keywords: steps-wanted

Updated

10 months ago
Blocks: 1336844
Duplicate of this bug: 1336844
Keywords: qawanted, regressionwindow-wanted

Updated

10 months ago
No longer blocks: 1336844
Depends on: 1337682
did you use ctrl+enter to visit the first page, by chance?

Comment 14

10 months ago
I did, yes. Also happens after Shift+Enter and Ctrl+Shift+Enter for net and org.
Duplicate of this bug: 1336844
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted, regressionwindow-wanted, steps-wanted
Priority: -- → P2
Summary: Address bar uses most recently entered URL, not URL in bar → Address bar uses most recently entered URL, not URL in bar, after using CTRL+ENTER
Whiteboard: [fxsearch]

Comment 16

10 months ago
Do we have clear STRs?

Comment 17

10 months ago
str
[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

STR:
1) Type "example" in the location bar and press Ctrl+Enter
NB: Firefox loads http://www.example.com/
2) Click on the link "More information..."
NB: Firefox loads http://www.iana.org/domains/reserved
3) Select the location bar and press Enter.

Result: Firefox reloads http://www.example.com/ instead of http://www.iana.org/domains/reserved

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f03e2740d604d339ed553dad62a3fc54c317f8fa&tochange=0c899672fff6ae00f5b3affbec48ee4daac35fa1
Blocks: 1306639
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox54: --- → affected
tracking-firefox51: --- → ?
tracking-firefox52: --- → ?
tracking-firefox53: --- → ?
tracking-firefox54: --- → ?
Flags: needinfo?(gpuleo)
Keywords: regression
OS: Unspecified → All
Hardware: Unspecified → All
Sounds like a reproducible regression from bug 1306639, tracking for 52/53/54.
status-firefox51: affected → wontfix
tracking-firefox51: ? → -
tracking-firefox52: ? → +
tracking-firefox53: ? → +
tracking-firefox54: ? → +
Too late for 52 now.  Marco, have you had a chance to look at this?
status-firefox52: affected → wontfix
(In reply to Julien Cristau [:jcristau] from comment #19)
> Too late for 52 now.  Marco, have you had a chance to look at this?

the dependent bug has a patch waiting for review (and it fixes this one as well).
Fixed by bug 1337682
status-firefox54: affected → fixed
Target Milestone: --- → Firefox 54
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → FIXED
Assignee: nobody → mak77
status-firefox53: affected → fixed
status-firefox-esr52: --- → affected
Flags: qe-verify+
I’ve reproduced the issue described in comment 0 by following the steps in comment 17 using an affected build: Firefox 54.0a1(Build Id:20170125030214).

I have verified that the issue is not reproducible using Firefox 53.0b1(Build Id:20170307064827) and Firefox 54.0a2 (Build Id:20170309004016) using Windows 10 64bit and Ubuntu 16.04 16bit.
Status: RESOLVED → VERIFIED
status-firefox53: fixed → verified
status-firefox54: fixed → verified
Flags: qe-verify+
status-firefox-esr52: affected → fixed
You need to log in before you can comment on or make changes to this bug.