Combobox suggestion popup filtering UI test waitForVaadin newer finishes

[maTrojak]

• Vaadin Framework version: 8.17.0
• Browser version: Version Chrome 103.0.5060.53 (64-Bit)
• Web container name and version: Spting Boot 2.7.4

Description of the bug:

When we use a combobox with new values allowed. We type a value in and it shows the popup and filters the suggestions accordingly. We use vaitforwaadin with a standard implementation for vaadin 8. Means we check if all vaadin.clients.isActive are false. In this case the window.vaadin.clients.ROOT.isActive() stays true indefinitely. Debugging the issue we found out the boolean waitingForFilteringResponse in VCombobox newer becomes false. Means the combobox thinks the suggestion filtering is not finished, but it is.

Expected behavior: isActive on the combobox is false eventually Actual behavior: isActive stays true indefinitely

Calls made in the UI test combobox.clear(); combobox.sendKeys(text); combobox.openPrevPage(); combobox.selectSuggestion(text); // custom method, find suggestion in popup and click it, contains autoScrollIntoView the actual clicking and waitForVaadin

Problematic location in VComboox probably is in DataReceivedHandler.dataReceived (line 1538). The waitingForFilteringResponse is set to true and afterwards it is newer set to false, because no additional server call/filtering actually happens. I am not super knowledgeable about the code here, though.

[Ansku]

I haven't found a way to reproduce this, but I did find a bug in setScrollToSelectedItem which causes it to stop working properly after the ComboBox is filtered (it keeps the page number from the filtered selection, not full selection) -- is that the same issue? And if not, could you provide a simple test code that would reproduce the problem?

[maTrojak]

This bug you are speaking of is it fixed? could you send me a link for me to check it out? The one the most resembled your description was fixed in 8.9 and we are on vaadin 8.17.

[Ansku]

I only made the pull request to the setScrollToSelectedItem issue yesterday evening so it didn't have time to make it to this morning's 8.18.0 release, but it should be already in the newest snapshot. Unfortunately our snapshot build configurations seem to have gone a bit awry and it looks like it's been building it into a 8.16-SNAPSHOT, will have to get that one sorted out...

[maTrojak]

How do I get some of the releases with the fix? Could i get a link to the pull request? i could probably try the modification locally.

[Ansku]

You can access the snapshot builds by adding these to your pom.xml:

        <repository>
            <id>Vaadin prereleases</id>
            <url>https://maven.vaadin.com/vaadin-snapshots</url>
        </repository>

within your <repositories> tag, and

    <pluginRepositories>
        <pluginRepository>
            <id>Vaadin prereleases</id>
            <url>https://maven.vaadin.com/vaadin-snapshots</url>
        </pluginRepository>
    </pluginRepositories>

