Able to reproduce the issue on Windows 10, Ubuntu 14.04, Mac OS 10.12.2 using reported version #55.0.2883.87 and latest canary #57.0.2962.0.

Bisect Information:
=====================
Good build: 55.0.2853.0	Revision(416812)

Bad Build : 55.0.2855.0	Revision(417475)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/58744ea650361b518c411667574be67749d65c48..2a56f872fc3e82ccd819db4378ae2e1ac206c116

From the above change log suspecting below change

Review URL: https://codereview.chromium.org/2257743002

toyoshim@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

This issue is still observed on Windows-10 and Ubuntu 14.04 using chrome latest canary #57.0.2986.0. 

toyoshim@ Can we get any latest update on this issue?

This is an intentional behavior change.
From the change pointed at comment #1, Chrome changes its behavior to handle obnibox+enter for the URL page as a reload. We are currently working on simplifying reload variations.

> This is an intentional behavior change.

That's pretty obvious, but you have to realize that it's plain wrong, completely idiotic, and MUST be reverted.

Here's an example that makes it evident how unquestionably wrong the behavior is:

You copy an url with a deeplink and paste it into the address bar of an existing tab that had been left open and forgotten. It just happens that on that same tab you had been browsing the same url and had scrolled. So, now the observed behavior is that instead of opening the expected page at the expected fragment, it goes to a seemingly random point.

And then there is also the obvious use case: you go to an url with a deep link, then scroll up and down, and then want to easily go back to the point where you started.


It's as simple as this: typing or pasting an URL and hitting Enter must have always the same effect, regardless of whether it's on a fresh new tab, an existing tab with a different current url, or an existing tab with the same url currently opened. It's a completely OBVIOUS expected behavior, and any other behavior is nonsense.

I wouldn't be surprised if this even violates some specs

Reload and navigating to the same page is an area that currently w3c spec does not cover well, and actually I asked this change in the w3c thread beforehand. Spec was revised to be clearer, but it still allows us to have user-agent specific behaviors / optimizations.

We carefully launched this feature behind a server managed flag so that we can revert this change without binary update whenever it is needed.

We had some reports like this. But numbers of negative feedbacks do not meet a bar to revert this change.

> so that we can revert this change without binary update whenever it is needed.

Cool, what about now.

> We had some reports like this. 
> But numbers of negative feedbacks do not meet a bar to revert this change.

Indeed, you shouldn't even need negative feedback to see the obvious. It's astonishing that this was done in the first place.

I'd love to hear one single argument in favour of this ridiculous behavior (I have mentioned two obvious arguments against it which should be enough to prove how wrong it is).

Note that it is SO obvious the behavior is wrong, that bug triagers in comments 2 and 3 didn't even consider it could be by design. That should tell you something.

@toyoshim I've recently learned about this change and find it really confusing. Can you provide us with the use case in which this is relevant? To me, it looks like we no longer can copy an URL from Wikipedia and paste it in the omnibar to check if it is referring to the correct before sharing it.

I read in your comment: 'We are currently working on simplifying reload variations.' which seems to indicate that you categorize this action as a reload, while to me, I would call it 'navigate'.

reg #9, it should just work.

If you paste the completely same URL to an existing tab, it works as a reload. But if the URL is different from the one of current page, or you are using new tab, it works as a new navigation. It should scroll to the position that the anchor points.

> But if the URL is different from the one of current page, or you are using new 
> tab, it works as a new navigation. It should scroll to the position that the 
> anchor points.

Yeah right. The problem is that when you copy an url and paste it into some random tab previously left open, you don't first check to make sure that the url that was open in that tab doesn't happen to be the very same one you are pasting. And it can happen (happens pretty often to me)

 Issue 715456  has been merged into this issue.

Guys, enough time has passed for you to admit that this was an idiotic mistake.

You have to reopen and fix this before it's too late and people get used to the wrong behavior to the point it becomes perceived as expected.

Plenty of evidence has been given in the comments that the new behavior is fundamentally wrong AND inconvenient, and not a single argument has been given in its favour (because there isn't).

For fuck's sake!

Every time I open a deep link and then scroll around, when I want to go back to the point the fragment links to, I have to open a new tab, copy and paste the url, and close the old tab. It's fucking RIDICULOUS!

Ok, enough time has passed, you must have realized how idiotic this was.

Reopen and fix it.

Note that many usecases have been provided where the old behavior was useful and the new behavior is annoying (disregarding that it should be obvious that it's simply wrong).

On the other hand, NOBODY has provided a SINGLE usecase where the new behavior shows any advantage.

Can't you just admit you made an embarassing mistake and undo it?
Unfortunately it has been so long that users will have even become accustomed to the wrong behavior and they may be slightly annoyed for a moment when it is changed back, but the current behavior is so evidently wrong that this shouldn't be a problem.

> reg #9, it should just work.
>
> If you paste 

You didn't understand anything about comment #9.