[Webkit-unassigned] [Bug 192224] [WPE] Add API to notify about frame displayed view backend callback

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 10 23:37:17 PST 2018


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

--- Comment #5 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Comment on attachment 356172
  --> https://bugs.webkit.org/attachment.cgi?id=356172
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=356172&action=review

>> Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:4147
>> + * Add a callback to be called when the backend notifies that a frame has been displayed in @web_view.
> 
> I don't think you need the detail about the backend:
> 
> "Add a callback to be called when the backend notifies that a frame has been displayed in @web_view."

I mentioned explicitly on purpose after realizing that fdo backend was not dispatching the frame displayed signal. So, I want to make it clear that this callback depends on the backend.

>> Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:4169
>> + * webkit_web_view_add_frame_displayed_callback().
> 
> Maybe we should document that the callback may be called once more after this function runs if the callbacks are currently being executed. Otherwise, applications that remove one callback during another callback and don't expect the original callback to be called again could crash. Admittedly, it would be pretty weird for an application to try this, so maybe not that important, but it seems unsafe and you do have a bunch of webView->priv->inFrameDisplayed logic trying to ensure safety here, after all.

Not really, that's actually bug, good catch :-) We should check callback is not in frameDisplayedCallbacksToRemove before emitting the signal. I'll try to make a test case.

>> Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitWebView.cpp:1240
>> +        }, this, nullptr))
> 
> Don't you think this is a bit much for a constructor initializer? I would do this in the body of the constructor. Up to you....

This is just a test...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181211/44af6299/attachment.html>


More information about the webkit-unassigned mailing list