[office] Correct a blicking artefact happening on a link context menu after back button was pressed.

[dcaliste]

I found a corner case when opening a context menu make the contentY change quickly to an offset position before returning to normal.

To reproduce:

• open a context menu on an external link (like one on the top right corner of the first page of the attached PDF) ;
• tap on a goto link (like the one on the page number, right bottom corner of the first page) ;
• tap on the back arrow and reopen the first context menu again.

The root of this is very hidden. It's the _flickableContentY property of the ContextMenu that triggers this. Following the previous steps:

• after opening the context menu the first time, the ContextMenu exists in memory and is attached to the ContextMenuHook that is taking the place of the link on the first page.
• when tapping on the goto link, the ContextMenuHook is moved to take the place of the box of the goto link.
• when tapping on the back arrow, and since the menu is closing and the height of the flickable is changing, the property of _flickableContentY is updated to ensure that the ContextMenuHook rectangle can be visible if contentY of the flickable is change accordingly.
• then, tapping on the link again, does not update _flickableContentY, because there is no reason (_flickableConentYAtOpen is the same), and when _open becomes true, the contentY is set to _flickableContentY which contains a not up-to-date value, thus the blinking.

Beside updating ContextMenu to ensure that _flickableConentYAtOpen is set to -1 or any non significant value, when hide() is called, I think it's safer to detach any menu from the ContextMenuHook when the hook is set to a different target. This is the purpose of this PR. examplePDF.pdf

[pvuorela]

Current version: click on top link to open menu, rotate the device -> menu remains open

This version: menu disappears and this gets output:

[W] unknown:66 - file:///usr/lib/qt5/qml/Sailfish/Office/ContextMenuHook.qml:66: TypeError: Cannot read property '_flickable' of null

[dcaliste]

That's right, I forgot that changing orientation changes the clickedBox in PDFView, so resetting the target…

I've moved the _menu._flickable = null into the on_OpenedChanged callback and removed the _menu = null to avoid cycle in setting _opened. The setTarget() function is not necessary anymore, but I suggest to keep it anyway, because it gives more sense IMHO when reading the code than setting two properties.

Seeing all this, I'm wondering if this possible to setup automatic tests for UI program and QML ? Having something like load PDF, emulate tap at (x,y) check that menu is opened… That would be great, especially, I'm currently fighting with the title proposition of the design team, adding a header component to PDFView.qml (see my title branch, it's almost working). It has created a mess because we rely a lot on contentY being linearly modified by page rotation, while now with header, contentY is not modified linearly anymore, but modified linearly plus a constant.

[pvuorela]

Looks good and works now better

Seeing all this, I'm wondering if this possible to setup automatic tests for UI program and QML

There's Qt Quick Test & qmltestrunner. Could be of help: https://publications.theseus.fi/bitstream/handle/10024/98894/Johansson_Lauri.pdf?sequence=1

[dcaliste]

There's Qt Quick Test & qmltestrunner.

Very interesting, thank you, I'll try to prepare something for the PDF UI in the coming weeks.