Watir fails to interact with elements and reports that they are disabled - watir

Whilst automating a collection of integration tests for various OAUTH providers, I found that watir does not seem to work with the Fitbit auth page, and always reports that the text_fields are disabled, no matter what I do.
This may be a bug in watir, or it may be something peculiar to the the Fitbit page (broken HTML or deliberate anti-scripting code).
The fitbit page is located at https://www.fitbit.com/oauth2/authorize/
watir can detect the email text_field exists:
browser.wait_until{ browser.text_field( name: 'email' ).exists? }
but any attempt to interact with it reports an error that it is disabled:
browser.text_field( name: 'email' ).wait_until_present
I've tried tabbing through all the fields on the page to see if this enables it, and I've tried using browser.driver.action.move_to to click on the element, but nothing seems to work.
Any thoughts?

The problem is that there are 3 text fields with the name "email". If you get a collection of the text fields, you can see that only some of them are visible:
browser.text_fields(name: 'email').map(&:visible?)
#=> [false, true, false]
Watir interacts with the first match, which in this case is one of the hidden fields. You actually want the second field - ie the visible one.
You can use the :visible flag to tell Watir to find the first visible one:
browser.text_field(name: 'email', visible: true).set('value')

Related

BluePrism Spy element uniquely

I am spying one button from one browser based application. But I am getting the error saying more than one item found.
I am able to spy it only under the Accessibility Mode.
Although,I can see in my page that there is only one element in my page.
How to refer my element uniquely under Accessibility Mode as there is no exact path to specify.
If you are not able to see the elements, but Blue Prism is saying that there is more than one element found, then you may have unchecked these two attributes:
Visible
Screen Visible
Try setting them as "True", and please check if that will help with your problem.
Different approach would be to use one of these two:
Match Index
Ordinal
In a nutshell, they tell Application modeller about which item should be used, if there are multiple similar object visible.
I think it happens when you are having two fields having same properties like in a login page, username & password have same properties when you spy these elements using Blue Prism it shows the error.So, to get rid of that error, check the box ordinal in the application modeller popup(which opens after clicking ctrl+left click) after you've spied the element.I hope you got it.
Whenever we spy elements it is recommended to uncheck few attributes like parent url, input identifier, title etc.
"if there is an error stating that more than one matching window found" then at this point we have to uncheck "windows text" and check the ordinal attribute.
Please try below in Application module
Uncheck the checkbox with empty values
Uncheck the ParentURL.
You just need to check the Match Index and Ordinal property of the spied element. Ordinal will always gives you the unique element on the screen.
This is even mentioned in Blue Prism's Training module.
For Browser/Web-based application, Ordinal Attribute cant not be found.
To Spy the exact element, you can also use "Application Navigator" or UI Automation Navigator.

XPages: possible bug with enableModifiedFlag in Release 9.0.1FP3 HF241, and workaround

I have a page where I wanted to use the "enableModifiedFlag" property, to let users know that their edit was not saved if they want to leave a page before saving.
I also have a search box in that page, and when I set the field to the static value "true", the message was popping because the search box was considered part of the page, and the field was modified. This all makes sense.
Since the "enableModifiedFlag" property can be computed, I decieded to set it to true only if the document was in edit mode, as the search box is not available at that time. The behaviour I got was that the message was not appearing anymore. I then tested with returning true as the value of the property, and it didn't change anything: the message was just gone. I then used the static values and set it to true, and the message was then appearing.
My conclusion is that there is a bug that prevents any computed value to be considered for that property.
So I had to find a workaround to prevent the message from popping up when users used the serach box. Here is the solution I came up with.
On the client side, we have access to the XSP object. One of its method is XSP._setDirty(). you can either set it to true or false, and it will affect if the page diplays the popup message or not. So in my search button, I added this code on the onclick event, on the client side:
XSP._setDirty(false,""); //so we don't get the "do you want to leave this page" message
showStandBy(); //show standby in case search is long or slow
return true;
That way, I tell my page not to show the message and the popup is not displayed.
It's still a shame you can't use the computed value for that property, but at least we have a workaround. Hope this will be useful to somebody!!!
GOT SOMETHING WORKING I THINK
This is what I have now, that controls teh flag:
<xp:this.enableModifiedFlag><![CDATA[${javascript:context.getUrlParameter("action")=="editDocument";}]]></xp:this.enableModifiedFlag>
I would rather use the document1.isEditable() function, but I wasn't successful with it so far, neither computed dynamically nor on page load.
At leaset I have something that seems to be working. Time to submit that code to the end users!

switch to chrome extension page without the tabs permission

I'm writing an extension for chrome that shows a results page when a user enters a query from the popup.
I would like subsequent queries to use the existing results page rather than opening new ones.
I used chrome.extension.getViews({'type':'tab'}) to get the currently opened extension pages and to pass the query to a javascript function in the open page.
The issue I'm having is switching to that page without requiring the 'tabs' permission.
This snippet of code works well from the background page.
chrome.tabs.getCurrent(function(tab){
chrome.tabs.update(tab.id, {selected: true});
});
However, tabs.getCurrent requires the 'tabs' permission. Is there a way to do this without the tabs permission?
I could use chrome.tabs.update but I don't know how to get the tab id from the view object returned from chrome.extension.getViews.
I'm fairly certain this can't be done without the tabs permission. You have correctly identified that chrome.tabs.update is the function you need, but without the tabs permission, it can only operate on the currently selected tab by provifing a null tab ID argument. Since you can't supply tab IDs in chrome.tabs.update without permission, switching between tabs is not possible.
/edit: As appsilers mentioned, not really doable.
If you can instead use chrome.tabs.create() to open the required tab, it will also return its tab id upon creation.
Otherwise the only way is to plast a global inside the target context and use chrome.extension.getViews() to identify the target and call a focus-stealing function, like alert(). But I'd advise against, since it's more like a hack and there isn't really a guarantee this functionality will keep stable between builds.

