Disable meta refresh when scripting is disabled

[beaufortfrancois]

Users have been asking for a way to disable <meta http-equiv="refresh"> from the browser since 2010. See https://bugs.chromium.org/p/chromium/issues/detail?id=63107

I believe disabling meta refresh when JavaScript browser setting is disabled in browsers would help with accessibility tools being confused by continual reloads.

What do you think?

• At least two implementers are interested (and none opposed):
  • Chrome
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=63107
  • Firefox: …
  • Safari: …

---

/semantics.html ( diff )

[annevk]

Can you restore the PR template? It seems that if we were to do this it would have to be tested, in particular for sandboxed environments. And as such also require implementation bugs and interest.

[beaufortfrancois]

Can you restore the PR template? It seems that if we were to do this it would have to be tested, in particular for sandboxed environments. And as such also require implementation bugs and interest.

Done. Sorry. I used https://github.dev/whatwg/html to create this change and the template was not proposed.

[domenic]

concept-environment-noscript applies to environment settings objects, not to documents.

Additionally, document is not declared anywhere.

Suggested wording:

If scripting is disabled for the the meta element's relevant settings object, then return.

[beaufortfrancois]

Done. Thank you!

[beaufortfrancois]

@domenic What are the next steps?

[domenic]

The next steps are to gather multi-implementer interest and write web platform tests, per the PR template.

[annevk]

FWIW, I worry that this behavior is problematic as this is often used as fallback for a scripted redirect solution. It seems better for browsers to provide a way to intercept these to give the user time to react.

Firefox has accessibility.blockautorefresh for this, though I don't think it's currently exposed through UI.

[beaufortfrancois]

FWIW, I worry that this behavior is problematic as this is often used as fallback for a scripted redirect solution. It seems better for browsers to provide a way to intercept these to give the user time to react.

Can you expand on this?

Firefox has accessibility.blockautorefresh for this, though I don't think it's currently exposed through UI.

For future reference, here's the 21y bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=83265

[annevk]

@beaufortfrancois in that users with scripting disabled would end up with a broken experience, rather than getting redirected or getting a refresh every so often as they do now.

[beaufortfrancois]

@beaufortfrancois in that users with scripting disabled would end up with a broken experience, rather than getting redirected or getting a refresh every so often as they do now.

Thanks!
I've recently added some use-counters in Chromium to track how much we would break actually. See https://chromium-review.googlesource.com/c/chromium/src/+/3231179
It should pop up in https://chromestatus.com/metrics/feature/popularity#HttpRefreshWhenScriptingDisabled soon

[annevk]

I'm not sure how that helps. We know refresh is being used and we know it's used for redirects. We also know some percentage of users disable scripting, either directly or through an extension. Ergo, they end up with a broken experience.

(And also, people using assistive technology don't necessarily disable scripting by the way; I'd expect that most don't (otherwise ARIA wouldn't work).)

[beaufortfrancois]

I'm not sure how that helps. We know refresh is being used and we know it's used for redirects. We also know some percentage of users disable scripting, either directly or through an extension. Ergo, they end up with a broken experience.

If numbers are low enough of course, I still believe it would be worth pursuing: having a quick and easy way to disable meta refresh per website would make some users happy.

[annevk]

Yes, but there's no reason to tie it to whether script runs.

[beaufortfrancois]

Yes, but there's no reason to tie it to whether script runs.

It seems to me this option is the most user friendly one as it doesn't clutter settings with yet another "specific" option.
Do you see another way for users to disable it without going too technical (.e.g about:config, about:flags, etc.) ?

[JC-LGMS]

FWIW, I worry that this behavior is problematic as this is often used as fallback for a scripted redirect solution. It seems better for browsers to provide a way to intercept these to give the user time to react.

Firefox has accessibility.blockautorefresh for this, though I don't think it's currently exposed through UI.

the problem with this option in Firefox, it is that redirect of all websites is blocked, without per site choice. This behavior ends with a broken experience.

[zcorpan]

This doesn't cover the Refresh HTTP header.

https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigating-across-documents:refresh

[beaufortfrancois]

FYI https://chromestatus.com/metrics/feature/timeline/popularity/4063 shows that 0.002750% of page loads in Google Chrome use HTTP Refresh when scripting is disabled.

[annevk]

As stated in #7203 (comment) I don't think that statistic is useful here.

[domenic]

An alternate approach here is to just not standardize this. The user agent is already allowed to do nothing, at its own preference, in step 13. If some browsers (such as Chrome) believe tying this to the disable-scripting UI is best, then they can do that. Whereas if other browsers (such as Firefox) believe tying this to a dedicated UI control, or not allowing user control at all, is best, then they can do that. We don't need a spec PR, if there isn't implementer agreement on tying scripting to meta refresh, and we just want to use the generic "do nothing" clause.