confirm will not give the user a chance to answer if a new window is crated
Reported by
mr.russm...@gmail.com,
Nov 27
|
|||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
Steps to reproduce the problem:
1. Open file
2. Notice confirm window does not display
3. Notice alert window works as expected
What is the expected behavior?
Confirm box will open but will not steal focus.
What went wrong?
Confirm box never asks the user.
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 70.0.3538.110 Channel: stable
OS Version: OS X 10.13.6
Flash Version:
Its worth noting that running the following code in dev tools works as expected but not when run from a file or website.
var x = window.open('thing');
confirm('test');
,
Nov 27
Sorry for the title typo.
,
Nov 27
confirm() and alert() no longer activate their tab and don't wait for user input, which is intended, see bug 747117 and bug 849816 . It's interesting that alert() stays visible, which could be a bug. In the following example the last alert() stays visible even though it doesn't block the script. alert('alert 1'); confirm('confirm'); alert('alert 2'); console.log('console'); If this is also intended, I think a less confusing solution might be to join the text of all suppressed alerts (e.g. with visual line separators, and some text length limiting).
,
Nov 28
even if you do the following it still doesn't work.
var x = window.open('thing');
x.close()
confirm('does not work');
Does this mean I should do a "setInterval" to watch when the document has focus again?
,
Nov 28
Able to reproduce the issue on reported chrome version 70.0.3538.110 also on latest chrome 72.0.3623.0 using Mac 10.14.0, Ubuntu 17.10 and Windows 10. As mentioned steps in the comment #0. Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged. Thanks..!
,
Nov 28
> Does this mean I should do a "setInterval" No, the modern solution is to use Page Visibility API. More info: https://developers.google.com/web/updates/2018/07/page-lifecycle-api
,
Nov 28
@woxxom@gmail.com thanks for the information
,
Dec 4
Seems working as intended.
,
Dec 4
I can see why the code snippet in the original comment is considered working as expected (the window calling confirm does not have focus, so confirm() immediately returns false). However, the example in comment #4 closes the child window before attempting to confirm(). In this case, I would expect the parent window to have focus and the confirm to be shown:
var x = window.open('thing');
x.close()
confirm('does not work');
Can we not safely assume that the window is closed (and focus returned to parent) synchronously?
,
Dec 5
That window may have a "beforeunload" listener which could show a blocking confirmation for an indefinite amount of time. The specification doesn't say anything about window.close() being synchronous: https://html.spec.whatwg.org/multipage/window-object.html#dom-window-close I guess you should use Page Visibility API instead. |
|||
►
Sign in to add a comment |
|||
Comment 1 by vamshi.kommuri@chromium.org
, Nov 27