-
Notifications
You must be signed in to change notification settings - Fork 728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Combobox suggestion popup filtering UI test waitForVaadin newer finishes #12562
Comments
I haven't found a way to reproduce this, but I did find a bug in |
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. |
I only made the pull request to the |
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. |
You can access the snapshot builds by adding these to your pom.xml:
within your
on its own (assuming you don't have that 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. |
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. |
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 |
Hi @Ansku , we tried to use the 8.19-SNAPSHOT in our project (in pom.xml the
If we open the URL
|
No idea what's wrong - it could be the firewalling/routing on your end, it could be international routing, it could just be your 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:
|
thanks, it helped a lot, at first we got We will run our failing tests against |
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 |
8.19-SNAPSHOT wouldn't fix the problem |
Would you be able to create a simple test UI/project that reproduces the issue? |
And just to confirm, did you remember to rebuild the widgetset? The changes are on the client side. |
I have created a project that reproduces the issue: https://github.com/FOCONIS/comboboxwaitforvaadin. |
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. |
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. |
If you'd like to test the fix, it should now be available in |
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.
The text was updated successfully, but these errors were encountered: