When using the Minibrowser in default touch mode and scroll down a long page using the mouse wheel, you will at some point reach an unpainted part of the screen. Panning the screen using touch-mock will trigger the repaint. The issue seems to be that wheel-scroll does not send new expose events to the web-process. This has been a regression since painting became better optimized.
Created attachment 124550 [details] Patch
Comment on attachment 124550 [details] Patch wouldnt it be better to call the viewportTrajectoryVectorChanged ?
I think this is the same issue as https://bugs.webkit.org/show_bug.cgi?id=77338.
(In reply to comment #2) > (From update of attachment 124550 [details]) > wouldnt it be better to call the viewportTrajectoryVectorChanged ? TrajectoryVectorChanged only tells which direction we are going to move in, not what we have actually moved. The normal animated process is: On animate start: TrajectoryVectorChanged On animate end: VisibleContentRectAndScaleChanged (called from _q_resume) This is just a non animated version doing the same as animate end. It could be achieved by calling suspend and resume in a quick succession, but that seems silly.
(In reply to comment #3) Having a second look, it is a separate issue, and we need a call to updateVisibleContentRectAndScale on wheel scrolling as well. Sorry for the noise.
Comment on attachment 124550 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review > Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 > +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() Would it be better to make updateVisibleContentRectAndScale a slot?
(In reply to comment #6) > (From update of attachment 124550 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review > > > Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 > > +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() > > Would it be better to make updateVisibleContentRectAndScale a slot? Well it is in QQuickWebViewPrivate, and all the other slots there have the _q_something form.
Comment on attachment 124550 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review >>> Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 >>> +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() >> >> Would it be better to make updateVisibleContentRectAndScale a slot? > > Well it is in QQuickWebViewPrivate, and all the other slots there have the _q_something form. and? what is wrong with renaming it?
(In reply to comment #8) > (From update of attachment 124550 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review > > >>> Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 > >>> +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() > >> > >> Would it be better to make updateVisibleContentRectAndScale a slot? > > > > Well it is in QQuickWebViewPrivate, and all the other slots there have the _q_something form. > > and? what is wrong with renaming it? Well nothing, but it is called from a other functions, and it seemed like a poor name for a function. I don't know the motivation behind the slot naming scheme, I was just trying to follow it, and it seemed most slots where thin wrappers.
Comment on attachment 124550 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review >>>>> Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 >>>>> +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() >>>> >>>> Would it be better to make updateVisibleContentRectAndScale a slot? >>> >>> Well it is in QQuickWebViewPrivate, and all the other slots there have the _q_something form. >> >> and? what is wrong with renaming it? > > Well nothing, but it is called from a other functions, and it seemed like a poor name for a function. I don't know the motivation behind the slot naming scheme, I was just trying to follow it, and it seemed most slots where thin wrappers. The reason for the _q_ in the name is that those slots are technically visible from the outside - Q_PRIVATE_SLOT only affects how a slot is implemented, not its visibility to the outside. Therefore we introduced the naming convention in Qt to say slots that start with _q_ are "internal" in the ABI/API sense and do not come with any compatibility guarantee.
Created attachment 124719 [details] Patch
Attachment 124719 [details] did not pass style-queue: Failed to run "['Tools/Scripts/update-webkit']" exit_code: 9 Updating OpenSource First, rewinding head to replay your work on top of it... Applying: Fix compilation errors on build-webkit --debug --no-workers on mac. Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging LayoutTests/ChangeLog CONFLICT (content): Merge conflict in LayoutTests/ChangeLog Auto-merging LayoutTests/platform/qt/Skipped CONFLICT (content): Merge conflict in LayoutTests/platform/qt/Skipped Auto-merging Source/WebCore/ChangeLog CONFLICT (content): Merge conflict in Source/WebCore/ChangeLog Failed to merge in the changes. Patch failed at 0001 Fix compilation errors on build-webkit --debug --no-workers on mac. When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". rebase refs/remotes/origin/master: command returned error: 1 Died at Tools/Scripts/update-webkit line 164. If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 124719 [details] Patch Clearing flags on attachment: 124719 Committed r106362: <http://trac.webkit.org/changeset/106362>
All reviewed patches have been landed. Closing bug.