Alright, in my web application there's a dropdown that UFT picks up as a 'WebElement' instead of a 'WebList'. The options available in this dropdown are all just 'divs' and the data within the div is dynamic. Has anyone had to deal with this before? I even tried using the absolute xpath within the object repository, but that seems to be inconsistent. Whenever I run my test the first time it interacts with the dropdown it will wait the entire object sync timeout before selecting the element. Then I have it going back to select another item from the dropdown and it goes instantly. This isn't the approach I want to take with this as the abs xpath could break at any time. I've been reading blog posts etc from as far back as 2008, and tried every person's suggestion but I can't reliably click a dropdown and select something. I can give more detail if needed, but any help here would be appreciated.
When UFT waits the object synchronization timeout and then succeeds to perform the action it's usually because it has been using smart identification. Look in the report to see if this is the case (or just disable smart identification and see what happens).
If this is the case, you should try to fine-tune the description to succeed on the description and not resort to smart identification.
I got it! This behaviour was being caused by the 'browser' being different in that part of my code. I think this happened due to some of the same items being added into the OR from different pages.
Instead of having:
Browser("Browser1").Page("Page1").WebElement("Element I want").
It was:
Browser("Browser2").Page("Page1").WebElement("Element I want").
Once this was corrected in the OR everything worked as expected.
Related
My REST service is performing lots of http queries which I would like to monitor in my dashboard. In it's APM view I can choose from servlet.request operation name or netty.client.request. The former one is the primary operation, while the latter one is additional operation.
What I managed to do was that I am able to build a widget in the dashboard which uses metric-type source like this: default_zero(sum:trace.netty.client.request.hits.by_http_status{$env,$service,!http.status_code:200}.as_count()) and it works, it shows me the number of errors client is getting, but when I click on the widget and choose show related traces I do not see traces related with netty.client.request operation, but the ones related with servlet.request. The reason for it was that it generates following query env:prod service:payments-braintree-gateway -#http.status_code:200, which does not include operation name, nor "all spans" (next paragraph explains it)
So I went to traces view in APM and I tried doing the query I wanted, there. Initially I was only able to choose one operation in the filters - servlet.request, but I noticed a button next to search bar labeled in, where you can choose in which set of spans to search for. There are 2 options: service entry spans and all... Switching to all made it possible to create a query I am interested in: $env $service operation_name:netty.client.request -#http.status_code:(200) and it works... So the only thing left was to use it in the dashboard.
Now when I am back in the dashboard's widget I fiddled with the query in json, I tried to edit context menu links, I even changed metric type from "metric" to APM... All in vein. Looks like it is impossible to use non service entry spans in widgets.
Funny thing is that I even exported from APM's service view error graph to dashboard and then clicked "show related traces" it still showed incorrect thing, while "show related traces" option in the graph in the APM takes me to the correct view in traces
So... is it possible to fix "show related traces" button in the DataDog dashboards?
Looks like the only doable solution is to hide standard traces link and create new custom link. Downside is that it is going to open a new APM browser tab instead showing traces in the modal at the right hand side of the screen, but at least it works. Still ideas how to tackle it differently are welcome of course :)
I have a set of tabs with proper roles and attributes for accessibility support. The content that tab controls gets loaded in via ajax. But each wrapper for the content loaded in also has proper tab pane roles and attributes.
The problem is, when I run an automated audit using Chrome Accessibility Tools, the test fails stating that the corresponding ID of the tab pane is missing for all of the tabs except the one that's currently active (because that wrapper with ID has been loaded). The exact error states: "ARIA attributes which refer to other elements by ID should refer to elements which exist in the DOM."
Since the ID will exist once the tab with the corresponding aria-controls attribute is active, is this really an error? Or is this just a case of a false positive because it's an automated test and they can only do so much.
In summary, What does aria-controls do and does it really need to refer to an ID that currently exists in the DOM?
aria-controls give your assisting technology a way to move to the controlled element.
If this element is not in the DOM or can't be accessed, then yes it's an error.
The two (the element with aria-controls as well the element with the referenced id) must exist at the same time, whether at page render or via JS injection.
The DOM is parsed by the UA/AT combo before the user even gets to the control or your script fires to make it exist. If you use JS injection then you need to make sure the DOM is re-parsed.
This would apply to aria-owns as well.
I don't know whether the following would work in your architecture, but it would solve the error problem:
Design the tabs so they are all in the page at the time it loads. Format those that should not be shown to be outside the viewport using absolute positioning and something like "left: -99em." Use AJAX to reset the positioning when the time has come to display the tabs. The result is that the ARIA ID dependencies will always be valid because the tabs are always part of the DOM.
I have a form that normally works with respect to dirtyforms. However, there is one circumstance where a jquery-ui datapicker calendar will pop up the "are your sure" dialog when a date is clicked.
I emphasize that this normally works correctly. The situation is related to the initial conditions of the form data source. Things work when the object being referenced is existing, but not if it is new. So I am sure somewhere there is a difference in the initial conditions of the form. But in theory the form should be identical.
How can I find what is causing the popup so I can fix my issue?
Well, I did find what was causing my problem by comparing the HTML of the working and non-working situations. (Not an easy task since there were many non-relevant differences.)
Seems that the original coder did a strange thing. Left out some Javascript function declarations when the page was "new" but of course did not eliminate the calls on those functions.
So I guess that the javascript errors were the root cause. At least when I include those function declarations everything works correctly.
By default, most anchor links on the page will trigger the dialog. We don't have a hard-coded selector of all potential 3rd party widgets, you must manually take inventory of whether these widgets use hyperlinks and ignore them if they are causing errant behavior.
See ignoring things for more information.
I was unable to reproduce this behavior using Dirty Forms 2.0.0, jQuery UI 1.11.3, and jQuery 1.11.3. However, in previous versions of Dirty Forms, you can probably use the following code to ignore the hyperlink clicks from the DatePicker.
$('.ui-datepicker a').addClass($.DirtyForms.ignoreClass);
Does anyone know how to delete an element from the source using Watir? There doesn't seem to be a method for removing elements. Perhaps I'm missing something.
If you know JavaScript, you could execute any JavaScript code on the page.
Example:
browser.execute_script("some javascript code")
I am not a JavaScript ninja, but this question could help you: JavaScript: remove element by id.
Remove elements by css:
browser.execute_script("[...document.querySelectorAll('.some.class')].map(e => {e.parentNode.removeChild(e)})")
We can remove it with javascript. Here's an example to remove a breadcrumbs div element but it's id:
browser.execute_script("bd = document.getElementById('breadcrumbs'); bd.parentNode.removeChild(bd);")
The Purpose for Watir is to do web testing, which is to say drive the browser as if a user was interacting with it. That means doing the things a user could do, clicking on stuff, filling in input fields, etc. It also means being able to verify what is there on the screen that the user can see or interact with.
Since a user cannot delete elements, there is no means by which to do that using the tool.
If the application provides a way for users to 'remove' or 'delete' something, like closing a simulated window, removing a tab etc, then you need to do that by simulating what the user would do (usually clicking on some specific element) in order for that to happen.
The newer versions of Firefox have a new 'feature' that remembers the stuff that was filled out in a form and repopulates the form with these values on refresh (maybe in other situations as well?).
The problem is we have a quite complicated web application which uses a fair bit of ajax and hidden form fields which are never filled out by the user, but by javascript.
Because of this new 'Feature' we get a lot of errors when refreshing form because these fields are suddenly populated with invalid values.
So i'm looking for a way to turn this 'feature' off without disabling auto-completion. (because that IS useful on the fields our customers fill in)
if i put
autocomplete='off'
in my html, the effect is disabled, but this loses auto-completion (obviously).
the problem is in fields getting filled in after a refresh without any user action.
While the password manager will populate a username and password if there is exactly one match, autocomplete itself doesn't automatically populate fields. But I'm guessing you're thinking about the sort of refresh you get, say, if you reload the page. In this case the field values are restored by session history, but you might be able to turn that off by marking your page as uncacheable.
Well you should set the value of these fields to nothing or or whatever default value they have using javascript right before you start your other javascript/ajax tasks.
It is a browser feature - without going into the settings of each client browser you can't disable this.
I suggest more robust validation - client and server side.
After the page is loaded, but before you do any other logic, you should force the value to be empty:
inputElem.value = '';
Here is a jQuery solution I put together.
It doesn't disable the autofill, rather it overrides the fields after the browser has done it's thing.
I was trying to fight Chromes autofill when I made this. Just using .val('') on it's own didn't work since it triggered before chromes autofill functionality kicked it.
var noFiller = $('input[type="text"]');
noFiller.val(' ');
var t=setTimeout(function(){
noFiller.val('');
},60);//keep increasing this number until it works
The Javascript solution (setting field values to empty when the page loads or updates via Ajax) has already been mentioned.
Another option might be to generate the ids of your fields with random numbers attached to them so that the browser can't match them to cached values, but this may screw up other things.
Autocomplete isn't a new thing. Every browser has it. See this http://www.w3.org/Submission/web-forms2/#the-autocomplete
Autofill? Are you sure? Check your input's value attribute with Firebug (Firefox addon). Check you post and response in your ajax. Maybe your ajax is filling it behind scenes.
BTW: remenber to disable any external toolbar. There are some toolbars for Firefox/IE/Chrome/etc that autofill data for the user. Warning with this.