chrome.processes.getProcessIdForTab incorrectly assumes a *single* renderer process per tab |
|||||||||
Issue descriptionchrome.processes.getProcessIdForTab incorrectly assumes a *single* renderer process per tab. This is kind of similar to issue 666525 (we are trying to remove the WebContents::GetRenderProcessHost method).
,
Sep 21 2017
nasko@ - can you please help with triage? I am not sure 1) if this is important and 2) what we can do here (changing externally-facing API is more difficult than just changing //contents public API).
,
Sep 21 2017
FWIW, the processes API is listed as experimental and restricted, so we can make breaking changes (though it'd be nice to somewhat limit them).
,
Sep 22 2017
Assigning to nasko for triage.
,
Sep 28 2017
,
Sep 28 2017
More generally, there are several aspects of the old chrome.processes API that pre-date out-of-process iframes (OOPIFs) and need to be updated before the API is launched. Nasko and I would be happy to consult but don't have time to spend on it in the short term.
,
Sep 28 2017
I'm removing myself as the owner, since I don't plan on working on this anytime soon. Anyone is welcome to take this over so changing to "Available".
,
Oct 1
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. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 1
If we want to ship chrome.processes to stable, this needs to be fixed first.
,
Oct 1
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by lukasza@chromium.org
, Sep 21 2017