[Webkit-unassigned] [Bug 70873] [EFL] Invalidation request outside of visible area doesn't seem to occur when tiled view is used.

[bugzilla-daemon at webkit.org]

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





--- Comment #23 from KwangHyuk <hyuki.kim at samsung.com>  2011-11-17 17:20:36 PST ---
(In reply to comment #22)
> OK, I think I got what the patch is supposed to fix. ewk_frame_paint_full_set is only called once when the frame is created by ewk_view's smart add, however FrameLoaderClient::transitionToCommittedForNewPage can be called more than once with the same frame, but since each time it is called a new view is created.
> 
> This should be as easy as calling ewk_frame_paint_full_set with the boolean parameter depending on some ewk_frame or ewk_view (or even FrameLoaderClientEfl, I haven't thought of it a lot) that is persistent across the many FrameViews created. There are many ways to solve this, among them having subclasses of ewk_view setting some flag for this. My point is that it can be done in a better way, OOP-wise.
> 
> But even more important than this is a reduced test case. It is impossible to properly debug this kind of thing with a full-fledged, huge site such as naver or daum. We just need a small html page which triggers the same behavior so we can always make sure this never regresses.

(In reply to comment #22)
> OK, I think I got what the patch is supposed to fix. ewk_frame_paint_full_set is only called once when the frame is created by ewk_view's smart add, however FrameLoaderClient::transitionToCommittedForNewPage can be called more than once with the same frame, but since each time it is called a new view is created.
> 
> This should be as easy as calling ewk_frame_paint_full_set with the boolean parameter depending on some ewk_frame or ewk_view (or even FrameLoaderClientEfl, I haven't thought of it a lot) that is persistent across the many FrameViews created. There are many ways to solve this, among them having subclasses of ewk_view setting some flag for this. My point is that it can be done in a better way, OOP-wise.
> 
> But even more important than this is a reduced test case. It is impossible to properly debug this kind of thing with a full-fledged, huge site such as naver or daum. We just need a small html page which triggers the same behavior so we can always make sure this never regresses.

Ok, I see, let me generate some simple test site sooner or later. :)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.