On Mon, 5 Mar 2012, Biju wrote:
Today I again landed on a malicious site which trap users using
alert/confirm to download some application.
On Mon, 5 Mar 2012, Rick Waldron wrote:
All three of these are considered highly effective tools in mobile web
development - they offer functional UI
Today I again landed on a malicious site which trap users using
alert/confirm to download some application.
URL :
All three of these are considered highly effective tools in mobile web
development - they offer functional UI for free.
Rick
On Mon, Mar 5, 2012 at 10:34 PM, Biju bijumaill...@gmail.com wrote:
Today I again landed on a malicious site which trap users using
alert/confirm to download some
On 5 March 2012 23:52, Rick Waldron waldron.r...@gmail.com wrote:
All three of these are considered highly effective tools in mobile web
development - they offer functional UI for free.
along with window.open() malicious sites also love those features.
to make browsing safe (especially for
On Tue, 10 Jan 2012, Adam Barth wrote:
On Tue, Jan 10, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jun 2011, Adam Barth wrote:
On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org
wrote:
28.02.2011, в 21:38, Ojan Vafai написал(а):
FWIW, chromium is
On Tue, 14 Jun 2011, Adam Barth wrote:
On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org
wrote:
28.02.2011, в 21:38, Ojan Vafai написал(а):
FWIW, chromium is planning on experimenting with disallowing modal
dialogs during the beforeunload/unload events.
On Tue, Jan 10, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jun 2011, Adam Barth wrote:
On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org
wrote:
28.02.2011, в 21:38, Ojan Vafai написал(а):
FWIW, chromium is planning on experimenting with disallowing modal
On Tue, Jan 10, 2012 at 2:38 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Jan 10, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jun 2011, Adam Barth wrote:
On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org
wrote:
28.02.2011, в 21:38, Ojan Vafai
On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org wrote:
28.02.2011, в 21:38, Ojan Vafai написал(а):
FWIW, chromium is planning on experimenting with disallowing modal dialogs
during the beforeunload/unload events.
http://code.google.com/p/chromium/issues/detail?id=68780
28.02.2011, в 21:38, Ojan Vafai написал(а):
FWIW, chromium is planning on experimenting with disallowing modal dialogs
during the beforeunload/unload events.
http://code.google.com/p/chromium/issues/detail?id=68780
What is the big difference between alerts from unload and alerts in general?
On Fri, Jun 10, 2011 at 2:35 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
Do we have any data on whether these warnings have any useful effect?
I don't, but then, browsers barely ever emit such warnings. So it
would be worth trying to mark some methods as deprecated in this
fashion and
On Thu, Jun 9, 2011 at 3:49 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 1 Mar 2011, Aryeh Gregor wrote:
We could define script APIs, or features of them, as deprecated if
browsers were willing to log some kind of notice to their error consoles
when the feature is used. They all have error
On Tue, 1 Mar 2011, Ojan Vafai wrote:
FWIW, chromium is planning on experimenting with disallowing modal
dialogs during the beforeunload/unload events.
http://code.google.com/p/chromium/issues/detail?id=68780
Please let us know how this goes, so I can update the spec accordingly (to
at
On Tue, Mar 1, 2011 at 9:52 PM, WeBMartians webmarti...@verizon.net wrote:
Aryeh! You have made an ad-hominem attack: shame on you! I mention the
Microsoft use cases only to save space. There are similar cases in the Linux
and Macintosh realms. Judge an idea by its merits, not by its source
On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote:
FWIW, chromium is planning on experimenting with disallowing modal dialogs
during the beforeunload/unload events.
http://code.google.com/p/chromium/issues/detail?id=68780
That sounds fairly unpleasant for users of pages
For comment 3, simply reference the use cases for Microsoft's AfxMsgBox,
::MessageBox and its derivatives. The time out is a well-received idea.
As to comment 2, I agree that the various traps put in place are
exceptionally annoying. An alternative would be a forced closing via the
browser
2011-03-01 11:13 EEST: Robert O'Callahan:
On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote:
FWIW, chromium is planning on experimenting with disallowing modal dialogs
during the beforeunload/unload events.
http://code.google.com/p/chromium/issues/detail?id=68780
That
On Tue, Mar 1, 2011 at 1:13 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote:
FWIW, chromium is planning on experimenting with disallowing modal dialogs
during the beforeunload/unload events.
On Mon, Feb 28, 2011 at 7:42 PM, Ian Hickson i...@hixie.ch wrote:
Well we can't remove support for them from browsers, since millions of
pages use them. Conformance checkers can't really complain about usage of
those APIs, since they can't easily check JavaScript runtime compliance.
So what
Aryeh! You have made an ad-hominem attack: shame on you! I mention the
Microsoft use cases only to save space. There are similar cases in the
Linux and Macintosh realms. Judge an idea by its merits, not by its
source (even if that source is as disreputable as I certainly am).
You are correct
On Thu, 25 Nov 2010, Biju wrote:
1. Can we deprecate alert(), confirm(), prompt() ?
At present many web2.0 js libs are providing alternate [and cool
looking] methods to achieve use cases where we need to use alert(),
confirm(), prompt(). So do we need those modal dialogs any longer?
Well we
On Mon, Feb 28, 2011 at 4:42 PM, Ian Hickson i...@hixie.ch wrote:
2. if we are still keeping them, can we disable them in
onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in
those events to confuse users, so that they can trap users for little
longer.
That's not a bad
On Mon, Feb 28, 2011 at 4:49 PM, Peter Kasting pkast...@google.com wrote:
On Mon, Feb 28, 2011 at 4:42 PM, Ian Hickson i...@hixie.ch wrote:
2. if we are still keeping them, can we disable them in
onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in
those events to confuse
FWIW, chromium is planning on experimenting with disallowing modal dialogs
during the beforeunload/unload events.
http://code.google.com/p/chromium/issues/detail?id=68780
On Tue, Mar 1, 2011 at 11:57 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Feb 28, 2011 at 4:49 PM, Peter Kasting
On Thu, Nov 25, 2010 at 3:30 AM, Nils Dagsson Moskopp
1. Can we deprecate alert(), confirm(), prompt() ?
If sites rely on them, it is not possible to deprecate them.
That is why I asked to deprecate, but not obsolete..
However, I melieve browsers are making these dialogs tab-modal.
Yes I
On 11/25/2010 08:30 AM, ext Nils Dagsson Moskopp wrote:
Bijubijumaill...@gmail.com schrieb am Thu, 25 Nov 2010 02:29:31
1. Can we deprecate alert(), confirm(), prompt() ?
At present many web2.0 js libs are providing alternate [and cool
looking] methods to achieve use cases where we need to use
On Thu, Nov 25, 2010 at 8:26 AM, Benjamin Poulain
Although in my opinion, it would not make sense to deprecate without a good
alternative for modal dialogs.
But how many good sites use it.
Only place in GMail is when user try to send mail with no text in
Subject or Body field. Which they will
Am 25.11.2010 13:21 schrieb Biju:
On Thu, Nov 25, 2010 at 3:41 AM, a...@ashleysheridan.co.uk
a...@ashleysheridan.co.uk wrote:
Modal dialogues have a very special purpose, which works consistently across
various browsers in that we can program in with javascript some very
specific responses.
On Thu, Nov 25, 2010 at 1:45 PM, Markus Ernst derer...@gmx.ch wrote:
Maybe, instead of your original suggestion, it might be worth thinking about
making alert()/confirm()/prompt() dialogs styleable via CSS? Then those
fancy JS lib dialogs would get obsolete, and we had the favour of both nice
On Thu, Nov 25, 2010 at 8:45 AM, Markus Ernst
Maybe, instead of your original suggestion, it might be worth thinking about
making alert()/confirm()/prompt() dialogs styleable via CSS? Then those
fancy JS lib dialogs would get obsolete, and we had the favour of both nice
look and support for
On 25.11.2010 15:55, Biju wrote:
The request I put is NOT about whether you can make it PRETTY looking or not.
The question is about why we are allowing website have something which is MODAL
(ie, both window modal and tab modal
https://bugzilla.mozilla.org/show_bug.cgi?id=59314)
In my opinion
Am 25.11.2010 17:12 schrieb Nikita Popov:
On 25.11.2010 15:55, Biju wrote:
The request I put is NOT about whether you can make it PRETTY looking
or not.
Sorry, that was how I understood point 1 your initial message.
The question is about why we are allowing website have something which
is
On Thu, Nov 25, 2010 at 1:29 AM, Biju bijumaill...@gmail.com wrote:
1. Can we deprecate alert(), confirm(), prompt() ?
At present many web2.0 js libs are providing alternate [and cool
looking] methods to achieve use cases where we need to use alert(),
confirm(), prompt(). So do we need those
1. Can we deprecate alert(), confirm(), prompt() ?
At present many web2.0 js libs are providing alternate [and cool
looking] methods to achieve use cases where we need to use alert(),
confirm(), prompt(). So do we need those modal dialogs any longer?
2. if we are still keeping them, can we
Biju bijumaill...@gmail.com schrieb am Thu, 25 Nov 2010 02:29:31
-0400:
1. Can we deprecate alert(), confirm(), prompt() ?
At present many web2.0 js libs are providing alternate [and cool
looking] methods to achieve use cases where we need to use alert(),
confirm(), prompt(). So do we need
as well in as many cases as it may be required.
Thanks,
Ash
http://www.ashleysheridan.co.uk
- Reply message -
From: Biju bijumaill...@gmail.com
Date: Thu, Nov 25, 2010 06:29
Subject: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
To: whatwg wha...@whatwg.org
1. Can we deprecate
36 matches
Mail list logo
