Bug 43528 – [EFL] Screen doesn't be rendered when changing size of EWebLauncher

• Component: WebKit EFL
• Status: RESOLVED FIXED

[Ryuan Choi]

when resizing EWebLauncher, Contents wasn't rendered properly.

I suspect _ewk_view_smart_contents_resize

[Ryuan Choi]

Created attachment 63526 [details]
error screen

[Ryuan Choi]

Created attachment 63529 [details]
Patch

[Rafael Antognolli]

Well, I don't think you should set the size of the view to the value passed to _ewk_view_smart_contents_resize, since they have different meanings.

Can you explain what is the bug you have when resizing? It seems to work fine here.

[Ryuan Choi]

(In reply to comment #3)
> Well, I don't think you should set the size of the view to the value passed to _ewk_view_smart_contents_resize, since they have different meanings.
> 
> Can you explain what is the bug you have when resizing? It seems to work fine here.

I think that you can see attached image when you visit http://www.naver.com
When we resizing at EWebLauncher, EWK looks not render additional area like attached image.

[Eric Seidel (no email)]

Comment on attachment 63529 [details]
Patch

OK.  Is your name normally written in all lowercase as it is in the ChangeLog?

[Eric Seidel (no email)]

My review is more of a rubber-stamp.

[Rafael Antognolli]

I still strongly disagree with this. From my point of view, you shouldn't set the View size to the Contents size. They are for different purposes, and have different meanings.

[Eric Seidel (no email)]

Comment on attachment 63529 [details]
Patch

I'll let you all fight it out.

[Ryuan Choi]

(In reply to comment #8)
> (From update of attachment 63529 [details])
> I'll let you all fight it out.

(In reply to comment #7)
> I still strongly disagree with this. From my point of view, you shouldn't set the View size to the Contents size. They are for different purposes, and have different meanings.

I simply referenced in gtk version.
but, I found that this issue occur at not EWK-demo, but EWeblauncher.
I think that we need to discuss.

[Ryuan Choi]

(In reply to comment #9)
> (In reply to comment #8)
> > (From update of attachment 63529 [details] [details])
> > I'll let you all fight it out.
> 
> (In reply to comment #7)
> > I still strongly disagree with this. From my point of view, you shouldn't set the View size to the Contents size. They are for different purposes, and have different meanings.
> 
> I simply referenced in gtk version.
> but, I found that this issue occur at not EWK-demo, but EWeblauncher.
> I think that we need to discuss.

I realized I create stupid solution.
After checking more, I'll make real solution.

[Ryuan Choi]

Created attachment 64492 [details]
Patch

[Ryuan Choi]

I found real problem.
It's not WebKit/EFL bug but EWeblauncher's.

_ewk_view_smart_calculate after calling on_resize can't invalidate contents when resizing EWeblauncher.
so, I removed on_resize.
I believe that we don't need to call ewk_view_fixed_layout_size_set when resizing.

[Rafael Antognolli]

This is a better solution. But I think we still should investigate later if this is a bug on our fixed_layout_set function.

[Ryuan Choi]

(In reply to comment #13)
> This is a better solution. But I think we still should investigate later if this is a bug on our fixed_layout_set function.

I believe that fixed_layout_set is not related with this bug.
but I agree we need to know whether fixed_layout_set itself also is a bug.

I can explain what I investigate.
problem is that on_resize called it with new (w,h) before calling _ewk_view_smart_calculate
It makes confusion in FrameView::layout because FrameView::m_size was already changd by fixed_layout_set.
so m_doFullRepaint can't become true although we called resize in _ewk_view_smart_calculate

Should fixed_layout_set change m_size?

[Ryuan Choi]

Created attachment 69177 [details]
Patch

[Ryuan Choi]

(In reply to comment #15)
> Created an attachment (id=69177) [details]
> Patch

I update patch because location of EWeblauncher was moved from WebKit/efl/ to WebKitTools/
And also update Changelog to clarify why I removed on_resize.

[Kenneth Rohde Christiansen]

Comment on attachment 69177 [details]
Patch

I trust you on this one.

[WebKit Commit Bot]

Comment on attachment 69177 [details]
Patch

Rejecting attachment 69177 [details] from commit-queue.

Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=cr-jail-3', 'apply-attachment', '--no-update', '--non-interactive', 69177]" exit_code: 2
Last 500 characters of output:
 leading up to this was:
--------------------------
|Index: WebKitTools/EWebLauncher/main.c
|===================================================================
|--- WebKitTools/EWebLauncher/main.c	(revision 68637)
|+++ WebKitTools/EWebLauncher/main.c	(working copy)
--------------------------
No file to patch.  Skipping patch.
2 out of 2 hunks ignored

Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', u'--reviewer', u'Kenneth Rohde Christiansen', u'--force']" exit_code: 1

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

[Eric Seidel (no email)]

WebKitTools recently moved to Tools.  abarth mentioned the possibility of creating a patch to svn-apply to automatically fix patches when applying.  But until such a change exists, we'll need to fix this patch to apply to Tools instead of WebKitTools.

[Adam Barth]

Created attachment 77419 [details]
merged patch

Here's an attempt to merge the patch by editing the diff.

[WebKit Commit Bot]

Comment on attachment 77419 [details]
merged patch

Clearing flags on attachment: 77419

Committed r74640: <http://trac.webkit.org/changeset/74640>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[WebKit Review Bot]

http://trac.webkit.org/changeset/74640 might have broken GTK Linux 32-bit Release