[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] appropriate context loss response



As more JS/Canvas/WebGL is being embedded on third party pages around the mobile web (because no flash), it becomes quite a bit of a problem if iOS safari throws a hissing fit everytime an iFrame or WebGL context on a page exceeds its (unknown and unknowable) resource limit and therefore borks the whole page. But this is the WebGL specification ML, we can't mandate that browsers behave nicely for everything, we could mandate they don't throw hissing fits if WebGL is being used in fashion that exceeds invisible resource limit border.

On Wed, Nov 11, 2015 at 6:55 PM, Dean Jackson <dino@apple.com> wrote:

On 11 Nov 2015, at 9:51 AM, Florian Bösch <pyalot@gmail.com> wrote:

On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson <dino@apple.com> wrote:
I do think it should (must?) be "acceptable" to kill the process/page completely if necessary. 
Obviously detecting that the context is broken and firing a context lost event is the preferred option, but I don't think we can require all implementations to always recover gracefully.

The issue is that if you kill the whole page, a reload will just kill it again in an endless loop (or however many auto-reloads iOS safari does by itself). It's night impossible to use iOS safari if it does that (closing the tab manually becomes quite challenging etc.). It also leaves the JS on the page with no clue that it did something bad (munch too much vram or whatever) and so no avenue to rectify/address the "bad" behavior. On the whole it's just really, really bad, is why I think it'd make a fairly good requirement for a specification. 

Safari should only reload the page twice and then give up. It's definitely a bug if it reloads constantly.

Dean