RobotFramework: can'f find element with JavaScript - javascript

Working with RF in recent weeks I noticed a problem, which stuck me for a long time. I have constant error:
Element with locator 'XXX' (this is a template, of course) not found
Investigation of span that wanted to locate revealed, that it has some JavaScript code under it, that, from what I think, enables it dynamically.
input bo-attr="" id="inventory-keyword" ng-attr-placeholder="{{('inventoryMode.' + {true: 'KEYWORD_DEVICE_PLACEHOLDER', false: 'KEYWORD_TEMPLATE_PLACEHOLDER'}[items.currentSeen == VIEWS.EQUIPEMENT]) | translate}}" ng-model="getCurrentFilters().searchString" class="ng-pristine ng-valid" placeholder="Name, description..."
How to have it passed by RobotFramework?
Or maybe source of the problem is different?
There are other elements like this (with sth that appaers to be JavaScript under it), and none of it is seen by RF, except the main menu.

From the Javascript code you have added to post, it seems the underlying Web Application uses AngularJS (I can see ng-model in code).
Sometimes, you cannot identify elements in AngularJS developed Webpage using the default ways the Selenium provides.
You can use AngularJS library or ExtendedSelenium2Library which has new ways to locate elements like model/binding etc.
Check below links for more information :
AngularJSLibrary
ExtendedSelenium2Library

Related

Polymer - Load different components dynamically

I'm a Polymer novice, but I guess what the answer will be...
Recently I came across with this issue: I got to loop through a collection of elements (using dom-repeat) and display its contents. But every element has a unique display and bindings, making it almost impossible to display each element dynamically. The ideal scenario would be to load a different component for each display type, but it looks like there is no easy way to achieve this.
Some options I have been thinking of were the following:
Using dom-if but it would add crap to my resulting HTML.
Is there a dom-switch? If it were something like that and didn't leave empty template tags (as it would do with dom-if) it would be nice.
It's possible to load a component dynamically? Using something like this: <[[item.type]] item-configuration=[[item.configuration]]></[[item.type]]>
Any other ideas? I would really appreciate any ideas or solutions or at least a workaround for my issue.
TL;DR; you can't
Polymer (and Web Components in general I guess) are best when used in a declarative way. Out-of-the-box your best solution is dynamically creating elements and adding to DOM or messy use of dom-if.
(potential) OPTION 1
I guess you could fairly easily implement a dom-switch element to work like
<template-switch switch="[[some.value]]">
<template-case case="10">
<element-one></element-one>
</template-case>
<template-case case="20">
<element-two></element-two>
</template>
<template-default>
<element-one></element-one>
</template-default>
</dom-switch>
I wrote this off the top of my head. There are multiple ways to implement such an element. A crucial decision is whether to use <template> internally or not. In this plunk I've implemented such element without templates but simply using content distribution.
OPTION 2
There is also Polymer.Templatizer.
Faced with a similar issue of choosing element to render dynamically I created this Plunk as a proof of concept.
As you see, you extend the <template> element with custom rules, which match against a model. You then bind the matched template's nodes with the model using Polymer.Templatizer.
Thanks to Templatizer, you don't have to pollute your actual element with conditionals and still get full binding functionality.
I'm working on a more feature-complete solution. If you're interested I could move it to a separate repository and publish.

Mysterious div being appended to hyperlinks

