Context loss for old WebGL contexts depends on how tab is opened
Reported by
eno...@onshape.com,
May 25 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3107.0 Safari/537.36 Steps to reproduce the problem: 1. Open attached "NewTabIssue.html" This is a webpage that creates 16 WebGL contexts. 2. Click on the "Open new tab" button. This will open the same file in a new browser tab 3. Go back to the first tab: notice that the WebGL context was lost for all 16 contexts in the first context 4. Click "Open new tab" again. 5. Note that this kills the context of the second tab that was opened. If you open new tabs manually and paste the file URI into the address bar, then you can create any number of tabs that have all 16 WebGL context active. What is the expected behavior? I expect that the behavior of context loss would be the same, whether the tab was opened by the user, or opened programmatically by another tab. Ideally, I would want the browser to allow each tab to have the maximum number of contexts. What went wrong? When the new tab is opened programmatically, the total number of allowed contexts is shared between all tabs in the "chain" of programmatically opened tabs. Did this work before? N/A Does this work in other browsers? No Safari exhibits the same behavior. Firefox always limits the context count to 16 across tabs that share the same url, regardless of how it is opened. Chrome version: 60.0.3107.0 Channel: canary OS Version: OS X 10.12.5 Flash Version:
,
May 31 2017
That's correct. While we could institute more complex per-origin heuristics, this one has been in place for a number of years and hasn't been reported as a problem until now. What's the scenario where this is causing issues?
,
Jun 6 2017
In our application a design can be made up of multiple elements. In our UI, the user can switch between the elements with tabs of our own making. However, through the context menu, the user can open individual design elements in their own _browser_ tab (see attached screenshot). This can make switching between elements a little more efficient for the user, and affords them whatever shortcuts they have for switching between browser tabs. I don't think fixing this issue is critical to us or our users, as the number of contexts the browser allows is fairly large. (16, right?) We have some work to do to be more conservative in our use of contexts; right now we make 2 per page, where I think we could create 1 for most use cases. I primarily wanted to check to see if this was an oversight that could be easily fixed on your end. Since it sounds like it is not, the correct resolution may be to mark this issue as one that won't be fixed.
,
Jun 6 2017
OK. Note that you can draw a WebGL-rendered canvas into for example a 2D canvas rendering context just via drawImage, so maybe your pop-up windows could use this instead of creating a full new WebGLRenderingContext. Sorry, but closing this as WontFix. |
|||
►
Sign in to add a comment |
|||
Comment 1 by sunn...@chromium.org
, May 26 2017Status: Untriaged (was: Unconfirmed)