Able to reproduce this issue on latest beta 62.0.3202.45 and on latest canary 63.0.3233.0 with steps mentioned in comment#0. Issue is not seen on linux and windows.

NOTE: Issue is working fine in latest stable 61.0.3163.100

Manual Bisect Info:
================
Good Build: 62.0.3181.0
Bad Build: 62.0.3182.0

Per-revision bisect invokes all good builds even after increasing bad range. Hence providing manual changelog.

CR: https://chromium.googlesource.com/chromium/src/+log/62.0.3181.0..62.0.3182.0?pretty=fuller&n=10000 

Unable to find suspect from above changelog. Could some one from UI>Browser>Navigation team could look into this issue.

Adding RB-Stable as this is recent regression. Please change if not the case.

Thanks!

avi@ has poked at browser shortcuts lately, so assigning to him for initial triage.

+dtapuska, the input expert.

I wrote a sample page at http://avidrissman.github.io/htmltests/reload.html , and have been playing with it. I disagree with OP's statement of which browsers behave this way.

Chrome 63 on Mac: Allows page to capture command-R
Firefox 56 on Mac: Allows page to capture command-R
Safari 11 on Mac: Does not allow page to capture command-R
Edge 40.15063.0.0 on Windows: Allows page to capture control-R after a click in the page.

I'll do another bisect with this test page but I don't see a clear-cut divide here in browsers. It would be nice to establish expected behavior in a standards committee.

Chrome 63 on Windows: Allows page to capture control-R

Please keep in mind that the webpage in ma initial report don't capture Cmd + R, but only R.

I've updated your example accordingly: https://www.harrycow.fr/r.html

With my test page I bisected to see when this change happened.

You are probably looking for a change made after 384085 (known good), but no later than 384096 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/fe1e90eeacdc473325519df9c556d1cffa5db3a0..d88171b10e74122f7ac1410370dd056314ffc25f

I can't find the exact change, but this behavior dates back to roughly M51.

Given that this is behavior that changed in M51, this is not RBS.

"Please keep in mind that the webpage in ma initial report don't capture Cmd + R, but only R."

That doesn't change anything, though. If the web page doesn't bother checking for "command" or "control" but just "R", sees the "command-R" key event and eats it, that's no different than my repro.

I just re-tested with your testcase on Firefox on my Mac and Edge on Windows, and my results are no different. They too allow pages to see the command/control-R key event and preventDefault it.

I re-bisected.

This bisects to a02ef8b2b472ef649f8881dfb52f97676c9bc3b4 because that's when KeyboardEvent.key got turned on.

It's quite possible that the command-R event was preventDefault-able before that.

I made a modification to the page (attached) where I look at the keyCode value rather than the key value.

I tried to bisect it but failed. This behavior goes back at least to r96380, and I can't bisect further because versions of Chromium older than that crash when I click in them on macOS 10.11.

As far as I can tell, this has always worked this way. From the research in comment 4 it's clear that browsers aren't agreeing here.

Until we have consensus here, I'm going to leave this.

Deleted: reload.html 469 bytes

reload.html 469 bytes View Download

This is the relevant code causing the reload...
            KeyboardJS.on("ctrl", function() {
                KeyboardJS.clear("r")
            });
            KeyboardJS.on("r", function() {
                window.InpactToolkit.GlobalScript.GoToRandomActu()
            })

Note that if you ever press ctrl on the page then the reload is disabled; they aren't doing this for the meta key (which command appears as).