Selenium webdriver on Safari: Keys.ENTER not working - javascript

I'm forced to use the Enter key to submit a form in automated testing (the submit button can't be targeted by an automated click event). client.Keys.ENTER works golden in all browsers... except Safari. In Safari it absolutely refuses to press Enter. Return doesn't work either. Is there some Safari Webdriver specific issue that is causing this?
UPDATE: Found the click event. It was counter intuitive and the person who made the page gave me the wrong info. Either way, still can't hit Enter, which is a problem.

The work around is using sendKeys("\n") in a form field in the form that you want to submit. This is equal to hitting the Return key. Another option may be to use submit() in a form field but I am sure the first suggestion works.

Related

Why does my JavaScript event execute on any input, rather than input to the proper field in Chrome?

I have an event I want to execute on key down in an input field. It does as much in Firefox. In chrome, however, it executes the event (a redirect) when I give the page any input (click, key down, etc). I can't seem to figure out why. Any ideas?
Here's the javascript:
var yum = document.getElementById("username");
var form = document.querySelector("div.resp-wrapper form[name='register']");
form.setAttribute("autocomplete", "off");
yum.addEventListener("keydown", function handler() {
window.location.href = "https://giphy.com/gifs/troll-you-mad-face-eVy46EWyclTIA";
this.removeEventListener("keydown", handler);
});
This is the page I'm working on [Link Deleted]; you can see the problem there while it's live. I'll be removing this link eventually.
Oh I guess I should probably mention that this is an invisible form field (it's a honeypot). It's between the captcha and the last visible form field. You can run a test by clicking where the field would be and pressing any key.
UPDATE: I am able to reproduce on my Windows machine; chrome version 74.0.3729.131 (Official Build) (64-bit). On my android, the behavior is the same as well (touching anywhere on the page redirects me) - version 74.0.3729.136. But was not able to reproduce on my Mac chrome version 71.0.3578.98.
Figured it out; and, of course, it was something stupid. I removed the CSS from the form field and realized that, even though I had cleared my cache and browser history, several times, that didn't prevent Chrome's autofill feature from populating that field EVERY time.
When I removed the CSS I could see the field was always populated whenever I visited the page. Chrome had been filling in my email address (oddly, considering it's not an email field). I cleared my Chrome autofill settings and now the code works as expected. It's unfortunate that the autocomplete="off" attribute doesn't prevent this. I've read that usually this attribute is moot because the browser will override it anyway.

Javascript - Input/text can't get focus (Chrome)

I'm doing a registry form, one of the validations is to check the database for existing username. To do that I open a php page in a separate hidden frame that checks the database and then calls a javascript funcion on the main frame to show an icon indicating if the user exists or not.
everything works fine, except in chrome that when the php page is open, the input/text loses focus and there's no way to get it back. I've tried calling focus on the element, using timeout as i've seen this solves similar issues in chrome, but nothing works so far...
any ideas?
Thanks.

Safari ignores submit alterations in onclick event

For a Drupal site I've developed a rather simple module to prevent users of pressing multiple times on a submit button. When the submit button is pressed it's replaced with a small message to have some patience.
The problem in all browsers it seems to work fine with the exception of Safari.
$("input[id^='edit-submit']").click(function(e){
var message = Drupal.t('Please wait...');
$(this).hide();
$('<span>' + message + '</span>').insertAfter(this);
});
When I look into the debugger I see an attribute appearing style="display: none;" but Safari seems to ignore it. When I manually (through the developer tools) add a display:none the button disappears.
I don't know it jQuery doesn't run in Safari on form submit is related because when I add a console.log() between the click function body it is executed once (the $(this) value also points to the correct element) but it doesn't respond to any changes on that button.
It seems that from the moment you click on the submit button it is in some kind of locked state - which would also prevent double submits - but I want to be rather sure this is standard behaviour for safari then a bug that could haunt me in the future.
I've tried googling on certain keywords but I couldn't find anything documentation that describes this behaviour in Safari.
EDIT: I also tried removing (and detaching) the button on the onclick which makes the button disappear, but then the form doesn't get submitted anymore.
Try to use:
.css('display', 'none');

Is there an alternate way to trigger autocorrect/autocomplete on mobile Safari (on iOS) when the user presses enter?

I know that normally the browser will handle autocorrect/capitalization/etc on its own when the user presses enter. But I'm using the contenteditable attribute and doing some special handling on "enter" that requires me to use evt.preventDefault() when the user presses enter. Since I'm using preventDefault() in my listener, mobile safari leaves the autocorrect bubble open and it gets pretty funky looking/unusable. Is there any alternate way (maybe using JS to fire an event) to dismiss the bubble or trigger the normal behavior without having to take out preventDefault?
I don't want to get rid of autocorrect functionality, since it is important to my application.
There should be sample code! But I think you talk of something like this:
$("#myForm").submit(function(event) {
event.preventDefault();
// Do other stuff
});
So I'm pretty sure you could fire the .blur-event manually which could fire that autocomplete-function:
$("#myForm #myInput").blur();
If this answer is wrong, please provide sample code - not everybody on Stackoverflow is a magician.
I will say its easy with focus set,
in contrast to previous answer which works with submit the auto behavior will continue to auto correct..
$("#MyInput").focus(function(event){
event.preventDefault();
});
$("#MyInput").blur(){ // do events you want on focus lost.. from input.. :)
});
I think this will do..

JavaScript - detect browser stop button click

I have a form that disables submit button, when it is clicked.
But what if the user clicks browser "Stop" button.
Then he will not be able to resubmit the form.
Is there any way to handle such cases, possibly detecting Stop button press?
What is the reason for disabling the submit button?
You are trying to avoid double-clicks? -> you can disable the submit button for only a brief period of time, re-enabling it again on a timeout.
You are trying to avoid impatient reload-clicking? -> the same, but with a longer inactivity period.
You are trying to stop a form being submitted twice causing duplicate actions to occur? -> you can't fight this just with button disabling, as going back/forward will cause the page to be reloaded, likely keeping old form content but not the disabledness state, unless short-circuited by bfcache. In this case you must create a one-use token or new item ID that cannot be used more than once, and put it in a hidden field in the form. The server can check for it and disallow duplicates.
possibly detecting Stop button press?
Avoid onstop, it's not really reliable. Apart from browser support issues, it can't catch all possible combinations of navigation and stop/reload/etc. You'll never know how far the server script got, whether it performed an action.
Your best bet would be to detect the submit button on the server, so it can only be submitted once. This way, no matter what happens (firebug etc), the form is only submitted once. There is an OnStop() event, but it is IE only, and I would not recommend using it.
document.onstop
You can find documentation for it here:
http://www.codeguru.com/forum/archive/index.php/t-437967.html
https://developer.mozilla.org/en/DOM_Client_Object_Cross-Reference/document

Categories