on its own (assuming you don't have that <pluginRepositories> tag yet, if you do, just append the contents).

8.19-SNAPSHOT should do the trick

I'm afraid I can't link to the pull request since they are in a private fork now that Vaadin 8 is out of free support.

[maTrojak]

The repostory https://maven.vaadin.com/vaadin-snapshots or 8.19-SNAPSHOT (probabably 8.19,0-SNAPSHOT?) are not there when accessing with maven build. I cannot list the contents of none of your repositories to check it seems.

[Ansku]

Did you try it in your pom.xml? There is no directory listing available for that repo, and my laptop broke so I can't test it myself right now, but the snapshot should be there. And it should be 8.19-SNAPSHOT exactly, no zero.

[nPraml]

Hi @Ansku ,

we tried to use the 8.19-SNAPSHOT in our project (in pom.xml the repositoryand pluginRepositoryas you suggested. The maven build does not find the vaadin-client-9.19-SNAPSHOT.pom and the jar.:

Downloading from vaadin-addons: https://maven.vaadin.com/vaadin-addons/com/vaadin/vaadin-client/8.19-SNAPSHOT/maven-metadata.xml Downloading from vaadin-addons: https://maven.vaadin.com/vaadin-addons/com/vaadin/vaadin-client/8.19-SNAPSHOT/vaadin-client-8.19-SNAPSHOT.pom Downloading from Vaadin prereleases: https://maven.vaadin.com/vaadin-snapshots/com/vaadin/vaadin-client/8.19-SNAPSHOT/vaadin-client-8.19-SNAPSHOT.pom [WARNING] The POM for com.vaadin:vaadin-client:jar:8.19-SNAPSHOT is missing, no dependency information available

If we open the URL https://maven.vaadin.com/vaadin-addons/com/vaadin/vaadin-client/8.19-SNAPSHOT/vaadin-client-8.19-SNAPSHOT.pom or https://maven.vaadin.com/vaadin-snapshots/com/vaadin/vaadin-client/8.19-SNAPSHOT/vaadin-client-8.19-SNAPSHOT.jar we get an error (I assume it should work and we should get a dialog to type our Vaadin Username & Passwort) :

<Error>
<Code>NoSuchKey</Code>
<Message>The specified key does not exist.</Message>
<Key>vaadin-snapshots/com/vaadin/vaadin-client/8.19-SNAPSHOT/vaadin-client-8.19-SNAPSHOT.pom</Key>
<RequestId>1X4T7NVMKYFWASHR</RequestId>
<HostId>Re+vAIZHMLSO/K8di9KS7+US7vMHUDtMh3xDULNthQc8A5j/hPBcHOB1Z38KJPbacKflk59ALKE=</HostId>
</Error>

[thevaadinman]

No idea what's wrong - it could be the firewalling/routing on your end, it could be international routing, it could just be your pom.xml having some wrong definitions.

In case it helps, here's the definitions I just used on a fresh test application with my Maven cache deleted, and it compiled and ran just fine, using 8.19-SNAPSHOT artifacts:

<properties>
    <vaadin.version>8.19-SNAPSHOT</vaadin.version>
    <vaadin.plugin.version>8.15.0</vaadin.plugin.version>
    <jetty.plugin.version>9.3.9.v20160517</jetty.plugin.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
    <!-- If there are no local customizations, this can also be "fetch" or "cdn" -->
    <vaadin.widgetset.mode>local</vaadin.widgetset.mode>
</properties>

<repositories>
    <repository>
        <id>central</id>
        <url>https://repo.maven.apache.org/maven2</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
    <repository>
        <id>vaadin-prereleases</id>
        <url>
            https://maven.vaadin.com/vaadin-prereleases/
        </url>
    </repository>
    <!-- Repository used by many Vaadin add-ons -->
    <repository>
        <id>Vaadin Directory</id>
        <url>https://maven.vaadin.com/vaadin-addons</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
    <repository>
        <id>vaadin-addons</id>
        <url>https://maven.vaadin.com/vaadin-addons</url>
    </repository>
</repositories>

[nPraml]

thanks, it helped a lot, at first we got <url>https://maven.vaadin.com/vaadin-snapshots</url> as URL from Ansku, but it should be <url>vaadin-prereleases</url>

We will run our failing tests against 8.19-SNAPSHOT and check if the fix helped

[Ansku]

It's possible our internal documentation has an error about the repository name, or alternatively both should work but there's something wrong with the vaadin-snapshots instance at the moment. I still haven't got my laptop back so my access to our resources is currently rather limited, but I'm glad you got it working and I'll look into the repository thing when I have proper tools again. Apologies for the hassle!

[nPraml]

8.19-SNAPSHOT wouldn't fix the problem

[Ansku]

Would you be able to create a simple test UI/project that reproduces the issue?

[Ansku]

And just to confirm, did you remember to rebuild the widgetset? The changes are on the client side.

[maTrojak]

I have created a project that reproduces the issue: https://github.com/FOCONIS/comboboxwaitforvaadin. The issue happens if the combobox has an addValueChangeListener that cleans the value. The issue happens if you set the value in the combobox and then press enter. The waitForVaadin timeout happens on a subsequent use of some ui component in the test, in the sample project i am setting the value of a textfield.

[Ansku]

Thank you, now I can see the issue. Is this only present in your test runs, or something that also affects the end users in some situations? So far things seem to be working ok in manual testing. I'm still digging into what exactly causes things to go wrong there.

[maTrojak]

We had to disable some of our UI tests, so lower quality of our product for the end user. But directly the end user does not see the issue.

[Ansku]

If you'd like to test the fix, it should now be available in 8.19-SNAPSHOT.