Re: [webcomponents]: The Shadow DOM spec is under heavy refactoring.

[Anne van Kesteren]

On Thu, Jul 25, 2013 at 9:43 PM, Hayato Ito  wrote:
> I would like to announce that the editor's draft of the Shadow DOM spec
> (https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html)
> is now under heavy refactoring.
>
> The goal of the refactoring is to make the spec healthy, including the
> followings:
>
> - Use more formal definitions and notations.
> - Make sure that the model and data structures, accompanying algorithms are
> clearly defined.
> - Make the spec more compact.
>
> P.S. You can also see the original refactoring plan, which might be
> obsolete, but some of the parts are still useful to know the goal of the
> refactoring.
> (https://docs.google.com/document/d/1iuf2DgzwKfMTscAX_xsymO73NmZ4NVYvfyFgUU4YINo/edit?usp=sharing)

This sounds great. I'm not sure if this is still on your radar, but I
think eventually we want to move parts of this specification into DOM,
correct? So that the whole object model is defined somewhat coherently
in a single place. It would be good if the refactored style more
closely matched that of the DOM to make the integration go smoother
down the line.


-- 
http://annevankesteren.nl/

Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

[James Greene]

>
> AFAIK Flash shipped with a more liberal model first, but the abuse problem
> was considered significant enough to tighten the model and make it more
> restrictive.


That's correct:

   - In Flash 9, you could use the
`System.setClipboard`
   method to write to the user's clipboard without *ANY* user interaction
   whatsoever.
  - This led to some security uproar about malicious clipboard
poisoning,
  especially since many of the SWFs that people created passed the text to
  inject via URL params, thus allowing XSS attacks to easily inject into
  someone's clipboard just by requesting their SWF resource with the right
  URL params.
  - Unsurprisingly, the uptake in Flash-based ads were a huge
  contributor to the problem back then.

  - In Flash 10+, Adobe locked
downthe
`System.setClipboard` method and the [then] new `
   
flash.desktop.Clipboard`
   class a bit more such that clipboard interactions (including settings and
   clearing) could *ONLY* be performed as a *synchronous *operation
   immediately following a user's click or keyboard event.
  - This also means that you cannot use async XHRs for fetching the
  data to inject; while it is unfortunate to have to use sync XHRs instead,
  the synchronous flow is obviously very important for the security of the
  user's clipboard.


If you look at the Flash docs I've linked to, it's important to notice when
they differentiate between when the context of Adobe AIR (where there are
no such clipboard restrictions) and Adobe Flash Player (where there are).



Sincerely,
James Greene



On Fri, Jul 26, 2013 at 9:37 AM, Hallvord Steen  wrote:

> > leaving it up to the browser vendors WITHOUT an agreed upon
> > standard (or at least "marching direction") means zero progress.
>
> I'd argue that the spec gives a "marching direction", but I'd like to pass
> a simple question on to the implementors and the security/privacy experts
> around here:
>
> Should we allow document.execCommand('copy') on all sites by default?
>
> Pro arguments include: web apps and sites can offer "copy to clipboard"
> functionality without Flash hacks. We avoid reliance on yellow warnings,
> which seem destined to be used for so many APIs over time that the user
> will be annoyed and maybe start automatically clicking yes. It's probably
> good in general to reduce the number of separate privileges web authors
> need to worry about having or not having, by omitting privilege
> requirements for the less risky actions.
>
> Contra arguments include: being able to write to clipboard can be abused
> to cause nuisance, in that every page you load can overwrite what's on your
> clipboard. Such behaviour could and should be self-defeating for a web site
> that wants to have return visitors, but in this case it may be hard to
> figure out exactly which website caused the issue, since clipboard entry
> meta data like "originating URL" is normally not available to users. (One
> might imagine a site placing ad copy for some service on your clipboard,
> but the perceived nuisance, data loss and annoyance would make it a very
> poor ad channel indeed). AFAIK Flash shipped with a more liberal model
> first, but the abuse problem was considered significant enough to tighten
> the model and make it more restrictive.
>
>
> -Hallvord
>

[Bug 22809] 'error' progress event is never fired

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22809

Hallvord R. M. Steen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||hallv...@opera.com
 Resolution|--- |INVALID

--- Comment #1 from Hallvord R. M. Steen  ---
At this point in the algorithm, the word "event" (in italics) is a variable
that might be "error", "timeout" etc. Hence it does indeed sometimes indicate
that the error event fires.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [screen-orientation] Comments from Marcos

[Marcos Caceres]

On Friday, 26 July 2013 at 12:09, Arthur Barstow wrote:

> FYI, Marcos provided some comments on the latest Screen Orientation API 
> ED in .
> 
> Marcos - thanks for this. 
No probs :)  
> Is your expectation that followups on your 
> review are made in GH or WebApps' list? (My preference is the list, 
> unless there is some specific `Web Architecture` / TAG issue.)

The feedback will happen on this list, but first I was going to move everything 
to a document on GH. Alex said he might also provide some feedback (potentially 
also other TAG members!). I'm coordinating with Mounir a bit on the review and 
updating the spec. 

Once we have the text ready, the TAG will send it to public-webapps for 
discussion. Will take a few more days as about 1/3 of the TAG is at a TC39 
meeting.   

-- 
Marcos Caceres

[screen-orientation] Comments from Marcos

[Arthur Barstow]

FYI, Marcos provided some comments on the latest Screen Orientation API 
ED in .


Marcos - thanks for this. Is your expectation that followups on your 
review are made in GH or WebApps' list? (My preference is the list, 
unless there is some specific `Web Architecture` / TAG issue.)


-AB

[Bug 22809] New: 'error' progress event is never fired

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22809

Bug ID: 22809
   Summary: 'error' progress event is never fired
Classification: Unclassified
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: dch...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

The 'error' progress event (http://xhr.spec.whatwg.org/#event-xhr-error) is
never fired in the specification.

However, a progress event named 'event' is fired several times in these steps:
http://xhr.spec.whatwg.org/#request-error

I think this may be a typo and that event should be named 'error' not 'event'.

-- 
You are receiving this mail because:
You are on the CC list for the bug.