We run a Ruby on Rails 3.2 web application that uses a standard mix of rails and jquery.
Recently, we noticed a strange div element appearing in our production code. It seems to only show up when we render views with strings that also contain hyperlinks.
Here's an example:
We have a string in our view, that we want rendered as HTML:
"Try to search <a href='/search?q=hiring'>hiring</a>"
When we render the page in production though, we get the following:
"Try to search <a href="azarvuttcexyytzq.html" id="qqqqtra" rel="file">trufarwdstrzyzdyw</div>."
We're not sure why but the following div is being appended to our link:
<div style="display: none;">trufarwdstrzyzdyw</div>
What's strange is that we don't think that the file azarvuttcexyytzq.html exists on our servers, and we also found out that "file" is not an acceptable rel value for a hyperlink's relation attribute.
So, where could the div be coming from?
One thought is that it is coming from some analytics library in our system, since we're using Google Analytics. But we can't seem to confirm that idea or rule it out.
Does anyone know of a library that causes behavior like this?
Any help or insight would be appreciated.
If there is no developer who has done this (intentionally or otherwise) by appending a div with a random hyperlink in your application, then there is a high probability that your application server, some library or a gem you are using is compromised. It would be good to do an audit of your code/server and ensure that you are using the original version of all the gems and libraries and no malicious code is otherwise included in your app code.
We had the exact same issue, although intermittently, and it was Distil networks injecting in our case. To verify we took Distil out for the site and it worked like a charm!
Although, have yet to find how to get it working with Distil, will update the answer if/when we do
We had the same issue, our application behind Distil as well as in other comments.
If you use Distil, read this:
https://help.distilnetworks.com/hc/en-us/articles/235705127-Optimizing-Honeypot-Links-for-Pages-with-Inline-JavaScript
In short: Add the following comment near the top of your page (and above the JS) to force Distil injection to happen there: </a> -–> You can also add any other custom, a unique comment which Distil could use to inject the honeypot link code into.

Selectize Capybara acceptance testing

I am looking for some assistance with acceptance testing of the Selectize jQuery plugin using the Capybara test framework.
We are having a problem with the way Selectize lays out the HTML it generates, there is no definitive link between the select dropdown and the values contained within the dropdown
As you can see from my jsfiddle here : http://jsfiddle.net/et4t20wz/
$('.test').selectize({
create: false,
dropdownParent: 'body'
});
Viewing the source code, the containing div has the 3 selects within it and the values for the dropdown are contained within the body tag.
I need a way for our test team to be able to create a 1 - 1 connection between the two elements. So far we have come up with a rather weak connection, as we know the first Selectize values will be stored in the first div.selectize-dropdown we can use this logic to map to the first div.selectize-control
This is rather flimsy and probably not the best approach, but the best we can come up with thus far. We have found a few solutions on the web, but sadly they appear to be out dated or reliant on different DOM structures.
For example: http://climber2002.github.io/blog/2014/09/22/capybara-integration-tests-with-jquery-selectize/
Hopefully we are not the only ones to have come in contact with this problem and someone can offer some assistance / advice
Thanks in advance.
I believe the link is just positional in the html, the two divs that make up a a selectize control are inserted immediately after the select element that is converted. Therefore if you know the id of the original select you should be able to get the associated divs using the sibling selectors
page.find(:css, '#test + div.selectize-control + div.selectize-dropdown')
or
page.first(:css, '#test ~ div.selectize-dropdown')
if you've already clicked on the div.selective-control (or maybe the input in it) then the elements in the .selectize-dropdown should be visible and you can click on them
So we managed to fix this problem using a solution I found here :
Capybara integration tests with jquery.selectize
The code didn't really work, however. So I ended up using this script I wrote.
var selectize = jQuery('#key').selectize()[0].selectize;
jQuery(selectize.setValue(selectize.search('#value').items[0].id));

Keep the javascript fully separated from markup on primefaces

