Closed Bug 1452722 Opened 7 years ago Closed 6 years ago

Provide way to set offline mode on a per-tab basis

Categories

(Core :: Networking, enhancement, P2)

Product:
Core
Component:
Networking
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1156659

People

(Reporter: jduell.mcbugs, Unassigned)

Details

(Whiteboard: [necko-triaged])

Immediate use case is DevTools. Current plan is to set a flag in the loadGroup somewhere (apparently we do something like that for appcache already), and at AsyncOpen time we can query to see if the channel should be treated as offline. Existing channels that are open to a remote host won't be affected by a switch to offline mode for the tab--only new channels.
How do you think this feature should work in these cases? 1. A SharedWorker attached to two different tabs. One tab is set offline. 2. A ServiceWorker thread intercepting FetchEvents for two different tabs. One tab is set offline. Could we perhaps create a separate offline principal origin attributes value? That would partition things like SharedWorker, ServiceWorker, etc. It would require reloading the tab when offline is set, though. Also consider how to propagate any offline state to something like dedicated workers (and sub-workers). Its not clear to me setting a value on docshell loadgroup is adequate.
Ben: those are great questions and I don't have a clue how to answer them :) Maybe you and :mayhemer can figure it out?
Flags: needinfo?(honzab.moz)
Jan may have thoughts and relevant requirements here too.
Flags: needinfo?(odvarko)
(In reply to Ben Kelly [:bkelly] from comment #1) > How do you think this feature should work in these cases? > > 1. A SharedWorker attached to two different tabs. One tab is set offline. > 2. A ServiceWorker thread intercepting FetchEvents for two different tabs. > One tab is set offline. > > Could we perhaps create a separate offline principal origin attributes > value? That would partition things like SharedWorker, ServiceWorker, etc. > It would require reloading the tab when offline is set, though. > > Also consider how to propagate any offline state to something like dedicated > workers (and sub-workers). Its not clear to me setting a value on docshell > loadgroup is adequate. Good points. I believe even more issues will emerge with this 'per-tab offline' feature. If we have this as a separation flag on origin attributes (which IMO don't belong there at all!) switching to offline would mean to reload the page with also a separation for HTTP cache (among other stuff being separated too, such as HTTP auth, cookies...), which would be at the moment empty for that context, which would lead to not being able to display the page at all - no cache, no net, no love. And having an exception for the "offline" flag on OA just for cache (auth, cookies,...) is IMO a nonsense. Also let you know that OAs are currently subject to specification, so it's not that simple to modify them this ad-hoc way. I think Honza Odvarko first has to clearly establish the requirements and primary motivation here, so that we can decide if this is even a valid thing, and if, how exactly to proceed.
Flags: needinfo?(honzab.moz)
(In reply to Honza Bambas (:mayhemer) from comment #4) > If we have this as a separation flag on origin attributes (which IMO don't > belong there at all!) switching to offline would mean to reload the page > with also a separation for HTTP cache (among other stuff being separated > too, such as HTTP auth, cookies...), which would be at the moment empty for > that context, which would lead to not being able to display the page at all > - no cache, no net, no love. And having an exception for the "offline" flag > on OA just for cache (auth, cookies,...) is IMO a nonsense. > > Also let you know that OAs are currently subject to specification, so it's > not that simple to modify them this ad-hoc way. What do you mean by this? Things like container id and private browsing bit are on our OriginAttributes structure today. I don't think those are specified standard at all. Anyway, I was just trying to say we could make this feature kind of like private browsing. Maybe even making it an "offline window" like PB would be a better user metaphor.
(In reply to Ben Kelly [:bkelly] from comment #5) > (In reply to Honza Bambas (:mayhemer) from comment #4) > > If we have this as a separation flag on origin attributes (which IMO don't > > belong there at all!) switching to offline would mean to reload the page > > with also a separation for HTTP cache (among other stuff being separated > > too, such as HTTP auth, cookies...), which would be at the moment empty for > > that context, which would lead to not being able to display the page at all > > - no cache, no net, no love. And having an exception for the "offline" flag > > on OA just for cache (auth, cookies,...) is IMO a nonsense. > > > > Also let you know that OAs are currently subject to specification, so it's > > not that simple to modify them this ad-hoc way. > > What do you mean by this? Ah, sorry, I might misplaced a published paper only with a specification draft. Anyway, OAs purpose is to do security isolation, not functional isolation. > > Anyway, I was just trying to say we could make this feature kind of like > private browsing. Maybe even making it an "offline window" like PB would be > a better user metaphor. Aha! That makes sense, yes. I didn't think this way. Depends on Honza's feature specification then, if that is acceptable. Anyway, the cache isolation issue is still there - no net, no cache, no love :) (ok - no content)
Ok, here's another idea: Don't add any new flags in OriginAttributes, but you can only toggle an entire container online/offline at a time. So if you open a container tab you could toggle that one tab without impacting other tabs in different containers. We could make a special "network development" container with nice UX for this purpose.
(In reply to Ben Kelly [:bkelly] from comment #7) > Ok, here's another idea: > > Don't add any new flags in OriginAttributes, but you can only toggle an > entire container online/offline at a time. So if you open a container tab > you could toggle that one tab without impacting other tabs in different > containers. We could make a special "network development" container with > nice UX for this purpose. Makes sense. So instead of having a per-tab offline we would have per-container offline. It's probably more easily doable.
The primary goal is providing a tool for web developers that can be used to switch network on/off for a given tab. This should help test web pages in offline mode. Like e.g. see that Service workers work fine when being offline. Chrome already has the feature. The UI is simple, there is an "Offline" checkbox in the Network panel forcing the current page/tab to disconnect from the network if on. It should work like the wire would be suddenly cut off. So, e.g. all HTTP requests in progress should stop downloading data from the server. There are some related bugs: 1) Bug 786419 - Provide way to "set network offline" per app This was done for Firefox OS, sounds similar but for Apps It's been removed in: Bug 1307491 - Remove IOService.SetAppOffline 2) Bug 1156659 - Provide way to "set network offline" per tab/docshell This was reported by Alex (DevTools team) while back (asking for platform API) and I think that it might be marked as duplicate of this report. 3) Bug 1029203 - Emulate being offline This is bug requesting UI in DevTools toolbox - I can fix it as soon as there are platform APIs (In reply to Ben Kelly [:bkelly] from comment #7) > Don't add any new flags in OriginAttributes, but you can only toggle an > entire container online/offline at a time. So if you open a container tab > you could toggle that one tab without impacting other tabs in different > containers. We could make a special "network development" container with > nice UX for this purpose. This sounds interesting, what exactly do you mean by: "network development" container with nice UX? Honza
Flags: needinfo?(odvarko)
Jan, what about my questions in comment 1. There are ways to get to the network that do not map 1:1 with tabs. What does chrome do for SharedWorker? I can tell you for ServiceWorker chrome just ignores the issue and lets service workers controlling a page in a tab that is "offline" hit the network anyway: https://bugs.chromium.org/p/chromium/issues/detail?id=593320 https://bugs.chromium.org/p/chromium/issues/detail?id=648208 Rather than copy a feature that is confusing giving the underlying architecture, I'd like us figure out in advance how we want to handle these real issues. If we're going to make this page only and ignore service workers like chrome, then we should also be planning a way for devtools to control offline state for the service worker.
Flags: needinfo?(odvarko)
(In reply to Ben Kelly [:bkelly] from comment #10) > Rather than copy a feature that is confusing giving the underlying > architecture, I'd like us figure out in advance how we want to handle these > real issues. Definitely agree. > If we're going to make this page only and ignore service > workers like chrome, then we should also be planning a way for devtools to > control offline state for the service worker. Yes, I think that the user should be able to control: 1) Online/offline state of a page 2) Online/offline state of a service worker Both independently using appropriate DevTools UI However, this is currently under discussion. Harald, what do you think? Honza
Flags: needinfo?(odvarko) → needinfo?(hkirschner)
SharedWorker probably also needs similar treatment to ServiceWorker with a separate control. FWIW, my idea for a "network development" container would be something like: - Offer an "open new network playground window" or "devtools playground window" - Window has controls that allow throttling/offline for all content in the window - The window gets its own container - We could also wipe the container after the window is closed. This matches how people want to use private browsing to get a "fresh" view of their window, but stuff like IDB and service workers don't work in PB. I think something like that would be more reflective of how the platform really works. Trying to do stuff on a per-tab basis doesn't really match the underlying platform. (Another mismatch is window.open creating a separate tab with different net settings but still able to communicate with the first tab, etc.)
(In reply to Ben Kelly [:bkelly] from comment #12) > SharedWorker probably also needs similar treatment to ServiceWorker with a > separate control. > > FWIW, my idea for a "network development" container would be something like: > > - Offer an "open new network playground window" or "devtools playground Ah, I see now what you meant in comment #7. Yes this sounds good to me and it could be also easy to understand to developers familiar with PB UX. It would probably require some browser window UI changes (like different color/icon) to differentiate from standard browser window, but all doable. Honza
> 1) Online/offline state of a page > 2) Online/offline state of a service worker 1) is important for now. Not sure where 2) fits as it can be tested by using 1). > I think something like that would be more reflective of how the platform really works. Trying to do stuff on a per-tab basis doesn't really match the underlying platform. (Another mismatch is window.open creating a separate tab with different net settings but still able to communicate with the first tab, etc.) If we showed that "Offline" applies to several tabs; would that solve the underlying problem? Fission would eventually address the window opener problem, right?
Flags: needinfo?(hkirschner)
(In reply to :Harald Kirschner :digitarald from comment #14) > If we showed that "Offline" applies to several tabs; would that solve the > underlying problem? Fission would eventually address the window opener > problem, right? I don't think fission will help here. For example, same-origin tabs will still be in the same process. The issue is that its not really possibly to trace every network request made by the web platform back to a unique tab. So trying to build a feature that controls network at a tab level is going to continually run into things that don't quite work as you expect. If you don't like the "devtools playground" window thing I suggested in comment 12, here is another idea: Allow users to mark *origins* as offline or network throttled. This simulates their server being down. It is also something we could clearly map to the network requests the web platform initiates.
I agree with Ben here. Trying to do this "per-tab" will surely run into problems around things that don't map 1:1 with tabs. How do we handle workers, other tabs opened by the current one, cross origin iframes? There are a bunch of issues here that need to be clarified. I think offline per-container would be a lot better. Offline per-origin would also be a good option.
The typical use case would be testing your way through an app and at some point want to test network flakiness … which would lose a lot of state when being moved to a new window. How far could we ease the disrupting experience of having to open a new "developer" window? Would it need to be a window or could it live as a special tab inside the same window? Otherwise, per-origin would be the least disruptive experience with side effects that we can communicate via UI. What are the main trade-offs for this option?
Priority: -- → P2
Whiteboard: [necko-triaged]
(In reply to Valentin Gosu [:valentin] from comment #16) > Offline per-origin would also be a good option. I personally like this option the most. Honza
Don't docshell flags work ? There's a docShell flag for overriding the user agent in network requests belonging to a certain tab, which hooks into AsyncOpen to set the override. DevTools then change that flag to set an UA override. Can't something like this be done here ?
(In reply to Tim Nguyen :ntim (busy until May 25th) from comment #19) > Don't docshell flags work ? There's a docShell flag for overriding the user > agent in network requests belonging to a certain tab, which hooks into > AsyncOpen to set the override. DevTools then change that flag to set an UA > override. > > Can't something like this be done here ? No, and that user-agent override will also not work as expected if the site uses SharedWorker or ServiceWorker. For example, see this exact problem reported in chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=709838
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.