If we don't have a client window (i.e. rendering to GL directly), and a WebPageCompositor is only set after a rendering operation (e.g. a loadData() call that doesn't need to wait for networking), then we'll try to render to BackingStorePrivate::buffer() which doesn't exist at this point. That's bad, and gets us various assertions and possibly worse. Fix it by starting in a screen-suspended state and only resuming screen and backingstore once a compositor is actually set.
Created attachment 153123 [details] Patch
Depends on the robustified suspend/resume behavior in bug 91644, therefore I didn't set a commit-queue request yet.
Comment on attachment 153123 [details] Patch Bug 91644 has been pushed, so this one's good to go if I get a positive review. Setting cq? flag in addition to the r?. Preferred reviewer is George Staikos as this patch is a reimplementation (slightly different, imho slightly better) of an original suggestion of his, but if others feel it's straightforward enough then I might take somebody else's review as well.
Comment on attachment 153123 [details] Patch I am not in love with this, but discussed with Jakob offline. Jakob, please update the commit message with the details you said on IRC (right timing of things, etc)
Created attachment 153344 [details] Patch as r+ed above, with more verbose commit message Antonio, please cq+ if the commit message is more what you were thinking of. Thanks :)
Comment on attachment 153344 [details] Patch as r+ed above, with more verbose commit message Clearing flags on attachment: 153344 Committed r123172: <http://trac.webkit.org/changeset/123172>
All reviewed patches have been landed. Closing bug.