[Presentation API] No devtools link for offscreen tab in chrome://inspect |
||
Issue descriptionForked from Bug 839617 +btolsch in case he has thoughts (worked on profiles for offscreen tabs recently) Chrome Version: 68.0.3421.0 (Developer Build) unknown (64-bit) OS: Linux What steps will reproduce the problem? (1) Navigate to https://googlechrome.github.io/samples/presentation-api/ (2) Start a presentation that creates an offscreen tab (e.g. to Chromecast) (3) Open chrome://inspect What is the expected result? Offscreen tab created for 1 is listed in chrome://inspect under "Other" What happens instead? No offscreen tab is listed there, or under other devtools pages that I could find Note: Did not check other Presentation API sites. The presentation continued to render and could be closed/reconnected/terminated, so I assumed that the tab/renderer was still alive.
,
May 7 2018
> Dmitry, is there a way to browse local devtools hosts for other profiles from chrome://inspect? Sure, open chrome://inspect in that profile. Does that work for you?
,
May 7 2018
The offscreen tab profile doesn't have a window to navigate to...
,
May 8 2018
The check could be modified to: auto* profile = Profile::FromBrowserContext(host->GetBrowserContext()); if (profile != profile_ && (!profile->IsOffTheRecord() || profile->GetOriginalProfile() != profile_)) I don't know if this makes sense for the UI since I don't have any context on whether DevTools would want to hide OTR tabs.
,
May 8 2018
The profile check we have covers a security issue, where we don't want to expose access to all the profiles from chrome://inspect. This all sounds like a deep architectural problem which I am not sure how to fix easily. The change proposed in #c4 is will expose incognito profiles in the original profile's chrome://inspect which leaks incognito data out and goes against the design of incognito. If you are willing to contribute a solution which can satisfy everyone, we are open to the patches. Unfortunately, we don't have cycles right now to address this.
,
May 9 2018
It sounds like devtools is not going to support a solution through chrome://inspect. I wonder if there is a real security problem here as normally one profile cannot block access to the windows/tabs of another through the UI. We will research other ways to expose devtools for presentation receiver pages and come back to this if we get stuck.
,
May 9 2018
> I wonder if there is a real security problem here https://bugs.chromium.org/p/chromium/issues/detail?id=817943 Everything that does not break ^^ would work. I'll mark it as available in case there are any takers... |
||
►
Sign in to add a comment |
||
Comment 1 by mfo...@chromium.org
, May 7 2018Owner: dgozman@chromium.org
Status: Assigned (was: Untriaged)
Added some logging to the devtools UI and it seems like the offscreen tab is failing the following check in devtools_targets_ui.cc: if (Profile::FromBrowserContext(host->GetBrowserContext()) != profile_) continue; Here's logging showing that the profiles are different (as expected). [142502:142502:0507/094524.221909:VERBOSE2:devtools_targets_ui.cc(152)] profile_ = 0x2b36fc5a2aa0 [142502:142502:0507/094524.222027:VERBOSE2:devtools_targets_ui.cc(154)] DevToolsAgentHost id = 04D8201E5667365652324E98AE83074F parentId = openerId = type = other title = Demo Receiver description = URL = https://googlechrome.github.io/samples/presentation-api/receiver/index.html profile = 0x2b3700493320 Looks like this check was added recently by dgozman@. Dmitry, is there a way to browse local devtools hosts for other profiles from chrome://inspect?