Bug 98280 – [EFL][WK2] Implement window frame callbacks in UIClient

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit EFL

[Chris Dumez]

We need to implement the following callbacks in EwkView's UIClients:
  getWindowFrame()
  setWindowFrame()

[Chris Dumez]

Created attachment 166917 [details]
Patch

[Chris Dumez]

Created attachment 166920 [details]
Patch

Use ecore_evas_move_resize() to avoid 2 separate calls.

[Chris Dumez]

Created attachment 166932 [details]
Patch

Use Evas object API to match corresponding WKTR implementation.

[Ryuan Choi]

Comment on attachment 166932 [details]
Patch

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

> Source/WebKit2/ChangeLog:10
> +        Implement getWindowFrame and setWindowFrame callbacks
> +        in EwkView's UIClient so that the window frame
> +        geometry can be queried / set.

Can we have test case for this?

> Source/WebKit2/UIProcess/API/efl/ewk_view_ui_client.cpp:111
> +    evas_object_move(view, frame.origin.x, frame.origin.y);
> +    evas_object_resize(view, frame.size.width, frame.size.height);

I am not sure whether we should move evas object or ecore_evas.

Can I know when this is called?

[Chris Dumez]

Comment on attachment 166932 [details]
Patch

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

>> Source/WebKit2/ChangeLog:10
>> +        geometry can be queried / set.
> 
> Can we have test case for this?

Hmm. I'm not adding any new API here. I guess it should be possible to test this though, I'll take a look.

>> Source/WebKit2/UIProcess/API/efl/ewk_view_ui_client.cpp:111
>> +    evas_object_resize(view, frame.size.width, frame.size.height);
> 
> I am not sure whether we should move evas object or ecore_evas.
> 
> Can I know when this is called?

We need evas_object. There is corresponding code in WebKitTestRunner (PlatformWebView::windowFrame). I tried both (evas_object and ecore_evas) in WKTR, with ecore_evas, the corresponding LayoutTests are failing. However, with evas_object, they are passing.

[Chris Dumez]

Comment on attachment 166932 [details]
Patch

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

>>> Source/WebKit2/UIProcess/API/efl/ewk_view_ui_client.cpp:111
>>> +    evas_object_resize(view, frame.size.width, frame.size.height);
>> 
>> I am not sure whether we should move evas object or ecore_evas.
>> 
>> Can I know when this is called?
> 
> We need evas_object. There is corresponding code in WebKitTestRunner (PlatformWebView::windowFrame). I tried both (evas_object and ecore_evas) in WKTR, with ecore_evas, the corresponding LayoutTests are failing. However, with evas_object, they are passing.

Actually, you're right that it needs be ecore_evas, I have tested. I will update the patch.

[Chris Dumez]

Created attachment 167150 [details]
Patch

- Use Ecore_Evas API
- Add unit test

[WebKit Review Bot]

Comment on attachment 167150 [details]
Patch

Rejecting attachment 167150 [details] from commit-queue.

Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 1

Last 500 characters of output:
Kit/chromium/third_party/yasm/source/patched-yasm --revision 154708 --non-interactive --force --accept theirs-conflict --ignore-externals' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'
51>At revision 154708.

________ running '/usr/bin/python tools/clang/scripts/update.py --mac-only' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'

________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'
Updating webkit projects from gyp files...

Full output: http://queues.webkit.org/results/14173341

[Chris Dumez]

Created attachment 167251 [details]
Patch for landing

Rebased on master. Could someone please cq+ ?

[WebKit Review Bot]

Comment on attachment 167251 [details]
Patch for landing

Clearing flags on attachment: 167251

Committed r130464: <http://trac.webkit.org/changeset/130464>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.