It's easy to reproduce with MiniBrowser code. On BrowserWindow.qml, do the following: WebView { id: webView + property bool scrolledUpToBoundary: webView.experimental.contentY < 0 + onScrolledUpToBoundaryChanged: console.log('Scrolled up?' + scrolledUpToBoundary) It is expected that we can lookup to contentY changes and properly bind the properties here. The comparison webView.experimental.contentY < 0 is causing the seg fault. If instead of this you only work inside experimental.onContentYChanged and print the new value, it works. So you can just force updates to "scrollUpToBoundary" this way inside experimental, but I believe we should be able to do the other way around. Here's an example of the workaround: + property bool scrolledUpToBoundary: false + experimental { + onContentYChanged: webView.scrolledUpToBoundary = webView.experimental.contentY < 0 + }
This bug might be invalid after https://bugs.webkit.org/show_bug.cgi?id=83033. (In reply to comment #0) > It's easy to reproduce with MiniBrowser code. On BrowserWindow.qml, do the following: > > WebView { > id: webView > + property bool scrolledUpToBoundary: webView.experimental.contentY < 0 > + onScrolledUpToBoundaryChanged: console.log('Scrolled up?' + scrolledUpToBoundary) > > It is expected that we can lookup to contentY changes and properly bind the properties here. The comparison webView.experimental.contentY < 0 is causing the seg fault. If instead of this you only work inside experimental.onContentYChanged and print the new value, it works. So you can just force updates to "scrollUpToBoundary" this way inside experimental, but I believe we should be able to do the other way around. Here's an example of the workaround: > > + property bool scrolledUpToBoundary: false > + experimental { > + onContentYChanged: webView.scrolledUpToBoundary = webView.experimental.contentY < 0 > + }
(In reply to comment #1) > This bug might be invalid after https://bugs.webkit.org/show_bug.cgi?id=83033. > Oh yea, hope so. I will mark this one depending on that then. Thanks! :)
Since the WebView is a direct subclass of Flickable, this bug is no longer valid.