Bug 131831

Created attachment 229601 [details] Patch

Comment on attachment 229601 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=229601&action=review > Source/WebKit2/UIProcess/API/efl/ewk_view.cpp:246 > + impl->pageViewportController().setHadUserInteraction(true); I don't think we have to set "true" whenever ewk_view_page_zoom_set() is called. Shouldn't we call it only one time ?

Comment on attachment 229601 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=229601&action=review >> Source/WebKit2/UIProcess/API/efl/ewk_view.cpp:246 >> + impl->pageViewportController().setHadUserInteraction(true); > > I don't think we have to set "true" whenever ewk_view_page_zoom_set() is called. Shouldn't we call it only one time ? we can check hadUserInteraction value and set true only if it is false. I will update patch.

Comment on attachment 229601 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=229601&action=review > Source/WebKit2/UIProcess/WebPageProxy.cpp:3055 > + // We have to find better solution. Eunmi, as you know, this looks one of workaround solutions. I'm also investigating how to solve this problem fundamentally. If you have spare time with your nice condition, please take a look fundamental problem.

Comment on attachment 229601 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=229601&action=review >> Source/WebKit2/UIProcess/WebPageProxy.cpp:3055 >> + // We have to find better solution. > > Eunmi, as you know, this looks one of workaround solutions. I'm also investigating how to solve this problem fundamentally. If you have spare time with your nice condition, please take a look fundamental problem. One more comment: I also think that page zoom on fixed layout should work same as "fixed layout is off".

Comment on attachment 229601 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=229601&action=review >>> Source/WebKit2/UIProcess/WebPageProxy.cpp:3055 >>> + // We have to find better solution. >> >> Eunmi, as you know, this looks one of workaround solutions. I'm also investigating how to solve this problem fundamentally. If you have spare time with your nice condition, please take a look fundamental problem. > > One more comment: I also think that page zoom on fixed layout should work same as "fixed layout is off". Second comment: RenderView::viewWidth() and RenderView::viewHeight() value have been affected by on/off of fixedlayout. When fixed layout is on, with/height look be multiplied by pageZoomFactor. If we don't apply effectiveZoom(), when the fixed layout is enabled without this patch, page zoom works as it is off. int RenderView::viewWidth() const { int width = 0; if (!shouldUsePrintingLayout()) { width = frameView().layoutWidth(); width = frameView().useFixedLayout() ? ceilf(style().effectiveZoom() * float(width)) : width; } ... } RenderView::viewWidth() http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderView.cpp#L1109

Created attachment 230568 [details] Patch

Comment on attachment 230568 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=230568&action=review > Source/WebKit2/UIProcess/WebPageProxy.cpp:3119 > + newSize.scale(1 / m_pageZoomFactor); As mentioned in comment #6, RenderView::viewWidth/Height() multiplies the pageZoomFactor(= effectiveZoom()) with width/height when fixed layout is enabled. So, I think we need to check if the calculation logic is correct from EFL port perspective. I think this patch looks a workaround patch. I'd like to clear r?,cq? until finishing the investigation.

Closing this bug because the EFL port has been removed from trunk. If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.