While doing same testing with Geb in a Grails application, the tests passed when runned with default's HtmlUnitDriver.
But, when I changed to ChromeDriver, I was receiving
org.openqa.selenium.InvalidElementStateException: Element is not
currently interactable and may not be manipulated
when testing the login page.
The exception was thrown immediately after setting the emailField (selected through its id '#username'). The strange thing was that I was seeing the browser setting the value on the field, but after that (and before executing the following line of the code) it throwed the Exception.
I noticed that the login page had 2 elements with id="username" (one of which was a hidden field), and that was the reason of the exception. When I changed the id of the login page to another value (and updated the selector), the problem was solved.
I was getting the same exception when I was trying to access a text field on popup window.
org.openqa.selenium.InvalidElementStateException: Element is not currently interactable and may not be manipulated
I realized that the window is shown in two places and verified that indeed the Xpath being used to identify the text field on popup window was showing me two results in the FireBug+FirePath Plugin.
I updated the Xpath such that it would uniquely identify text field on the second popup window and the issue was resolved.
Related
when I run our vaadin 23 app in production mode, I get following error in the browser console, while the corresponding site is rendered twice:
Uncaught (in promise) TypeError: [Vaadin.Router] Expected router outlet to be a valid DOM Node (but got null)
First it's rendered with a corrupt textfield (UI written in Vaadin); the second page looks fine. When I try to debug (IntelliJ), it gets rendered correctly, so I added log messages, where I learned, that the HomeView gets initialized even three times, whereas in dev mode it is initialized once. I find it hard to figure out why, since that is run in a thread (I'm far from knowing Vaadin well).
We have two apps, a backoffice and a webshop. The non-responsive backoffice does not show this issue, only the webshop. The webshop also uses two lit web components (but even when I comment them out, I have the same error). The rest is all kept in Java.
Does anybody have an idea how to solve this, or in what direction to search and debug?
Thanks a lot! Sura
This is likely caused by a known bug with the eagerServerLoad flag. As a workaround, try disabling this flag to prevent the issue.
Add vaadin.eagerServerLoad=false to application.properties to disable the flag, assuming that your application uses Spring Boot. You could find alternative ways of setting the property see the Configuration Properties article.
I am using Maximo 7.6.1.1 and Birt (eclipse 4.3.1). The requirement is to add some page related text with a field from the report into the footer on each page, so I am attempting to update the master page footer. The master page is local, not extended.
I have tried to repeat this from 2013 (https://www.youtube.com/watch?v=lw_k1qHY_gU&t=4s) without success.
So using page level variables as described by the link did not work - it appears that the page event for the variable I chose (when the variable is about to be updated on the page) did not seem to be getting invoked.
Has this possibly changed (since 2013) or does someone know of another work around?
I tried to add a number of data elements to the footer without success.
I did see that if I added a value to the footer element in the initialization event for the report, that we could see that but we never got any updates even though the field we wanted to use was updated as it is normally.
I don't know Maximo, but these page variables only work if BIRT is running in 2 steps: RunTask, then RenderTask. If the program is using the single-step RundAndRenderTask, page variables don't work. This behaviour has not changed with "newer" BIRT releases.
I'm using processmaker 3.0.1.7-community, I've added the Print button to the form. However, when I print using that button, a dropdown field does not display its value on the printout, but is correctly displayed on the form itself.
Weird enough, when I use the print functionality from the browser, the printout has the correct value displayed.
Used Internet Explorer, tried on Chrome same thing.
I think this is a bug that was reported before when I was working in ProcessMaker. Have you tried upgrading to the latest version and see if it works?
I hope this helps.
I am working on a web app that utilizes jquery UI for drag/drop functionality.
There's a strange problem in IE browsers only. When user drops an item inside a container, that item is added to the container but also leaves a remnant of it on the page.
Here's a working DEMO.
Drag items from the left column to yellow field to create container.
Add second item to newly created container.
What's causing it and how can I fix it?
This happens in IE8 and below.
The error is:
SCRIPT5007: Unable to get value of the property 'options': object is
null or undefined jquery-ui.min.js, line 105 character 158
That line is:
var a=d(this).data("draggable").options;
The jQuery UI version they are using is 1.8.11.
I would suggest upgrading to the latest version of jQuery UI and see if that resolves your issue.
If not, you might want to create a test case and submit it to them as a bug.
I'm building a form in the Orbeon Form Builder. The simplest way to recreate this problem is as follows:
Put a control on the form.
Give it any label, it does not matter.
Go to 'control details'.
Change the 'Control Name' to 'test-controlenummer'.
Confirm with the 'apply' button.
See the control itself disappear
Notice that the question mark of the help feature does not disappear, nor do the delete and validation options once you hover over the formerly-visible-component. The grid cell also acts as if it was occupied. The control simply does not show and some of the changes to the name and/or validation options result in XPath expression errors.
I have taken a quick look at the underlying xml code, however at first glance I did not find anything out of the ordinary.
It disappears because of a bug in Orbeon Forms 3.9 when control names contain a dash. Like you said, there is nothing wrong with the markup Form Builder generates, but it then incorrectly just doesn't expect a dash to be present in the control name.
This bug has been fixed in the latest code, so it won't be present in the next release.
If you are using Orbeon Forms PE, I recommend you contact Orbeon to see if you can get a patch for this (either through Basecamp if you already have a support account setup, or by email, info AT orbeon.com).
If you are using Orbeon Forms CE, for now, you can work around this issue by avoiding dashes in the names of your controls.