I've noticed on Chrome and Edge that if I have a javascript confirm (or alert or prompt) message fire, and the user refreshes the page instead of clicking the ok/cancel button, any textfield on the page cannot be edited.
<html>
<body>
<input name="input" value="Can you type here?" />
<script>
console.log("document has focus = "+document.hasFocus())
if(document.hasFocus()==true){
confirm("Refresh this page, do not click cancel or ok");
}
</script>
</body>
</html>
It's as if refreshing on the popup completely blurs Chrome, so the only way to get it back into focus is to click out from the app and back in again. Even constant refreshing by ctrl-R won't put the focus back.
By forcing focus onto the textfield onload, the textfield will have focus but I still can't type into the box, as the browser itself is out of focus.
Has anyone seen this before? A colleague and I couldn't find any mention of this online, apologies if it's been answered.
I'm on Windows 7
Chrome 91.0.4472.77
Edge 90.0.818.46
On my Mac (Chrome 90.0.4430.212) I cannot replicate this.
Cheers
Just posting for the record that I raised this as a bug and it's been merged into an existing bug that I didn't find when searching. As yet no fix on the Chromium side but hopefully will see a fix in future.
https://bugs.chromium.org/p/chromium/issues/detail?id=1085949
Related
Given a webpage that sets the beforeunload event handler in the Safari browser and the development console is closed, the beforeunload handler cannot always prevent navigation away from the webpage. When the development console is open, the handler almost always can prevent navigation away from the page.
This may be reproduced in two ways.
Reproducible Method 1
Using a Safari Browser (Version 12.0.3 (13606.4.5.3.1)) visit the following index.html:
<!doctype html>
<html lang="en">
<body>
<script type="text/javascript">
window.onbeforeunload = (evt) => { evt.preventDefault(); evt.returnValue = false; return true; };
</script>
<p>hello, world!</p>
</body>
</html>
then, open the development console, select the navigation bar, type www.ibm.com and hit return. An alert will appear prompting the user to "Stay" or "Leave".
Close the console, retry the navigation, a prompt may or may not appear. If it does appear and is not clicked within 2-5 seconds ("Stay"), the new page will be visited although the prompt will remain. Clicking on the prompt has no apparent affect after that.
Reproducible Method 2
Using a Safari browser begin to answer a stackoverflow question. Open the development console, then using the navigation bar attempt to visit another site. An alert should appear guarding against loss of form data. Then, close the development console and re-attempt the navigation. This time, the navigation should go through and no alert will be displayed or, if too long before selecting "Stay", navigation will continue.
Discussion
Can anyone else reproduce this?
Advice on whether I should file a bug against Safari or Webkit is welcome.
I've tested Method 1 on Firefox and did not see the same behavior - beforeunload acted mostly as expected.
Have I failed to conjure the onbeforeunload function in just the correct way?
I first saw this using Angular (with rxjs), however, as I've been able to reproduce it with straight HTML and in another website, this has nothing to do with Angular.
EDIT (2019-06-18)
Marked as possible duplicate of this question. It is not because that question explores a bug due to back button and bf history caching in Safari. This problem occurs without pressing the Back Button. If it is related somehow to the browser cache mentioned in the associated bug, someone will have to explain that to me, as I cannot see any obvious connection.
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.
Is this a problem with Chrome or something that I'm doing wrong? I noticed that if I use a file input element to get the file browser/camera prompt to show, then follow it up with something that would cause an alert message, it locks up the entire page forcing me to kill the app to make things work again. Here's a simple jsfiddle that shows the problem:
https://jsfiddle.net/etc4bxpq/
HTML:
<input type="file">
<button id="btn">Click me</button>
JS:
document.querySelector('#btn').addEventListener('click', event => {
alert(1);
});
Tap on the file input, then tap on the Click Me button. The alert won't fire and the page will lock up. It seems to only happen with Chrome on IOS. Safari seems to work just fine.
Having same error with same conditions. I tried wrapping my alerts and prompts with setTimeout function as suggested by some but it did not work for me, tried putting input in another page and calling it inside iframe, also did not works for me. The only solution works for me is using alert modals instead native javascript alert and prompt function. Also if you open chrome settings menu and close it, script continues it's execution which is very strange.
I have a button which is calling a function that displays an alert. The alert is displayed but if I change the messege that the alert is showing, when I press the button the alert will still show the first message I wrote and not the updated one.
It is also happening when I add html tags, they won't show when I run the code.
Why is this happening?
You know the drill: make some edits to your document, click save, switch over to your browser, refresh it, and then observe the changes.
However, every now and again I will catch myself viewing the wrong site page, viewing the site on a different browser, or viewing the client's old live site! Check your address bar + go into your folder and open the page again.
I have a form (with just one text area) that is submitted using AJAX to allow users to save a note about a page. The form stays visible on the page all the time, and you can keep clicking save to keep updating the note.
In safari (but not chrome or FF), if you start typing in the form and hit reload, the browser prompts you with a "are you sure you want to reload, you have unsaved changes" type dialog. My problem is that the dialog also pops up if you save your note, and then hit reload without making any further changes to the text area. Is there some way in javascript for me to mark the form as submitted // unchanged so that safari knows not to show the prompt?
I'm not too sure about safari, but you can have this behavior in all browsers with the following:
var confirmLeavePage = "Are you sure you want to exit this page, you have unsaved changes..."
window.onbeforeunload = askConfirm;
function askConfirm(){
if (confirmLeavePage != false){
return confirmLeavePage;
}
}
then all you have to do is to set confirmLeavePage to false when there are no modifications to the document.
Hope this helps.
Probably not the greatest solution to your problem here .. however, if you remove the html form tags from your form, that should solve it.
Since you are using ajax already, you could get the values of the elements from the DOM directly ..
example ...
<form><textarea></textarea></form>
will give the are you sure message .. where
<textarea></textarea>
will just reload.
Hope this helps on a Friday afternoon :)