Regression: Unnecessary browser navigated to 'about:blank' page after clicking on 'Reload' button.
Reported by
db...@etouch.net,
Jan 16 2018
|
||||
Issue descriptionChrome Version: 65.0.3322.4 Revision b41bd45daf7be30b05ec90cd2367e4c072aef174-refs/branch-heads/3322@{#7}(32/64 bit) OS: Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.12.6,10.13.1,10.13.3) Test URL: chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://www.tutorialspoint.com/html/html_tutorial.pdf What steps will reproduce the problem? (1) Launch chrome, navigate to above URL and click on Reload button. (2) Observe. Actual: Unnecessary browser navigated to 'about:blank' page after clicking on Reload button. Expected: Browser should not navigated to about:blank page after clicking on Reload button. This is a regression issue. broken in 'M62', below is manual bisect info: Good Build:62.0.3190.0(495758) Bad Build: 62.0.3191.0(495816) You are probably looking for a change made after 495778 (known good), but no later than 495779(first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/a9c2e448a2a2f48d9d2b0ec28185ffa4ea263eb3..f1afce25b3f94d8bddec69b08ffbc29b989ad844 Suspect : https://chromium.googlesource.com/chromium/src/+/f1afce25b3f94d8bddec69b08ffbc29b989ad844 @rdevlin.cronin: 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. Note: Above issue is seen on M63 Stable(#63.0.3239.132), M64 Beta(#64.0.3282.85) and M65 Dev(#65.0.3315.3)
,
Jan 18 2018
"PDF Viewer" extension issues are not the same as Chrome PDF Viewer.
,
Jan 23 2018
Mac triage: ping - rdevlin.cronin, can you take a peek at this?
,
Jan 24 2018
Interesting. In both cases, the extension isn't installed. But in the initial navigation (via the omnibox), we show the ERR_BLOCKED_BY_CLIENT page, whereas when we click reload, we get about:blank. Nasko, Alex: I'm assuming this is because clicking reload here triggers a renderer-initiated navigation, and for renderer navigations, we direct to about:blank rather than the error page. A few questions: - Should clicking reload on a semi-native surface like the error page be a renderer-initiated navigation? - Should we be showing the error page (rather than about:blank) for both renderer-initiated and browser-initiated requests?
,
Jan 24 2018
The likely reason we show about:blank is that the navigation is not allowed by FilterURL, which has the behavior of rewriting the URL to about:blank. FilterURL runs much earlier than any navigation throttles that could potentially block it. Changing how FilterURL behaves to cause navigation to an error page will be non-trivial, so I'd call it a project, not a bugfix. Error pages are implemented in HTML and JS, so any actions coming from those are basically renderer initiated. We can't treat them differently at this time, as the error page commits in a regular renderer process. I do have design and started CL to change error pages to commit in their own process, so maybe once that is done, we could do things differently.
,
Jan 24 2018
@5 Thanks for the info! So, anything we can/should do here in the interim? I'm not terribly worried about it, given that visiting a nonexistent extension page *should* be relatively rare, but it is still a little odd.
,
Feb 2 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by nyerramilli@chromium.org
, Jan 16 2018