Re: [whatwg] JavaScript dialogs blocking user experience

2016-04-14 Thread Arvind Nigam 
> The problem you describe above was addressed by Apple in iOS 9.3 and also in
Safari 9.1 on Mac.

My iPad is on iOS 9.3.1, but I was using the UC browser at the time.

I couldn't relocate the exact scamjam page I saw in the morning, but found
this url of a company that supposedly "helps" people fix the issue on their
phones somehow:

http://guides.yoosecurity.com/how-to-remove-fbi-warning-message-from-iphoneipad/
(This
page is safe, ordinary wordpress/blog.)

Their post is fairly recent. And they have a few screenshots of the modal
that people see so I'm guessing that this is still a problem for a lot of
users out there; and is big enough to warrant/sprout/support scammy
businesses like that.

- a

On 14 April 2016 at 16:25, Darin Adler  wrote:

> > On Apr 14, 2016, at 1:04 PM, Domenic Denicola  wrote:
> >
> > I'm not sure whether this has much of a spec impact. The spec already
> allows great leniency in these areas; e.g.
> https://html.spec.whatwg.org/multipage/webappapis.html#dom-alert step 3
> and the "optionally" in step 7. If any browser has qualms with the current
> language and would like it to be more flexible, we're certainly open to
> that, in the same spirit as the semi-recent
> https://github.com/whatwg/html/pull/714.
>
> Here are two things we might want to address in the specification—not sure
> either is practical:
>
> - Find some place to emphasize the importance of having UI driven by a
> webpage not seem to come from the browser or operating system and not block
> user interface that lets a user “leave”. Documenting this kind of thing
> makes it more practical to build a new browser engine, cutting down on the
> “unwritten lore” needed to make an acceptable user experience. I think
> making this clear is important for the Simple Dialogs feature, but also
> many other features such as full screen modes. Maybe this calls for a
> section like the “Security and privacy” section someone wrote for
> registerProtocolHandler?
>
> - This one is even more “aspirational”: Clarify the relationship between
> multiple webpages that are separately running JavaScript. When content from
> the same website is open in multiple windows, the ancient classic version
> of these Simple Dialogs functions in the oldest web browsers accidentally
> guaranteed that everything in both windows was paused until the user
> responded. I think it would be good if there was some way we could clearly
> state to website authors that this is not the case any more. Ideally we
> would find a way to make it practical to quickly discover if a website
> author accidentally relied on something like that, but I am not optimistic
> that we can.
>
> — Darin

Re: [whatwg] JavaScript dialogs blocking user experience

2016-04-14 Thread Darin Adler 
> On Apr 14, 2016, at 1:04 PM, Domenic Denicola  wrote:
> 
> I'm not sure whether this has much of a spec impact. The spec already allows 
> great leniency in these areas; e.g. 
> https://html.spec.whatwg.org/multipage/webappapis.html#dom-alert step 3 and 
> the "optionally" in step 7. If any browser has qualms with the current 
> language and would like it to be more flexible, we're certainly open to that, 
> in the same spirit as the semi-recent https://github.com/whatwg/html/pull/714.

Here are two things we might want to address in the specification—not sure 
either is practical:

- Find some place to emphasize the importance of having UI driven by a webpage 
not seem to come from the browser or operating system and not block user 
interface that lets a user “leave”. Documenting this kind of thing makes it 
more practical to build a new browser engine, cutting down on the “unwritten 
lore” needed to make an acceptable user experience. I think making this clear 
is important for the Simple Dialogs feature, but also many other features such 
as full screen modes. Maybe this calls for a section like the “Security and 
privacy” section someone wrote for registerProtocolHandler?

- This one is even more “aspirational”: Clarify the relationship between 
multiple webpages that are separately running JavaScript. When content from the 
same website is open in multiple windows, the ancient classic version of these 
Simple Dialogs functions in the oldest web browsers accidentally guaranteed 
that everything in both windows was paused until the user responded. I think it 
would be good if there was some way we could clearly state to website authors 
that this is not the case any more. Ideally we would find a way to make it 
practical to quickly discover if a website author accidentally relied on 
something like that, but I am not optimistic that we can.

— Darin

Re: [whatwg] JavaScript dialogs blocking user experience

2016-04-14 Thread Domenic Denicola 
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of

> The problem you describe above was addressed by Apple in iOS 9.3 and also
> in Safari 9.1 on Mac. That release changed the style of JavaScript alerts so
> that they are less likely to appear to come from Safari, the operating system,
> or Apple. They look more like part of a webpage, and no longer interfere
> with closing a tab or webpage, using the back button to leave the webpage,
> or using the smart search field to enter a new search or website address.

Yes, this is pretty great! +Avi, who sits next to me on the Chrome team, has 
started a similar project for Chrome, inspired very much by Safari's example: 
https://docs.google.com/document/d/1wtV5rmLhbf1OZkbg7crtCt6h1mMtig_ctTQt3BLLEIU/edit?pref=2=1

I'm not sure whether this has much of a spec impact. The spec already allows 
great leniency in these areas; e.g. 
https://html.spec.whatwg.org/multipage/webappapis.html#dom-alert step 3 and the 
"optionally" in step 7. If any browser has qualms with the current language and 
would like it to be more flexible, we're certainly open to that, in the same 
spirit as the semi-recent https://github.com/whatwg/html/pull/714.

Maybe we could consider adding language like "this must not block navigation or 
other parts of the user interface" to step 6, now that more browsers appear to 
be moving in that direction. But practically these changes are mostly being 
driven by browsers interested in improving the user experience for their users, 
and trying to hurry up that process by adding spec language seems like it 
wouldn't accomplish much.

> I don’t think that’s the same topic, though, as what this thread was 
> originally
> about.

I forked the thread, since this topic seems sufficiently interesting on its own.

Re: [whatwg] JavaScript Hovers and Back Button

2016-04-14 Thread Darin Adler 
> On Apr 14, 2016, at 10:38 AM, Arvind Nigam  wrote:
> 
> I wish to add that this issue is a bit more annoying on mobile: both on
> iPad and iPhone.
> 
> 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.

The problem you describe above was addressed by Apple in iOS 9.3 and also in 
Safari 9.1 on Mac. That release changed the style of JavaScript alerts so that 
they are less likely to appear to come from Safari, the operating system, or 
Apple. They look more like part of a webpage, and no longer interfere with 
closing a tab or webpage, using the back button to leave the webpage, or using 
the smart search field to enter a new search or website address.

I don’t think that’s the same topic, though, as what this thread was originally 
about.

— Darin

Re: [whatwg] JavaScript Hovers and Back Button

2016-04-14 Thread Arvind Nigam 
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  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 
> 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 
> > 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
> > >
> >
>

Re: [whatwg] JavaScript Hovers and Back Button

2016-04-14 Thread Yay295 
*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 
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 
> 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
> >
>

Re: [whatwg] JavaScript Hovers and Back Button

2016-04-14 Thread Majid Valipour 
> 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  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
>

Re: [whatwg] JavaScript Hovers and Back Button

2016-04-14 Thread Delfi Ramirez 
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