Hi, Unlike others on this thread I'm a little more ordinary user of the web. Came across one such modal just today!
So thank you for reporting this. I wish to add that this issue is a bit more annoying on mobile: both on iPad and iPhone. I guess the behavior on Android phones too will also be the same, but this needs validation. Once the webpage loads, it goes into a JS invoked confirm/ok modal that would not relent -- not without seeking credit card info or something else to let you off the hook. The site that I saw today was somehow phishing a *.gov url too, using serious/ even scary warnings with quotes from Federal Law / websites... :-) The only way out then was to delete the browser from my iPad and reinstall it clean. Cheers, On 14 April 2016 at 10:45, Yay295 <yay...@gmail.com> wrote: > *Windows* > IE11, Chrome: Navigation buttons are blocked while modal dialog is shown. > Firefox: Navigation buttons remain usable. > > On Thu, Apr 14, 2016 at 8:34 AM, Majid Valipour <maji...@chromium.org> > wrote: > > > > A very common abuse is that when pulling the mouse to hit the back > > > button because you are not interested in a page, a hover comes up and > > > when the hover comes up, the back button no longer works. > > > > Does 'hover' refer to modal dialog e.g., window.alert? > > That is the only way I know that you can block a user to click back > button. > > Here is a simple page that does this: http://jsbin.com/fuwosaxefa > > > > That behavior is a side-effect of how a browser may decide to implement > > modal dialog which is dependent also on the OS. I tested a few browsers > on > > Linux & Mac and this is what I found: > > > > *Mac* > > Firefox, Chrome, Safari: Navigation buttons are usable while modal dialog > > is shown. > > *Linux* > > Chrome: Navigation buttons are block while modal dialog is shown. > > Firefox: Navigation buttons remain usable. > > *Windows* > > ???? > > > > Perhaps this is worth a non-normative note in the spec in "user-prompt" > > section [1] > > > > [1] https://html.spec.whatwg.org/multipage/webappapis.html#user-prompts > > > > Majid > > > > On Thu, Apr 14, 2016 at 4:38 AM Delfi Ramirez <del...@segonquart.net> > > wrote: > > > > > Agree. > > > > > > May it be done within the History API spec? > > > > > > Just wondering. > > > > > > --- > > > > > > Delfi Ramirez > > > > > > My digital signature [1] > > > > > > +34 633 589231 > > > del...@segonquart.net [2] > > > > > > twitter: delfinramirez > > > > > > IRC: segonquart Skype: segonquart [3] > > > > > > http://segonquart.net > > > > > > http://delfiramirez.info > > > [4] > > > > > > On 2016-04-13 21:44, Michael A. Peters wrote: > > > > > > > It needs to be made very clear as a web standard that no JavaScript > > > action can disable UI functions such as the back button. > > > > > > > > A very common abuse is that when pulling the mouse to hit the back > > > button because you are not interested in a page, a hover comes up and > > when > > > the hover comes up, the back button no longer works. > > > > > > > > This is a browser UI issue but it needs to specified that browsers > must > > > not disable the back button in response to JavaScript. The web is > enough > > of > > > a cesspool as it is. > > > > > > > > > Links: > > > ------ > > > [1] http://delfiramirez.info/public/dr_public_key.asc > > > [2] mail:%20del...@segonquart.net > > > [3] skype:segonquart > > > [4] http://delfiramirez.info > > > > > >
