[Webkit-unassigned] [Bug 164180] [GTK] No way to safely use webkit_web_view_get_snapshot() as pages are not rendered when LOAD_FINISHED is called

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=164180

--- Comment #4 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > I don't think we should change the semantics of LOAD_FINISHED, we should
> > > probably expose APILoaderClient::didReachLayoutMilestone, and the
> > > applications could wait for DidFirstVisuallyNonEmptyLayout or
> > > DidHitRelevantRepaintedObjectsAreaThreshold, I don't know the details of the
> > > milestones.
> > 
> > Why you think we should not change when LOAD_FINISHED triggers?
> > What is the use case of having a LOAD_FINISHED signal that doesn't trigger
> > always when the page is fully rendered??
> 
> Because load finished is not about rendering but about networking, the page
> finished loading, but not necessarily rendering. That's why there are other
> callbacks more related to rendering like the ones I mentioned before.

I think that this is an internal implementation detail that don't necessarily has to be exposed in our API

Quoting our docs:

" WEBKIT_LOAD_FINISHED This state means that everything that was required to display the page has been loaded. "

https://webkitgtk.org/reference/webkitgtk/stable/WebKitWebFrame.html#WebKitLoadStatus

And after reading that twice, I would expect that when LOAD_FINISHED triggers the page is always fully rendered.

Adding a new state is an option, but I think is a bad idea to do it, if we only add it for the sake of exposing the internal implementation.

So, what is the use case for an application to have both WEBKIT_LOAD_FINISHED and WEBKIT_LOAD_FINISHED_AND_RENDERED_COMPLETED ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170203/5bfafee1/attachment.html>