Re: Should we be using or avoiding window.confirm()/alert/prompt/modal dialogs?

[Kevin Grandon]

I highly recommend fixing window.confirm to look standard if it's not. The reason: tons of existing HTML mobile apps leverage it. I know I use confirm/alert a lot in my iOS/android apps so they feel more native.

I'm not sure of the impact of the blocking nature of the call, but if it's bad, maybe we should consider a shared async implementation?

Thanks,
Kevin

----- Original Message -----
From: "Andrew Sutherland" <asuth...@asutherland.org>
To: dev-...@lists.mozilla.org
Sent: Thursday, February 28, 2013 1:43:33 PM
Subject: Should we be using or avoiding window.confirm()/alert/prompt/modal dialogs?

The system app provides a window.confirm() implementation.
Unfortunately, it currently is not actually using the shared/building
blocks confirm.css so it doesn't meet Visual Design guidelines and has
wrapping problem, etc. See
https://bugzilla.mozilla.org/show_bug.cgi?id=818047#c5

In the e-mail app we are currently largely displaying confirmation
dialogs by just using confirm.css and throwing up an appropriate DOM
hierarchy ourselves, but we have 2 window.confirm() calls.

Should we/other apps be avoiding window.confirm(), or should we be
trying to use it? MDN has very little or nothing to say on
https://developer.mozilla.org/en-US/docs/DOM/window.alert and friends
about re-entrancy of JS within the page in single-process Firefox, let
alone multi-process B2G where we might not bothering spinning nested
event loops, etc.

Andrew
_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Alive Kuo]

The reason why it doesn't use BB is because it was implemented before we invent BB.

I think there're two issues you addressed here:
1. Make modal dialog up to building block
-- This is pure gaia work. One way is changing the HTML tags(dangerous because code logic change is needed) and alternative is just fixing the wrapping problems.

2. Async alert. IMO this should be gecko work.
Justin, could you tell us more about this?
IMO alert/confirm/prompt should be blocking by the way we use this API:

var result = confirm('delete me');
console.log(result);

If the confirm call isn't blocking JS execution, the console here may print something unexpected.




Furthermore,
modal dialog is having some problems but they are not `blocking` before.
For instance, if we have 3 continuous alert:
alert(1);
alert(2);
alert(3);

The last two alert event would be discarded per current implementation.
But this use case is very seldom so nobody argued this.

If you guys think you have to use window.confirm to do something and find it hard to use in your case,
file a bug and c.c. me, we could find out how to solve it together.

We could continue the discussion in the bug thread if no others have different opinion on this. Too specific to be discussed here. :)


- Alive

----- 原始郵件 -----
寄件人: "Andrew Sutherland" <asuth...@asutherland.org>
收件人: dev-...@lists.mozilla.org
寄件箱: 2013年3 月1日, 星期五 上午 5:43:33
標題: Should we be using or avoiding window.confirm()/alert/prompt/modal dialogs?

[Tim Chien]

Agree that window.confirm/alert/prompt should be fixed and matches the
behavior of the web(TM).


We should file bugs against style and behavior against these.

--
Tim Guan-tin Chien, Senior Front-end Dev., Mozilla Corp. (Taiwan)

[Justin Lebar]

> MDN has very little or nothing to say on
> https://developer.mozilla.org/en-US/docs/DOM/window.alert and friends
> about re-entrancy of JS within the page in single-process Firefox, let
> alone multi-process B2G where we might not bothering spinning nested
> event loops, etc.

AFAIK we're doing the right thing on B2G with blocking, spinning up
nested event loops, and all that nonsense. But it hasn't been
exercised thoroughly, and I suspect you could break it if you tried
hard enough. (I suspect the same is true for desktop FF's
implementation, tbh.)

But my opinion is that alert and co are pretty evil. They're fragile,
and they're blocking. Convenient though it may be to use them on B2G,
I'd prefer if we didn't. Not like my preference counts for much,
since I'm not hacking much on Gaia. :)

Does that answer your questions?

-Justin

[David Bruant]

Le 28/02/2013 22:43, Andrew Sutherland a écrit :
> MDN has very little or nothing to say on
> https://developer.mozilla.org/en-US/docs/DOM/window.alert and friends
> about re-entrancy of JS within the page in single-process Firefox, let
> alone multi-process B2G where we might not bothering spinning nested
> event loops, etc.

This page isn't very helpful indeed. I'll add that to my TODO list and
improve it at some point.
If there are other pages for which don't answer your questions, please
file a doc bug [1] or reach out to me directly [2]

I've recently written a little something about concurrency and the event
loop [3] and alert/prompt/confirm, etc don't conform to this model. They
just block everything until interacted with.

David

[1] https://bugzilla.mozilla.org/form.doc
[2] brua...@gmail.com or on Twitter @DavidBruant at your convenience
[3] https://developer.mozilla.org/en-US/docs/JavaScript/Guide/EventLoop

[Josh Carpenter]

Hi everyone,

Let's match UX with devs on this issue. In my v1 experience it is generally best to work with the natural behaviors of the web (go with the flow, truth to materials, less needless work, etc), but sometimes the standards' default behaviors are not applicable to effective mobile interaction design patterns / heuristics. That's where UX and devs can work together to define the solution based on mutual understanding of constraints and system-wide design patterns/principles. Vivienne, Etienne and I engage in a fair bit of this in v1, rejiggering areas like notifications as we learned more about the constraints, and occasionally giving Vivienne heart burn when we had to implement a hack to enable a vital piece of functionality. ;)

I'll forward this to the UX team and we'll follow up on this thread.

Thanks,

—
Josh Carpenter
UX, Firefox OS
Mozilla

On Mar 1, 2013, at 4:17 AM, Tim Chien <timd...@mozilla.com> wrote:

> Agree that window.confirm/alert/prompt should be fixed and matches the
> behavior of the web(TM).
>
>
> We should file bugs against style and behavior against these.
>
>

>> trying to use it? MDN has very little or nothing to say on

>> https://developer.mozilla.org/en-US/docs/DOM/window.alert and friends
>> about re-entrancy of JS within the page in single-process Firefox, let
>> alone multi-process B2G where we might not bothering spinning nested
>> event loops, etc.
>>

>> Andrew
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>>
>
>
>

> --
> Tim Guan-tin Chien, Senior Front-end Dev., Mozilla Corp. (Taiwan)

[JOSE MANUEL CANTERA FONSECA]

El 01/03/13 03:04, "Alive Kuo" <ak...@mozilla.com> escribió:

>
>The reason why it doesn't use BB is because it was implemented before we
>invent BB.
>
>I think there're two issues you addressed here:
>1. Make modal dialog up to building block
> -- This is pure gaia work. One way is changing the HTML tags(dangerous
>because code logic change is needed) and alternative is just fixing the
>wrapping problems.

I think that should be changed to use the Bbs, even though it would only
land on master, but that's technical debt that should be resolved.

>
>2. Async alert. IMO this should be gecko work.
>Justin, could you tell us more about this?
>IMO alert/confirm/prompt should be blocking by the way we use this API:
>
>var result = confirm('delete me');
>console.log(result);
>
>If the confirm call isn't blocking JS execution, the console here may
>print something unexpected.

That could be a nice to have, but a shared library could do the trick, as
the one we share between the comms apps

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx