when resizing EWebLauncher, Contents wasn't rendered properly. I suspect _ewk_view_smart_contents_resize
Created attachment 63526 [details] error screen
Created attachment 63529 [details] Patch
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.
(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.
Comment on attachment 63529 [details] Patch OK. Is your name normally written in all lowercase as it is in the ChangeLog?
My review is more of a rubber-stamp.
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.
Comment on attachment 63529 [details] Patch I'll let you all fight it out.
(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.
(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.
Created attachment 64492 [details] Patch
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.
This is a better solution. But I think we still should investigate later if this is a bug on our fixed_layout_set function.
(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?
Created attachment 69177 [details] Patch
(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.
Comment on attachment 69177 [details] Patch I trust you on this one.
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
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.
Created attachment 77419 [details] merged patch Here's an attempt to merge the patch by editing the diff.
Comment on attachment 77419 [details] merged patch Clearing flags on attachment: 77419 Committed r74640: <http://trac.webkit.org/changeset/74640>
All reviewed patches have been landed. Closing bug.
http://trac.webkit.org/changeset/74640 might have broken GTK Linux 32-bit Release