Visibility into service worker control over localhost |
||||
Issue descriptionService workers (https://developers.google.com/web/fundamentals/getting-started/primers/service-workers) bring with them some fundamental changes to the assumptions that most developers have about development on localhost (or the equivalent IP addresses). For instance, a service worker that uses a cache-first strategy inside of its fetch handler might end up responding to HTTP requests with stale content long after the corresponding local web server has been stopped. I'm going to file some other feature requests with suggestions for working around specific scenarios, but a general suggestion that I wanted to track here was increased visibility somewhere in the Chrome UI when there's a service worker controlling the current navigation and the origin is localhost. This might entail an automatic "butter bar", or some badging in the URL bar, or badging in the tab. It should ideally be persistent. It also might include a message in the JS console log, but (I think) it's important that we show something that is visible to developers even if they don't have DevTools open. This suggestion doesn't apply to non-localhost navigations, with the assumption that anything non-localhost should be treated as a "production" deployment.
,
Jun 20 2017
I'm picking UI>Browser>Bubbles, which seems to be the component that encompasses those URL bar indicators.
,
Jun 21 2017
Do common local subnets (e.g. 10.x.x.x, 192.168.x.x, 100.x.x.x) count as localhost-equivalent IPs? It's pretty common to have Chrome for Android listening to a server on an adjacent computer, and not everyone knows about (or takes the time to set up) port forwarding. Alternatively, perhaps chrome:inspect could check if the mobile tab's host is one of the IPs the computer is bound to; and if so, treat it like localhost & show whatever warning this issue ends up recommending.
,
Jun 21 2017
Common local subnets like 192.168.x.x are not whitelisted to allow service workers over http: There's more background about what's allowed at https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
,
Jun 21 2017
Ahh - good point. So, unless dev servers support HTTPS, it's a moot point anyway.
,
Jul 13 2017
,
Aug 21
Archiving old bugs that haven't been actively assigned in over a year. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks! |
||||
►
Sign in to add a comment |
||||
Comment 1 by chenwilliam@chromium.org
, Jun 17 2017