I'm running a scenario where form fields are automatically filled in with invalid values which trigger some javascripts to show warnings under each incorrectly filled field when I blur.
The test passes when the browser is in focus. It finds the xpath with the "expected warning" that I pass. But if I minimize or just click on another application, it fails to find the xpath.
I'm running Firefox 3.6 (going to update it soon) and the way I'm doing to find the xpath is by using "page.should have_xpath(xpath)"
Does anyone have any idea how what might solve this? It's really important for me to run it with the browser minimized.
Edit and alternative solution:
I guess the timing issue that occurs in events such as blur followed by finding a certain xpath in a minimized browser inherent to the driver itself. Therefore, I decided to run the tests in a Virtual Frame Buffer using xvfb in Linux and it seems to be working really well. I'm planning on applying this to be triggered by Hudson/Jenkins whenever a change is committed.
Could it be a timing issue? Perhaps if the browser isn't frontmost and maximised, the rendering is not happening quickly enough for the content be present when Capybara checks for it.
Also: How are you triggering the blur event?
Related
I write UI tests using Selenium Webdriver 2.0 with Python 3.6. A popup appears randomly, that causes focus to be lost, causing my test to fail. It appears for one second, randomly on different pages, and doesn't exist in the DOM, how to win it?
What I've tried:
Try/except
Wait for element
Sometimes these methods help but it's unreal to add it on every step to wait or catch that element
I expect my tests shouldn't fail because of that popup.
here it is
I have a Xpage that takes too long to load. So the client ask me to do a loading indicator.
I searched and found XSP.startAjaxLoading(), that I put in onClientLoad event of the Custom Control.
But now I don't know where should I put XSP.endAjaxLoading() to make the loading screen go away.
I'tried to use in afterRenderResponse and beforeRenderResponse: view.postScript("XSP.endAjaxLoading()"), since this comand is CSJS, but it doesn't work.
Thanks in advance.
I think you want to put it in the onComplete event. That can be difficult to find. You typically need to use the outline control to find it.
I have a video demo on NotesIn9 that has an example on this.
http://www.notesin9.com/2016/02/19/notesin9-188-adding-a-please-wait-to-xpages/?unique=http%3A//www.notesin9.com/2016/02/19/notesin9-188-adding-a-please-wait-to-xpages/
Your attempt (view.postscript) works only with full/partial updates and does not work for page loading.
You have used onClientLoad - which is executed when your page is finished with loading. I guess you get ajax animation after a while and it won't stop.
You should make preload screen - very simple XPage which starts animation and does not care to turn it off. In onClientLoad event redirect to your slow XPage. That will discard the animation.
I'd highly recommend using the Standby Dialog XSnippet https://openntf.org/XSnippets.nsf/snippet.xsp?id=standby-dialog-custom-control. I use it as a standard in all XPages applications.
I used this answer as solution: https://stackoverflow.com/a/35481981/5339322
I've saw it a few days ago, what made me think twice is that using this i should know what is doing my XPages to delay. I ran some tests and discovered what, and it was a call to a method in the afterRestoreView event, then I migrated it to onClientLoad event and used the solution in the answer above cited.
But I'm afraid that I have to keep an eye on it, so if someone adds some code that delays in one of the another events of XPages I have to move it again, of course, if it's possible, if it's not, I'll figure it out something diferent.
Thanks for all the answers ans comments.
I am using jquery in my web page. I see a lot of memory leak happening and after a while the whole browser grinds to a halt. I used the sieve tool and noticed that there is a contsant increase in the no. of DOM elements, everytime by a no. of 4.
Am I doing something wrong in the way I have associated events?
Or is it because I am using setTimeout to redraw my app every X seconds?
Event association:
$('.bir_Names').click(showNames);
The selector $('.bir_Names') evelautes to a set of some 300 elements each of which call the function on click.
setTimeout
Every X mins I remove every single HTML element in the app and rebind fresh data and associate the events. I use jquery remove() to delete elements. have tried innerHTML = '' and empty() also.
I see a jump of nearly 30-40 MB for every redraw and Sieve indicates that none of the deleted nodes are actually removed.
Anyhelp would be greatly appreciated. This thing is driving me nuts.
Thanks.
You don't mention which browser, but some googling seems to indicate that this is a known problem with IE. Here's one potential workaround:
http://forum.jquery.com/topic/possible-memory-leak-in-remove-and-empty
Note that that's referring to a 1.2.x release of jQuery. Before you do anything, make sure you are running the latest 1.6.x release to first see if the defect has already been fixed within jQuery.
[EDIT] ack...you DO state your browsers...'all'...so maybe disregard that first link.
I'm adapting my regression tests to test a web app in firefox. The biggest stumbling block seems to be how to automate the modal dialogs in firefox.
In ie I use variations of the script below, but it doesn't work in Firefox. Is there an alternative that will work in both ie and firefox?
popup=Thread.new {
autoit=WIN32OLE.new('AutoItX3.Control')
ret=autoit.WinWait(title,"",60)
if (ret==1)
puts "There is popup."
autoit.WinActivate(title)
button.downcase!
if button.eql?("ok") || button.eql?("yes") || button.eql?("continue")
autoit.Send("{Enter}")
else
autoit.Send("{tab}")
autoit.Send("{Enter}")
end
elsif (ret==0)
puts "No popup, please check your code."
end
}
at_exit { Thread.kill(popup) }
end
button.click_no_wait
check_for_popups("Message from webpage", "OK")
Given you are talking about a javascript created dialog, I really have to ask, is there a lot of value in actually testing those?
It basically amounts to testing the functionality of the browser
If you are talking about the type of popups described here http://wiki.openqa.org/display/WTR/JavaScript+Pop+Ups then I think the first solution, of overriding the javascript may well be your best cross platform option.
The problem with modal dialogs like this is that they are basically a UI even that is happening out at the OS level, it's no longer inside the browser DOM, and thus you need tools that are specific to the OS (like stuff that depends on win32ole, such as autoit) in order to generate the necessary interaction with the native UI and click buttons, send keystrokes etc. Most of the solutions presented should I think work with FF on windows (with proper renaming of expected window titles etc) but would fail on a mac or *nix OS. That means you need a different solution for each OS, which is a pain.
It might simply be easier to verify you can find the proper stuff that would fire the event in the HTML of the page, so you know an event WOULD be fired, and then override things so it isn't. After all it's not really your job to validate that the browser pops up a local dialog when something like alert('This is an alert box') is invoked in javascript. Your concern is that in the HTML a given element is coded to fire off the event that is needed e.g. that there's something like this onClick = 'javascript:x = confirm('Do you really want to do this');" affiliated with the element
I am experiencing a similar problem in Firefox (and I do have to test in Firefox). I can see the code calling the Javascript but when I try to override as described above nothing happens. Is there any kind of a workaround for this? Anticipated updates to Watir? ;-)
In our MOSS '07 site we have a page that contains just a Page Viewer web part in it that points to a site on another server. However, I've noticed that on that page (and any others that have a Page Viewer web part on it) our drop down menus and hover effects are super slow and completely max out the CPU on the visitor's computer (process is IExplorer.)
Through testing, I was able to determine that it doesn't matter what URL the web part is pointed to...just having the Iframe on the page seems to cause it (just setting the viewer to load Google's homepage--which is probably the simplest site I know--still causes the problem). If I go and remove the web part, the menus start functioning just fine again.
I attached a debugger to the process and stepped through the Menu_HoverStatic and called functions and it seems to have a hard time when assigning panel.scrollTop to zero in the PopOut_Show function.
Has anyone else noticed this? ...perhaps found a solution to it? I can't find where to edit PopOut_Show function on our server (I think it's a resource in one of the .NET DLLs) or else I'd just comment out that line as I don't think it's really important anyway...at least on our site.
I really like the ability to have web pages from another server hosted in our SharePoint site, but the performance on the hovers is agonizing... and, honestly, unacceptable. Depending on the resources of the user's computer, the hover effects can take 15 seconds to complete at times!!!!
Any suggestions would be really appreciated!
SharePoint's built-in JavaScript is probably making the browser wait until the IFrame within the Page Viewer Web Part has completely loaded. If you can see a status bar message that says "Please wait while scripts are loaded..." when you attempt to click on the page then that's definitely the problem.
Thank you for your reply. I was actually able to discover what the problem was (my appologies for not sharing it here with everyone when I did!)
The problem wasn't so much from having the IFRAME on the page, it was because I had set the zone to be 100% width and height. Because of a but in IE, trying to calculate the location of the dropdown was erroring (I don't remember what javascript function or call was exactly to blame, but I remember stepping through it with the debugger.) I believe it had something to do with "location offset" or something like that. My take at the time was that it was trying to position the dropdown menu on the screen, and the calculation for positioning it was failing.
To get around it, I had to set a javascript routine to programmatically set the height of the zone after the page loaded. Exactly setting the height prevented the dropdown problem in the menus. Of course, it wasn't ideal because if a user resizes the window, the IFRAME (or, more precisely, the zone it's in) doesn't resize with it. But, it was a suitable band-aid for the problem.
I'm hoping that IE 8 will fix this when it's released.