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
> > >
> >
>

Reply via email to