The Code
I have a linear application where halfway through the user must submit images to continue. The submitFile function is below:
selectFile: function(image) {
var path = require('path');
var image_path = path.resolve(__dirname, image);
this.uploadButton.click();
this.uploadButton.sendKeys(image_path);
}
I know from Selenium that you cannot interact with the OS, just anything contained within the browser. So we've been following the stackoverflow go-to answer for Protractor file uploading.
The Result
The function in practice clicks the file upload button, the dialog box pops up, sendKeys manually tells it what image to use, then it moves on with its life while that dialog box is always open. Chrome and Firefox don't care that the dialog remains, so I can continue testing pages past image upload without issue.
But today, we're getting into trying to automate IE testing and it seems that that pop up must be dealt with to continue. It never hits this.uploadButton.sendKeys(blah);. The moment the dialog is opened IE wants it resolved before continuing.
The Attempts
this.uploadButton.sendKeys(protractor.Key.ESCAPE) right after the click, which didn't work since the test cannot not get past the uploadButton.click().
this.uploadButton.click().then(function() {this.uploadButton.sendKeys(image_path)}), was worth a shot but nope
browser.executeScript('something'); after the click; I forget what the something was but it never got to executeScript
The Thoughts
Is there a way to kill a process from Protractor? To be able to kill explorer.exe / explorer's pid
Is it possible to have a listener to kill the pop up as it happens?
Though would any of the above mess with the sendKeys?
Does the button click and sendKeys even work on IE11?
Right now, I'm just sticking to manual testing for IE, though I'd love to be able to integrate my tests with IE so I can use Browserstack or even just multiCapabilities in my config.
Related
I use jquery-ujs with Rails, which allows us to ask for a confirmation before a form submit by using data-confirm="Confirm submit?".
I have this very weird bug on a specific page that the window.confirm is blinking very fast as soon as I click on the submit button, like if there was multiple event handlers attached.
This is the HTML code:
<button name="button" type="submit" data-confirm="Do you confirm?" data-disable-with="Wait..." class="btn btn-primary">
Submit
</button>
And this is what happens when the button is clicked (note the window.confirm appearing for a flash of a second, and dismissing imediatelly):
The bug:
Doesn't happen in my development env;
Doesn't happen in Firefox
Doesn't happen in other pages where there are identical forms, with data-remote="true" submission, and data-confirm on the submit button.
Doesn't happen in other 4 different macbooks using Chrome as well!
DOES happen in my production env, on my machine, EVEN on private tab;
This is so puzzling because since it happens only on my machine, but even on a private tab, it can't be an extension, but I simply cannot reproduce this bug on any other machine, browser, or even in my own machine in the development env.
It's so weird that even starting rails with RAILS_ENV=production, so that I get all the assets just like they are in production, the bug doesn't happen.
Attaching a debugger to the mouse.click using Chrome devtools (sources tab) makes the bug go away (the debugger fires as soon as I click the button, I resume code, and the confirm window appears only once).
I have no clue how to debug this weird behavior. Could just let it go, but I fear it will come back to bite me later on, so I need to understand why this is happening on my machine.
There was an old bug in the jquery-ujs lib (https://github.com/rails/jquery-ujs/issues/384) but it was fixed years ago and I'm on the latest version of the lib (https://github.com/rails/jquery-ujs/commit/9e805c90c8cfc57b39967052e1e9013ccb318cf8), which even has a safe mechanism that errors out if it's included more than once, and there's no errors in the console (I'm sure the lib is only included once).
Not using turbolinks.
UPDATE 1
I added a gif of the bug above.
Also, I imported jquery-ujs manually (copy and paste from https://github.com/rails/jquery-ujs/commit/9e805c90c8cfc57b39967052e1e9013ccb318cf8) and edited the confirm method:
confirm: function(message) {
console.trace();
return confirm(message);
},
In dev tools, I confirm the trace appears only once even in production when the bug happens, and here's the stack trace:
1) Refresh the page
2) Run this in your Developer console (F12): window.confirm = function() { debugger; }
3) Click the submit button and debug from there.
Inspecting the callstack may give you some insight as to what's happening.
I finally found out the culprit: Facebook pixel code JS.
Like I said, this was a hard one to debug. Any debugger you attached to window.confirm() just made the bug disappear (window.confirm then just appeared once, as expected). Also, I couldn't reproduce it in development, even with RAILS_ENV=production.
So how did I found out? I noticed in the dev tools that every time I clicked that blue submit button, a request was being made to facebook server initiated by fbevents.js. That's facebook pixel code.
Just tried a deploy without that script and ... FINALLY, problem is over.
Damn you fbevents.js
I have a very, very weird issue that only seems to be an issue in Chrome.
When a user comes on the website, the user cannot focus any element (via mouse click, if they focus it via tabbing, the elements don't get the 'focused' state either) and that's only an issue in Chrome. That is, until the user resizes the window, minimizes the window, opens a new tab, opens developer tools, etc. Reloading the page does nothing. However, as soon as focus is "enabled", the user can navigate/refresh with purging cache, etc., close the browser and open it again, and everything works normally - the elements get the 'focused' state normally.
This behaviour can only be reproduced in Chrome and not on localhost.
The difference between localhost and beta environment is:
beta env requires authentication (basic http auth)
files in development env are concated in a single JS and single CSS file and both are minimized
beta env includes hotjar, while there's no hotjar on localhost
There are no custom event listeners that would listen for the 'resize' event. There are no errors in console and all javascript that doesn't depend on focused element state gets executed correctly. Hover events and all CSS styling that depends on hovered state all work correctly.
The main issue is, that a form which has to be filled out and includes a datepicker, cannot be filled out and thus the users can't really interact with the page. Datepicker doesn't open and, as the input elements don't get the focused state, they don't visually change (CSS :focused selector isn't working either) and thus give the impression to the user that they cannot type in the normal text inputs (which works, after clicking on the input, it is possible to type in the input).
I have tried removing hotjar and the problem persisted. The only thing that made the problem go away was removing the basic auth, however, that is not an option in this stage (it's a closed beta test, so we need to limit the access only to the users with password).
I also find it extremely odd that basic auth would interfere with the focused state of elements, especially as the error persists after you refresh and only goes away as soon as you interact with browser itself (minimize, open new tab, do anything that resizes your browser window or document), after that it works correctly and there are no errors whatsoever.
The problem only started to appear recently, but I do not believe it's an issue with the app itself, as I tried rolling back to a couple months old build and the problem persists. All of that makes me believe it's a bug in Chrome, but what can be done to fix it?
EDIT: I also tried to add autofocus property to an input element and, in beta environment, it doesn't get focused.
So it seems it indeed is a Chrome bug that's present both on mobile (Android and iOS) Chrome browsers, as well as desktop Chrome browser (tested both on a Windows and a Mac). I submitted an official bug report. In the bug report, a fellow user made a website that's accessible only through basic auth and only has 2 basic inputs, the input should get a red border on focus. As expected, after opening the webpage in Chrome (for ease of use - incognito mode), the input doesn't get focus and the border doesn't change.
For those who are also affected by this bug in Chrome, you can track the bug progress here: https://bugs.chromium.org/p/chromium/issues/detail?id=740652
Meanwhile, here's a hacky solution for those interested:
$(document).on("ready", function() {
var $inputs = $("input");
$inputs.off("click.trick");
if (!sessionStorage.fixedChromeFocus) {
sessionStorage.fixedChromeFocus = "true";
$inputs.on("click.trick", function() {
var win = window.open("/", "_blank");
setTimeout(function() {win.close()}, 1);
$inputs.off("click.trick");
});
}
});
The goal is to, somehow, interact with the browser outside of the current page, to make it somehow lose focus. You cannot use JS to minimize browser, cannot resize it, cannot open dev tools. What you can do, though, is open a new window. Of course, if you open a new window immediately, a pop-up blocker (as most people have it) will block it and the window itself (or rather your current tab) won't lose focus. Opening a new window can only be done as a reaction to a user event (without triggering potential pop-up blocker).
I also use some browser detection so the code will only be executed for Chrome and, using server-side conditioning, only for builds that include basic auth.
What the code does, quite self evidently, is that as soon as a user clicks on an input, it opens a new tab and quickly closes it, 1ms later. To prevent this from happening all the time, on every page load, sessionStorage, which gets cleared automatically after tabs from that domain are closed, is used (and we've already established that once focus starts working correctly, it will work as long as you keep your browser open).
The effect of this code is that the user will see a quick white flash the first time he clicks on the input, but everything will work correctly
I have an application set up to perform some automation using GeckoFX web browser. My application is nicely setup, everything is working fine.
The problem that I'm running into is that when Gecko loads a webpage into itself, it sometimes doesn't fire the DocumentComplete event for a long time, instead gives an error dialog box that The script is taking too long, with two buttons Continue or Stop the script (although this happens rarely, but does happen).
I can't figure out how to suppress this error/warning dialog. In case the web browser is having a script error, I want it to stop processing and fire the DocumentComplete event anyway, I have coded my application in a manner to handle partially loaded webpages. But I can't reach to this point since the application gets stuck up at the error dialog.
Any suggestions on how to suppress scripting errors like this in GeckoFX? The IE Web Browser control had a property called SuppressErrors (or something).
Thanks in advance!
There exists an about:config setting dom.max_script_run_time which controls how long a script can run before this error appears. Setting this to 0 will disable the dialog entirely.
This can be done programatically in GeckoFX:
Gecko.GeckoPreferences.User("dom.max_script_run_time") = 0;
Via: https://support.mozilla.org/en-US/kb/warning-unresponsive-script
I'm building a quick VOIP demo using Skype and when I press a call button, the Skype application takes the focus away from the browser. You can try here http://developer.skype.com/skype-uris/skype-uri-tutorial-webpages where you'll find several "Try it here" links. When I click those links, I would like the browser to maintain focus. Is there a way to do this?
Thanks.
What you would need to do is apparently called "focus stealing" from my web searches.
At least as far as Windows is concerned, there does not seem to be a reliable way to do this from the browser alone.
I just googled "focus stealing" (which is what the JavaScript only solution would need to do to get this done) and found many answers showing that, though theoretically possible, depending on the configuration of Windows stealing the focus away from Skype by the browser would probably not work in the majority of cases.
The complaints in the Google links are numerous and some answers conflict, but it looks like reliably "stealing the focus" back to the browser is not going to be supported.
This is a good thing though, if you think about it - I do not personally want just any old JavaScript program running in my browser to change my focus from what I am working on back to the browser willy nilly - this would be a very annoying behavior for a web page to be able to do at best, making my system useless at worst.
If you could do it in this case using some methodology allowed in a browser, so could anyone else - even malevolent websites.
The best answer is to never let the focus leave the browser, but I have no idea how to do that in your specific case. Perhaps whatever means you are using to launch Skype may have an option or something to launch it in the background or whatever, never changing the focus.
I did not hit on specific links pertaining to Apple OSes, Linux or mobile OSes, but I have a feeling the same concerns and limitations apply for those as well.
Here are some of the links on the Google search (and sorry about the bad news for your needs):
Microsoft Answers Forum Post
Focus stealing is evil
http://pcsupport.about.com/od/windowsxp/ht/stealingfocus02.htm
you can open it on new window, then close the new window and refocus on yours
somthing like:
a=window.open('skype:ohadcn?chat',10,10);
//i couldn't find a relevant event, onload() do not work for me here
//so i used setTimeOut, hoping that two seconds is enough to open skype but not enough to loose the user
setTimeout(function(){ a.close();window.focus();},2000)
I went to the skype tutorial page in Chrome, brought up the console and tried Ohad's answer, but it would not return the focus to the tutorial web page.
I even tried a script to perpetually put the focus in the Search textbox:
function ASDF() {
document.getElementsByName("q")[0].focus();
setTimeout(ASDF, 1000);
}
setTimeout(ASDF, 1000);
Still no luck.
I tried changing Ohad's script so that it would reopen the tutorial page in a new window after the skype app opened. It would work if the tutoral/console page was the only tab in the window:
a=window.open('skype:ohadcn?chat',10,10);
setTimeout(function(){
a.close();
a=window.open('http://developer.skype.com/skype-uris/skype-uri-tutorial-webpages', 10, 10);
window.close();},2000);
However, if the tutorial page/console script was in window with other tabs, it did not return focus to the reopened page. Not to mention, IE might warn the user that the original page is trying to close.
I do not think there is a way to consistently achieve your goal, but I reserve the right to be wrong.
I am working on a JavaScript file and using the alert() method to print some object information. I am testing my ".js" file on Eclipse.
Every now and then this information is to big to fit in the alert box so I see the alert box but am unable to see the OK button (located usually in the end of the alert box). So I end up force quitting Eclipse. The same thing also happens with some browsers (Google Chrome). Is there any way to prevent force quitting or is this somehow preventable?
I know this question is somewhat general but it happened to me a lot recently and I am wondering if this can be avoided.