I am writing functional tests and dealing with a modal window that fades in and out.
What is the difference between displayed and present?
For example I have:
settingsModule.container.displayed and settingsModule.container.present
where settingsModule represents my modal window.
When testing my modal window (the modal from Twitter's bootstrap), I usually do this:
def "should do ... "() {
setup:
topMenu.openSettingsModal()
expect:
settingsModule.timeZone.value() == "Asia/Hong_Kong"
cleanup:
settingsModule.closeSettingsModal()
}
def "should save the time zone"() {
setup:
topMenu.openSettingsModal()
settingsModule.timeZone = "Japan"
when:
settingsModule.saveSettings()
then:
settingsModule.alertSuccess.size() == 1
settingsModule.alertSuccess.text() == "Settings updated"
when:
settingsModule.saveSettings()
then:
settingsModule.alertSuccess.size() == 1
cleanup:
settingsModule.closeSettingsModal()
}
and on and on. In my modules, I have:
void openSettingsModal() {
username.click()
settingsLink.click()
}
void closeSettingsModal() {
form.cancel().click()
}
I always get a complain: "Element must be displayed to click".
In my openSettingsModal and closeSettingsModal, i tried many combination of waitFor with time interval and using present or not ... Can't figure it out.
Any pointers would be highly appreciated. Thanks!
I think the main difference is that present would check that there is an element in your DOM, whereas displayed checks on the visibility of this element.
Remember that webdriver simulates the actual experience of an user using and clicking the website using a mouse, so if the element is not visible to them, they will not be able to click on it.
I wonder if your issue has to do with settingsLink not being in the DOM when the page is first loaded. If you are waiting for a dialog to popup and a link to live in this dialog, then you probably want to set something like
content{
settingsLink( required: false ) { $( '...' }
settingsModal( required: false ) { $( '#modalDialog' ) }
}
your waitfor should look something like
username.click()
waitFor{ settingsModal.displayed }
settingsLink.click()
I would stick with the book of geb conventions and just use displayed all the time.
Geb Manual - Determining visibility
Thanks for your reply. I was actually able to resolve my issue.
The problem was that the modal window had an animation of 500ms. Opening and closing the window several times in my tests made them succeed/fail inconsistently.
What I ended up doing is hooking the the "shown" event provided by the plugin. I ended up adding a "shown" class to the modal and check for it every 100ms during 1s.
void openSettingsModal() {
username.click()
settingsLink.click()
waitFor (1, 0.1) { $("#settingsModal", class: "shown").size() == 1 }
}
void closeSettingsModal() {
form.cancel().click()
waitFor (1, 0.1) { $("#settingsModal", class: "shown").size() == 0 }
}
As a side note, the tests were failing in Chrome and Firefox BUT were passing in IE!! I am guessing that because IE 8 doesn't support animations that my tests were passing.
It is all good now.
I hope it will help someone someday!
Where we can use displayed?
If a particular element you are removing or deleting, if it is still there in DOM and not displayed in page, you can use assert thatelement.displayed == false which will make sure that element is not displayed in the page (but still it is present in DOM)
Where we can use present?
In the same example as above, after removing,if the element is not found at the DOM ,you should use present for verification
assert thatelement.present == false
Hope you understand....
Adding to the above, present takes more time in script execution
Related
our team decided to zoom out the whole site. So they did this:
This is breaking my PW tests while clicking on the button.
I get this in the inspector:
selector resolved to visible <button id="add-to-cart-btn" data-partid="04-0001" data-…>ADD TO CART</button>
attempting click action
waiting for element to be visible, enabled and stable
element is visible, enabled and stable
scrolling into view if needed
done scrolling
element is outside of the viewport
I found this is an issue in PW https://github.com/microsoft/playwright/issues/2768
My question is: how can I bypass this in the most efficient way?
Is there a way to override a playwright function that sets the initial loading of the page and set my zoom there?
Since if I do it via JavaScript, then I have to do it every time my page reloads, and that can be really tedious and error-prone in the tests.
This is what I have now, but it is really a hack a like solution:
async removeZoomOutClassFromBodyElement() {
await this.#page.evaluate(() => {
const body = document.querySelector('body');
if (body) {
// Removes the class only if it exists on the body tag
body.classList.remove('zoom-out');
} else {
throw Error(ErrorMessage.BODY_NOT_FOUND);
}
});
}
Can you please advise what would be the best approach here?
Thanks!
I've been racking my head against this for 2 days now. I'm massively frustrated, and I can't seem to find any information on this with searching.
The issue. I'm using a :remote => true link to load some html from a different controller.
$('.managed_locations').bind('ajax:complete', function(evt, xhr, status){
$('#locations_modal').modal('show')
$('#locations_modal').html(xhr.responseText);
});
So it gets the html, dumps it into the bootstrap modal and displays the modal. This is working fine.
But inside of the modal I ALSO have a form which also uses :remote => true. Now to make life harder, when a button is pressed I clone the form and display it. So the user could have many forms.
Now the issue. Whenever the form is submitted it just loads it like a normal page. It's as if the :remote => true is being ignored. But this only in the modal. If I just load the modal controller by itself it works just fine. I also had this developed before using another jquery lightbox where it was working fine. I'm just switching in bootstrap for consistency.
So my initial thoughts are that the jquery_ujs.js isn't finding the new forms. So I added some code to output the form elements.
$("#log_events").click(function () {
$(document).find(".new_stored_physical_location").each(function() {
console.log( $(this).data() );
console.log( $(this).data('events') );
});
return false;
});
Which outputs in the console:
Object { type="html", remote=true}
Object { ajax:complete=[1]}
So I see that the events are being set in jQuery. Each of these forms has :remote => true and has the ajax event for when the request is complete. But it's just not doing an ajax request when I hit submit.
Is there something I'm missing that is required to make sure an ajax request will happen from the form???? The data() looks fine, the data('events') look fine. But is there some other event/binding that I need to look at?
The html that is loaded in from the modal right now is loading a layout. But i've done it both with a layout, without a layout. It's driving me nuts. Thanks for the help guys.
Edit: Some extra weirdness. The modal also loads some additional remote links, all of which are working correctly. It's only the form links which don't seem to work.
I got a solution. The big issue was within jquery_ujs.js Especially this line:
$(document).delegate(rails.formSubmitSelector, 'submit.rails', function(e) {
FYI, rails.formSubmitSelector = 'form'. So this code found all of the forms in the document, overwrote the submit with this function. But the issue was that once you loaded in some ajax, and that ajax contained a it wouldn't add this fancy event to it. You need to re-add it.
So this is what I did.
Inside of jquery_ujs there is a bunch of functions that are accessible outside of it using $.rails. So things like: $.rails.enableElement, $.rails.nonBlankInputs. And the code for the submit event was sitting around all willy nilly. It only executes once when the page is loaded. So I put that in a function addSubmitEvent():
// Add the form submit event
addSubmitEvent: function(element) {
//$(element) was before $(document) but I changed it
$(element).delegate(rails.formSubmitSelector, 'submit.rails', function(e) {
var form = $(this),
remote = form.data('remote') !== undefined,
blankRequiredInputs = rails.blankInputs(form, rails.requiredInputSelector),
nonBlankFileInputs = rails.nonBlankInputs(form, rails.fileInputSelector);
if (!rails.allowAction(form)) return rails.stopEverything(e);
// skip other logic when required values are missing or file upload is present
if (blankRequiredInputs && form.attr("novalidate") == undefined && rails.fire(form, 'ajax:aborted:required', [blankRequiredInputs])) {
return rails.stopEverything(e);
}
if (remote) {
if (nonBlankFileInputs) {
return rails.fire(form, 'ajax:aborted:file', [nonBlankFileInputs]);
}
// If browser does not support submit bubbling, then this live-binding will be called before direct
// bindings. Therefore, we should directly call any direct bindings before remotely submitting form.
if (!$.support.submitBubbles && $().jquery < '1.7' && rails.callFormSubmitBindings(form, e) === false) return rails.stopEverything(e);
rails.handleRemote(form);
return false;
} else {
// slight timeout so that the submit button gets properly serialized
setTimeout(function(){ rails.disableFormElements(form); }, 13);
}
});
}
This is basically the exact same code. But now it's $(element) instead of $(document). This was changed because now I can sniff for when the modal has loaded in the html. Then I can call:
$.rails.addSubmitEvent('#my_modal');
I then had an issue of it adding the event too many times from when I opened/closed the modal multiple times. So I just put a simple true/false if around it to call it once only.
I am working on a asp.net mvc site that uses facebook social widgets. Whenever I launch the debugger (ie9 is the browser) I get many error popups with: Error: '__flash__removeCallback' is undefined.
To verify that my code was not responsible I just created a brand new asp.net mvc site and hit F5.
If you navigate to this url: http://developers.facebook.com/docs/guides/web/#plugins you will see the pop-ups appearing.
When using other browsers the pop-up does not appear.
I had been using the latest ie9 beta before updating to ie9 RTM yesterday and had not run into this issue.
As you can imagine it is extremely annoying...
How can I stop those popups?
Can someone else reproduce this?
Thank you!
I can't seem to solve this either, but I can at least hide it for my users:
$('#video iframe').attr('src', '').hide();
try {
$('#video').remove();
} catch(ex) {}
The first line prevents the issue from screwing up the page; the second eats the error when jquery removes it from the DOM explicitly. In my case I was replacing the HTML of a container several parents above this tag and exposing this exception to the user until this fix.
I'm answering this as this drove me up the wall today.
It's caused by flash, usually when you haven't put a unique id on your embed object so it selects the wrong element.
The quickest (and best) way to solve this is to just:
add a UNIQUE id to your embed/object
Now this doesn't always seem to solve it, I had one site where it just would not go away no matter what elements I set the id on (I suspect it was the video player I was asked to use by the client).
This javascript code (using jQuery's on document load, replace with your favourite alternative) will get rid of it. Now this obviously won't remove the callback on certain elements. They must want to remove it for a reason, perhaps it will lead to a gradual memory leak on your site in javascript, but it's probably trivial.
this is a secondary (and non-optimal) solution
$(function () {
setTimeout(function () {
if (typeof __flash__removeCallback != "undefined") {
__flash__removeCallback = __flash__removeCallback__replace;
} else {
setTimeout(arguments.callee, 50);
}
}, 50);
});
function __flash__removeCallback__replace(instance, name) {
if(instance != null)
instance[name] = null;
}
I got the solution.
try {
ytplayer.getIframe().src='';
} catch(ex) {
}
It's been over a months since I last needed to debug the project.
Facebook has now fixed this issue. The annoying pop-up no longer shows up.
I have not changed anything.
I'm trying to implement a comparison chart-like table, and a large list of selectable objects would work just perfectly, save for a few functionality changes that I need. I see that both of these have been addressed in previous questions, but neither of them provide complete solutions.
This question addressed the multiple select behavior by default, but only says 'I did it on my own' without providing anything. Looking at the internals of selectable, I see that if I play with the !event.metaKey condition I could probably get the behavior I'm looking for without too much trouble, but was wondering if anyone had a solution that didn't involve editing the internals.
Similarly, this page addresses the lasso toggle effect that I desired, but I'm not sure where in the code the lasso functionality was changed and as the rest of the script (the sortable functionality) is reported to not work in chrome or IE8 (link) and is outdated as this point, I'd rather not rely on the entire thing.
So if anyone could help me out with either of these, I'd appreciate it. Thanks
[Edit] Formatting...
I'm sure there's a better way to do this, but here's what I've did within the selectable js file.
For the always multi-selection:
I added an option 'alwaysMulti' (default false). Then I replaced the three instances of !event.metaKey with (!event.metaKey && !options.alwaysMulti) and the two instances of event.metaKey with (event.metaKey || options.alwaysMulti).
To get the selection lasso to toggle the selected status, I found the changes I needed from the second page I linked to. I also added an option 'lassoToggle' (default false) to trigger this functionality. Within _mouseDrag, there is a condition if (hit), it gets changed to the following:
if (hit) {
// SELECT
selectee.deselect = false;
if (selectee.selected || (options.lassoToggle && (selectee.startselected && event.metaKey)) {
selectee.$element.removeClass('ui-selected');
selectee.selected = false;
selectee.deselect = true;
}
if (selectee.unselecting) {
selectee.$element.removeClass('ui-unselecting');
selectee.unselecting = false;
}
if (!selectee.selecting && (!options.lassoToggle || !selectee.deselect) {
selectee.$element.addClass('ui-selecting');
selectee.selecting = true;
// selectable SELECTING callback
self._trigger("selecting", event, {
selecting: selectee.element
});
}
if(selectee.deselect && options.lassoToggle) {
selectee.$element.removeClass('ui-selecting');
selectee.selecting = false;
selectee.$element.addClass('ui-unselecting');
selectee.unselecting = true;
// selectable UNSELECTING callback
self._trigger("unselecting", event, {
unselecting: selectee.element
});
}
}
Note: The event.metaKey change for the multi-select isn't in that code sample.
Hopefully this helps someone else!
I'm having problems to get browser's back button work properly on web flow.
Version of grails is 1.1.2.
Imagine example code:
def someFlow = {
...
fillGroup {
on("addMember"){
...
}.to "fillMember"
}
fillMember {
on("addMember") {
...
}.to "fillMember"
on("goToCart").to "showCart"
}
showCart {
...
}
}
Now, I add group, several (>1) members and go to cart. Problem is that during filling the members the URL remains the same. URL execution parameter changes only if the state (view) changes.
So Firefox remembers fillMember pages as one page because the URL doesn't change. Therefore back button doesn't work properly. If I am on showCart and push back, I get to fillMember page. Further push of back button returns fillGroup. I need it to go through all the fillMember pages.
Is there any way to force Grails web flow to change the execution parameter even though I redirected to the same state? Or can I put my own parameter into the URL?
I found one pretty ugly way how to do that: use two fillMember states - fillMember1 and fillMember2, both doing the same thing, one redirects to another. But I need one more action state to be able to distinguish the actual state when hitting back and forward buttons. This construct works but I'd prefer easier way.
Thanks for any answers
Tom
So far, the only solution I've found is the one I mentioned. Use two view states, both doing exactly the same thing, and one action state to hold some state information (it would be difficult to properly distinguish processed member without it). The code would be something like this:
def someFlow = {
...
fillGroup {
on("addMember"){
...
}.to "fillMemberLogic"
}
fillMemberLogic {
action {
...
flow.stateinf += 1
if(flow.stateinf%2 == 1)
return gotoFillMember1()
else
return gotoFillMember2()
}
on("gotoFillMember1").to "fillMember1"
on("gotoFillMember2").to "fillMember2"
}
fillMember1 {
on("addMember") {
...
}.to "fillMemberLogic"
on("goToCart").to "showCart"
}
fillMember2 {
on("addMember") {
...
}.to "fillMemberLogic"
on("goToCart").to "showCart"
}
showCart {
...
}
}
Since the view is being changed for every member, the execution parameter is also being changed and URL is distinct for every member. Firefox distinguishes viewed pages according to URL, so you can go back and forth through all the members using back and forward buttons.
Web flow is mapping URL with current state of flow object. Therefore it's easily possible to distinguish the current member you are processing after several back button pushes.