meta refresh navigation to data url fails correctly, but keep on repeating without any interval.
Reported by
k...@deletethetrees.com,
Sep 15 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce the problem: 1. Click the link in the attached HTML file. 2. This will create a redirect loop that on high performance machines is too fast to interrupt. 3. On slower machines (e.g. ChromeOS) it is stoppable by furiously clicking to another tab which will then remove resources from the tab suffering the redirect loop and you can then close it. What is the expected behavior? Chrome should detect a redirect loop or prompt to stop scripts. What went wrong? All of Chrome locks up and due to high CPU usage even Windows becomes unusable except for the task manager. Crashed report ID: How much crashed? Whole browser Is it a problem with a plugin? N/A Did this work before? N/A Chrome version: 52.0.2743.116 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0
,
Nov 22 2016
A very simple solution would be have a minimum delay for ScheduledRedirects to the same URL in NavigationScheduler. Something like 50ms or even 25ms would not be very noticeable to the user but would allow abusive sites to be closed and it wouldn't lock the browser. This would avoid having to do anything complicated like exponential backoff or threading state through navigations. Note that this wouldn't solve the problem for true redirect loops, but I imagine they are harder to code up with data urls, so we wouldn't be cpu bound. +kinuko for thoughts (also japhet fyi)
,
Dec 20 2016
Adding kinuko as owner so it is triaged and won't get dropped; leaving status as available.
,
Feb 21 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 22 2018
Now the top frame navigation to the data url is forbidden. It should show "Not allowed to navigate top frame to data URL" errors in the inspector console. The original issue seems to be fixed now, but there is another issue on navigating in a subframe. Repro steps: 1. Open parent.html of below. 2. clink Test link parent.html <iframe src="refresh.html"></iframe> refresh.html <a href="data:text/html;charset=utf-8,<html></html>">Test</a> With this step, Chrome can keep sane, but one thread will get to be busy. DevTools shows repeating reload of data url. According to the spec I roughly checked, may overlook something, https://dev.w3.org/html5/spec-preview/the-meta-element.html The URL in the refresh content should be 'Resolve'-d. And the 'Resolve' algorithm explicitly disallow the data URL at the step 10. https://dev.w3.org/html5/spec-preview/urls.html#resolve-a-url So failing refresh navigation to the data URL sounds fine here, but repeating it should not be expected. FYI, FireFox shows similar behavior.
,
Aug 31
There is something fishy with entity handling in the original report; with <meta http-equiv='refresh' content='0;url='https://google.com''> I think the infinite redirect comes from ' terminating content='0;url=' and that's why the redirect is to data:... (from resolving the empty URL relative to data:...) @toyoshim is comment 5 is meant to include <meta http-equiv='refresh' content='0'> in the data: content? Here's an updated spec link: https://html.spec.whatwg.org/#attr-meta-http-equiv-refresh It seems WHATWG's URL spec doesn't have any special treatment for data: URLs. Is this bug still relevant? The browser doesn't lock up, and an rapid data: refresh is no different to a rapid http refresh or anything else of this kind. Tentatively WontFixing this but feel free to reopen it if I'm missing something. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dtapu...@chromium.org
, Sep 15 2016Components: UI>Browser>Navigation Blink>Loader