I'm working on a web interface with the help of primefaces framework.
In that interface, one of the objectives is to have the code divided in javascript functions that do not share information between each other and they don't allow being invoked by other parts (that eases testing and reduces the number and complexity of possible use-cases).
All "parts" are encapsulated using:
(function (window, document, undefined){
var $ = window.jQuery;
// main content here
})(window,document);
The communication required between each part is minimal and the required one is made using DOM events where an object is passed between each other. (if the event is not caught, it's just a functionality that didn't act. If it caused something to break, the js does not stop working, among other reasons).
This has been working for quite a while with minimal bugs found until I had to work with jsf+primefaces.
By reading the documentation, primefaces has many XML tags that do not map to HTML tags. One of the main ones I have to work with is <p:ajax>.
This tag was many on*-like attributes whose concept works much like the HTML3's ideology of writing javascript in HTML's "on*" attributes. Still, those <p:ajax> are always attached to specific XML elements like <h:inputText> or <p:commandButton> and that's where I started looking at.
In primefaces documentation, there's information about the inline on* attributes but I was fully unable to find information about jsf or primefaces' personalized DOM events.
How it appears with primefaces, I'm forced to change the javascript code so that functions/methods can be called inline in the HTML. That would require a lot of work also because, depending on the situation, the js code might even not be there (because the feature it enables is not required for that page).
How do I make the system on primefaces such that I have my javascript fully detached from the jsf/primefaces XML (and the whole HTML output I can manage).
EDIT:
I ran out of ideas on where to look at, I'll work on looking at primefaces source code now. I may get better luck there.
EDIT:
Meanwhile I got some ideas for searching using different keywords and I found this(see: "Client Side API"):
http://courses.coreservlets.com/Course-Materials/pdf/jsf/primefaces/users-guide/p-ajaxStatus.pdf
This is near what I wanted but it seems like it does not exist for the elements I mentioned above. I'll work on continuing searching for more.
After some testing, investigation, etc... I was finally able to understand the whole story of what was happening.
Primefaces was doing everything right after all! The <p:ajax> has the correct code to send all the events it should! The problem lies in jQuery itself.
jQuery's trigger() method (and it's shortcuts) works in such way that it handles all events directly inside jQuery bubbling and calling the callbacks registered using on() (or any of the shorthands).
The main issue in jQuery is that it only resend the "click" event to the DOM because it tries to use a method in the DOM element with the same name as the event. In the DOM, (at the moment) the only situation when that happens is the "click" event. That's why I was getting the click event and not the rest of the events.
With that, the mistery and confusion was, finally, solved. uff!

How does one properly test a javascript widget?

So, I've written a little javascript widget. All a user has to do is paste a script tag into the page, and right below it I insert a div with all of the content the user has requested.
Many sites do similar things, such as Twitter, Delicious and even StackOverflow.
What I'm curious about is how to test this widget to make sure that it will work properly on everyone's webpage. I'm not using an iframe, so I really want to make sure that this code will work when inserted most places. I know it looks the same in all browsers.
Suggestions? Or should I just build one hundred web pages and insert my script tag and see if it works? I would hope there is an easier way than that.
Once you have confirmed that your javascript works cross-browser in a controlled environment, here are some things that might cause problems when used on an actual website:
CSS
You're using a CSS class that is already being used (for a different purpose) by the target website
You're using positioning that might interfere with the site's CSS
The elements you are using are being styled by the website's CSS (you might want to use some sort of "reset" CSS that applies only to your widget)
HTML
You're creating elements with the same id attribute as an element that already exists on the website
You're specifying a name attribute that is already being used (while name can be used for multiple elements, you may not be expecting that)
Javascript
What is the expected behaviour without Javascript enabled? If your script creates everything, is it acceptable for nothing to be present without JS?
At very basic you should make sure your widget works for following test-cases. I am sure then it will work on all web-pages -
http/https: There should not be any warning for HTTPS pages for unencrypted content.
<script> / <no-script>: What if JavaScript is disabled? Is your widget still visible?
What happens when third-party cookies are disabled? Does your widget still work?
Layout-box restrictions: When parent div element's size is less than your widget. Does your widget overflow the given size and destroys owners page?
By keeping all your Javascripts under a namespace (global object) with a very unique name, you should be pretty much OK. Also, you can simply use an anonymous function if you just want to print out something.
Similar question: How to avoid name clashes in JavaScript widgets

Categories

Resources