Sync jqGrid filterToolbar and searchGrid filters

I am using a jqGrid with both filterToolbar and searchGrid.
When I perform a search using the filterToolbar and then open the searchGrid window, the filters come filled fine.
But when I change something after this, this feature stop working.
I can explain by testing this sample: http://srv04.wln.com.br/cpsadmin/sample
Try typing an 'a' for the fields Name, Address and City in the filterToolbar, then perform a search (pressing return when focus in any input).
After that, click in the 'Find Records' button at the footerBar, this will open the search window, with the 3 fields filleds according with the filterToolbar searchoptions.
But if we try to do something after this, nothing works ok again, since we refresh the page.
I would like to get the power of both, filterToolbar and searchGrid, working together, and in the two ways.
You can try to add recreateFilter: true searching option. To be able to find the exact reason of the problem you should use jquery.jqGrid.src.js instead of jquery.jqGrid.min.js on your demo page.
I recommend you additionally to use refreshSerchingToolbar function which I suggested in the answer. One more answer with the demo could be also interesting for you. It show how to save last searching filter (and some other information) in the localStorage. At the visit of the same page the previous used searching filter will be applied.
UPDATED: It's a little the matter of the tasted, but I personally use the settings
$.extend($.jgrid.search, {
multipleSearch: true,
multipleGroup: true,
recreateFilter: true,
closeOnEscape: true,
closeAfterSearch: true,
overlay: 0
});
or some more advanced version as my default Advanced Searching settings. The recreateFilter: true like recreateForm: true for the form editing are always my default settings. I suggested many times (see here for example) to make the settings as jqGrid defaults, but the suggestings stayed unanswered. Tony (the developer of jqGrid) has another opinion on the subject.

How to use Geb to check element attribute value after page event

After a bit of help here, I am writing a functional web test using Geb and want to test the disabled attribute value of an form submit button both before and after an event has occurred, the flow should be as follows:
Load page, submit button is declared as disabled in page source so should be disabled e.g. <input type="submit" class="submit" disabled="true"/>.
Check a checkbox on the page, this should result in a piece of JQuery code executing which will enable the disabled submit button programatically using: $('input.submit').attr('disabled', false);
My first attempt was to use the assertion $('input.submit').#disabled == 'true', this appeared to work for the initial check after page load however after executing my JQuery code to enable the button a subsequent check still returns the same result. This has caused me to wonder if this kind of check is only able to report the value at page load time and doesn't see any subsequent programmatic changes?
I then discovered Geb's jquery itegration, I was hoping I could use this to return the value of the submit button and do my assert on this e.g. $('input.submit').jquery.attr('disabled') == false however the Geb documentation confirms that all calls to the .jquery property return the Geb Navigator instance so sadly I don't think I can return the information I want.
I have also doubted whether the JQuery code was actually toggling the submit button disabled state, I have tested this extensively using Firebug and can confirm that this is working perfectly in the browser, so I suspect this is either an issue with my understanding of Geb or perhaps a limitation of Geb itself?
It strikes me that checking the value of element attributes after performing some action on a page might be a common use-case, hence I'm rather hoping that I've missed some trivially simple way of doing this. Would be most grateful for any pointers to help me get this sorted.
Cheers,
Edd
Have done a bit more testing and have now achieved a satisfactory result. I was doing a couple of things which I now believe are inproper, namely trying to set the disabled attribute value to illegal values of true and false like this:
$('input.submit').attr('disabled', true);
$('input.submit').attr('disabled', false);
Looking at the HTML forms specification the disabled attribute is shown not to take a value, rather it's presence alone indicates that an element is disabled. Modifying my code to honour this and remove the attribute to indicate enablement of an element seems to have done the trick:
$('input.submit').attr('disabled', true);
//This time we remove the disabled attribute rather than setting it to false.
$('input.submit').removeAttr('disabled');
Note: I am still setting the value of disabled to true since I can't determine how to set the attribute without setting a value, see this SO post for further details.
Using the above I am now able to use Geb to assert the disabled/ enabled status of elements like this:
//Check that something is disabled.
deleteSelectedButton.#disabled == 'true'
//Check that something is enabled.
deleteSelectedButton.#disabled == 'false'
Note: Geb seems to require a string literal indicating the expected status rather than a boolean, which iirc caused my assertions to fail.
So that's it - all is now working nicely and I'm running along writing loads of Geb tests! Hope this explanation is of some use to others.
Rebroadcasting my post on the Geb mailing list:
After you execute the jQuery code that enables the button, is it possible that you are checking the result before the code has actually enabled the button? For example, are doing something like:
waitFor { $("input.submit").#disabled == "false" }

Resources