Thanks Jacob!
On Fri, Aug 1, 2014 at 6:48 PM, Jacob S Hoffman-Andrews wrote:
> I think the CSP directive is unnecessary and makes things more fragile. The
> 'protect this credential from XSS' attribute should be a property of a
> stored credential, not a web site. If the site has the correct CSP
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26502
Bug ID: 26502
Summary: Need to define UIEvent or link to where it's
normatively defined
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
On Fri, Aug 1, 2014 at 8:39 AM, wrote:
> Spinner is not sufficient. All user activity must stop. They can take a
> coffee break if it takes too long. Browser must be frozen and locked down
> completely. No other options are desirable. All tabs, menus, etc. must be
> frozen. That is exactly
Your proposal decouples spec from implementation more than the
placeholder approach does, which is good.
I think the CSP directive is unnecessary and makes things more
fragile. The 'protect this credential from XSS' attribute should be
a property of a stored credential, not a web site. If the
If you use your tab key, you will discover that you will need to disable
all controls under your spinner to prevent user input completely. Kind of
a lot of work to get exactly the effect that sync requests do for you.
I find sync xmlhttprequests useful and you don't, it's clear. But instead
o
On 8/1/14, 9:39 AM, nmork_consult...@cusa.canon.com wrote:
All tabs, menus, etc. must be frozen.
Sync XHR doesn't do that.
-Boris
From: nmork_consult...@cusa.canon.com
Thank you for letting me know my input is not desired.
No, not at all. I think many engineers reading this list are truly delighted
to have seen your message. Some of us are also very sad, but I would argue
that all of us who have a good sense of humor are
On Aug 1, 2014 8:49 AM, wrote:
>
> Thank you for letting me know my input is not desired.
All input is definitely desired, but you seem to either not fully
understand what async XHR does, or are ascribing greater functionality to
sync XHR than it actually possesses. So far you have not described
On Aug 1, 2014 9:52 AM, wrote:
>
> Thank you for letting me know my input is not desired.
>
As Tab said, you can visually and functionally lock user input in your tab
and even provide a progress meter. Nothing you suggest is difficult with a
sync xhr and promises, and it's less hostile. How is th
On Fri, Aug 1, 2014 at 3:31 PM, Brian Smith wrote:
> There is some tension here between making things password-specific and
> simple vs. making them general and harder to understand. Defining this
> as a mechanism to protect only passwords keeps it simple. But, it
> seems wrong to have a way to p
Thank you for letting me know my input is not desired.
From: "Tab Atkins Jr."
To: nmork_consult...@cusa.canon.com,
Cc: public-webapps
Date: 08/01/2014 06:46 AM
Subject:Re: =[xhr]
On Aug 1, 2014 8:39 AM, wrote:
>
> Spinner is not sufficient. All user activity must sto
On Aug 1, 2014 8:39 AM, wrote:
>
> Spinner is not sufficient. All user activity must stop. They can take
a coffee break if it takes too long. Browser must be frozen and locked
down completely. No other options are desirable. All tabs, menus, etc.
must be frozen. That is exactly the desired
Spinner is not sufficient. All user activity must stop. They can take a
coffee break if it takes too long. Browser must be frozen and locked down
completely. No other options are desirable. All tabs, menus, etc. must
be frozen. That is exactly the desired result.
From: "Tab Atkins Jr
On Aug 1, 2014 8:16 AM, wrote:
>
> In this case, a freeze on all browser operations is desirable. The
thread cannot be interrupted, and if it is interrupted (by browser closure
or other such) then the transactions are immediately stopped and no update
will occur (this is the most desirable outcom
On Fri, Aug 1, 2014 at 5:37 AM, Mike West wrote:
> On Thu, Jul 31, 2014 at 6:37 PM, Brian Smith wrote:
>> particular, if we are worried about XSS stealing passwords then we
>> have to consider the possibility that XSS has inserted a form without
>> any httponly attributes being used, right?
>
> C
In this case, a freeze on all browser operations is desirable. The thread
cannot be interrupted, and if it is interrupted (by browser closure or
other such) then the transactions are immediately stopped and no update
will occur (this is the most desirable outcome.) Async is not desirable,
sin
Hi Mike,
On 31/07/2014 09:48 , Mike West wrote:
It's not clear to me that WebApps is the right venue from a process
perspective,
but this is almost certainly the right group of people to evaluate the
proposal.
Thanks in advance for your feedback, suggestions, and time. :)
As you know I think t
Forking this out into a separate thread, as I think it's a great idea, but
tangential to the original proposal. :)
TL;DR: I put together a strawman based on these suggestions which defines a
'writeonly' attribute on HTMLInputElement:
http://projects.mikewest.org/credentialmanagement/writeonly/, WD
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26493
Philip Jägenstedt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26493
Bug ID: 26493
Summary: Null dereference in exitFullscreen()
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26480
Anne changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
21 matches
Mail list logo
