Web view can scroll under long tap overlay
dcaliste opened this issue · 4 comments
When long tapping on a link, an overlay is displayed to show various options. If one keep his finger on screen and move it up and down after the overlay is shown, the webview is scrolled accordingly under the overlay and the toolbar can also appear when moving up.
Thanks for reporting long time known issue.
Ah ok, just noticed it some days ago and didn't see any previous report on TJC or here, so not so visible !
By the way, yesterday, I forked the code and the webview component one. Which one is actually used at the moment ? I would like to put an eye on it. I've seen that the WebView controls the context menu opening through JS, but it's not clear what controls the display of the HTML page and its flickability. I guess WebContainer and WebPage are defined from C++ ?
Will fix this along with text selection.
Yeap, WebContainer (WebView) and WebPage are implemented in C++. There is no flickable at all on WebContainer. Web content is rendered to a background window (QWindow/WebView) with opengl and browser chrome that is the foreground window is implement with QML (QQuickView). There are some decision points that judges which kind of input regions we have at times e.i. imagine that toolbar is visible then foreground window (chromeWindow) has input region that starts from top-left corner of the toolbar. This in turn affects which is the window handling the touch event happens on point x,y. Or e.g. when context menu is open all events are handled by chrome window.
There two ways to pass messages to gecko. First is that we can send json messages to gecko and/or embedlite-components and those are handled by respected component if listener is registered for a given topic. Secondly some operations are implemented through QtMozEmbed such as load, goBack, goForward, loading state, and things like that. QtMozEmbed uses Gecko's embedding API that we have in mer/gecko-dev.
Now we're introducing sailfish-components-webview and sailfish-browser that uses it can be found from "next" branch. But it's not enough to build just sailfish-components-webview rather you need to build also latest embedlite-components, qtmozembed, and gecko-dev. With this ContextMenu handling will move to sailfish-components-webview.
That's a short background info + status.
That being said if you like to up-to-speed, you can start by using "master" branch of sailfish-browser that doesn't need sailfish-components-webview. You can tweak BrowserContextMenu look and feel there as that has not change on sailfish-components-webview. Once we get new browser packages out, you can port changes to sailfish-components-webview 's ContextMenu. On "master" branch of sailfish-browser context menu handling is over here: https://github.com/sailfishos/sailfish-browser/blob/master/src/pages/components/WebPopupHandler.js. WebView.qml handles messages and upon "Content:ContextMenu" topic message handler calls PopupHandler.openContextMenu. Json data passed to openContextMenu contains data of the context menu for instance xPos and yPos (sent from [1] if you're interested).
How does this sounds like? Don't hesitate to ask more info, if you need. You can reach me from freenode's #sailfishos channel (rainemak).
Thank you for the detailed answer. It's clearer now for me about the separation between chrome and web content. I'll try to give a look in the coming days.