Closed Bug 1334844 Opened 8 years ago Closed 8 years ago

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

Categories

(Firefox :: Address Bar, defect, P2)

51 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 54
Tracking Status
firefox51 - wontfix
firefox52 + wontfix
firefox-esr52 --- fixed
firefox53 + verified
firefox54 + verified

People

(Reporter: gpuleo, Assigned: mak)

References

Details

(Keywords: regression, Whiteboard: [fxsearch])

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).
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.
Have you run http://kb.mozillazine.org/Standard_diagnostic_-_Firefox ? I had a similiar bug caused by an add-on --> Bug 1248120
Component: Untriaged → Location Bar
Flags: needinfo?(gpuleo)
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.
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.
(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
Blocks: 1336844
No longer blocks: 1336844
Depends on: 1337682
did you use ctrl+enter to visit the first page, by chance?
I did, yes. Also happens after Shift+Enter and Ctrl+Shift+Enter for net and org.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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]
Do we have clear STRs?
[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
Flags: needinfo?(gpuleo)
Keywords: regression
OS: Unspecified → All
Hardware: Unspecified → All
Sounds like a reproducible regression from bug 1306639, tracking for 52/53/54.
Too late for 52 now. Marco, have you had a chance to look at this?
(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).
Target Milestone: --- → Firefox 54
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Assignee: nobody → mak77
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
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.