Re: [whatwg] [Workers] CSP and SharedWorkers
On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey m...@kylehuey.com wrote: Thoughts? What happens today for iframe? The load itself seems to be governed by the parent. Does the policy inherit into it? I feel like workers should work like iframe as they're essentially their own global objects. -- http://annevankesteren.nl/
Re: [whatwg] [Workers] CSP and SharedWorkers
The registration of a Service Worker is currently only possible via DOM call from an HTML document, so it makes sense for registration to be governed by CSP. There was some discussion here https://github.com/slightlyoff/ServiceWorker/issues/46 So script-src would cover registration, but there was also suggestion that x-domain controllers would be disallowed be default, and enabled by script-src or perhaps an additional controller-src CSP directive. Note, this only covers registration. If http://example.com allows controllers from http://example.co.uk, and successfully calls registerServiceWorker(/*, http://example.co.uk/service.js;), that controller will be used for all top-level fetches on http://example.com, and all fetches originating from documents on http://example.com, regardless of their CSP headers. The browser will re-fetch (ugrade) and continue to use http://example.co.uk/service.js even if the CSP rules are changed to disallow controllers from that url. But if a page attempts to register a new controller, the url must be allowed by CSP. Does script-src apply to importScripts in Workers currently? The spec doesn't explicitly mention it, feels like it should. I don't have a strong opinion on whether Workers should have their own CSP. Seems sensible for SharedWorkers to obey their own CSP headers and ignore those of the constructing/registering page (except for the actual constructing/registering of course). script-src should apply for importScripts and imported scripts would use the rules of the top-level SharedWorker. connect-src should also apply to fetch ( https://github.com/slightlyoff/ServiceWorker/blob/master/service_worker.ts#L193 ). On 26 September 2013 13:53, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey m...@kylehuey.com wrote: Thoughts? What happens today for iframe? The load itself seems to be governed by the parent. Does the policy inherit into it? I feel like workers should work like iframe as they're essentially their own global objects. -- http://annevankesteren.nl/
Re: [whatwg] [Workers] CSP and SharedWorkers
On 26 September 2013 14:57, Jake Archibald jaffathec...@gmail.com wrote: Note, this only covers registration. If http://example.com allows controllers from http://example.co.uk, and successfully calls registerServiceWorker(/*, http://example.co.uk/service.js;), that controller will be used for all top-level fetches on http://example.com, and all fetches originating from documents on http://example.com, regardless of their CSP headers. Oops, that's misleading, I mean the existing worker will be used for all fetches even if the CSP rule of the page has changed to disallow registering of that worker. The CSP of the page will still govern script loading, XHR etc. If the page's CSP disallows a resource from a particular URL, it won't consult the worker at all. If the page requests an allowed url, and the worker serves up a response (cached or otherwise) from a not-allowed url, CSP should block it. (apologies for saying controller when I mean service worker)
[whatwg] Supporting scanners on the web
One of the use cases that has come up for why people are still using plugins is supporting scanning to the web, in particular multi-page scanning. It seems to me that we could hook this up to input type=file multiple, but that we should try to provide UAs with a hint that a page expects a document instead of images. This primarily may affect whether/how the browser presents a scanner option to the user in addition to or instead of camera/photos when selecting an image. A couple questions I've thought about but don't have answers to: * Do/can PNG images contain information about their resolution, so that the site can reconstruct the actual page size? * Should we give the site any way to specify preferred resolution or color depth for an image? Or should the site be prepared process any images to the required resolution, convert to monochrome, etc. * Should the spec recommend any specific MIME types for scanner page images? Most desktop scanners appear to default to .tiff, but that's not a normal web format: perhaps we should recommend that UAs convert to PNG. --BDS
Re: [whatwg] Supporting scanners on the web
On Thu, Sep 26, 2013 at 11:19 AM, Benjamin Smedberg benja...@smedbergs.us wrote: One of the use cases that has come up for why people are still using plugins is supporting scanning to the web, in particular multi-page scanning. It seems to me that we could hook this up to input type=file multiple, but that we should try to provide UAs with a hint that a page expects a document instead of images. This primarily may affect whether/how the browser presents a scanner option to the user in addition to or instead of camera/photos when selecting an image. A couple questions I've thought about but don't have answers to: * Do/can PNG images contain information about their resolution, so that the site can reconstruct the actual page size? * Should we give the site any way to specify preferred resolution or color depth for an image? Or should the site be prepared process any images to the required resolution, convert to monochrome, etc. * Should the spec recommend any specific MIME types for scanner page images? Most desktop scanners appear to default to .tiff, but that's not a normal web format: perhaps we should recommend that UAs convert to PNG. So what do the plugins do here (pointers to the plugins?)? It seems if we want to replace these plugins, knowing what they do would be a great start. -- http://annevankesteren.nl/
Re: [whatwg] OUTPUT tag: clarify purpose in spec?
On Sun, 25 Aug 2013, Richard Kennard wrote: Thanks for all the great work you do on the HTML 5 specification! Can I ask for a little clarification in the spec? Specifically it says: The output element represents the result of a calculation or user action. http://www.w3.org/TR/html5/forms.html#the-output-element It is my understanding (or hope!) that the output tag fills a hole in form markup. For example, if this is the editable version of a form: label for=nameName:/labelinput id=name type=text value=Bob Then this can be its read-only variant: label for=name value=Name:output id=nameBob/output No, the readonly variant would be: label for=nameName:/labelinput id=name type=text value=Bob readonly Essentially, I am taking 'result of a calculation' to include 'values looked up from database, REST call, etc'. Is that correct? I guess. I meant more actual calculations rather than just lookups, but lookups can be the results of user action, so... There's a lot of output examples in the spec; do they help at all? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] OUTPUT tag: clarify purpose in spec?
2013-09-26 21:41, Ian Hickson wrote: There's a lot of output examples in the spec; do they help at all? There are indeed several examples, but they are scattered around; the section that specifically deals with the output element, 4.10.15, has only one example. It is a simple calculator that shows the calculated result in an output element. And it is a form with no action attribute and with onsubmit=return false, so it is clearly meant to work in the browser only. That is, the value of the output element is not submitted. The question then arises why output is used, instead of just showing the result in a span or div element as usual. In fact, none of the examples about output have no apparent association with any submission to server-side processing. Yet, the from the properties defined for output, whole point seems to be that the output element has a special purpose: it is a control, with a value that may be included in form data upon submission, but its value is not meant to be changed by the user directly, only via actions that may indirectly modify it. Simultaneously, it is normally visible to the user. As I see it, the difference between output and a readonly input is that the latter is not meant to be changed by the user *at all*, whereas output is not be changed *directly*. If this interpretation is correct, I think some of it should be somehow expressed in the spec, and there should be at least one example where output is seemingly participating in form data submission. It's of course too late to change the name output now, but it is really misleading, since it suggests that the element is just for output (possibly even suggesting that it's really a duplicate of samp!). Yet it seems that it primarily computed data (in a broad sense for computed) to be submitted, though it can, like input, be used without submission too. So computed or input type=computed might have been better. I mention this because this name problem emphasizes the need for explaining what the element is really for. I still don't quite see *why* output has been introduced. I can understand it as a purely logical creation, but what is the practical gain expected to be? Yucca
Re: [whatwg] Comments on dialog
On Mon, 26 Aug 2013, Matt Falkenhagen wrote: On Thu, Aug 22, 2013 at 7:58 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 22 Apr 2013, Tab Atkins Jr. wrote: On Mon, Apr 22, 2013 at 12:38 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 22 Apr 2013, Matt Falkenhagen wrote: 3. For centering in the viewport, the spec mandates that the used value of 'top' be specially calculated. I found it more convenient to implement by mutating the computed value rather than the used value. This has the added benefit that it's straightforward for the page author to implement dragging using getComputedStyle. The computed value can't rely on layout, since it's used for inheritance, which can happen without layout, if I'm not mistaken. Matt means that we, the browser, explicitly set the computed value to whatever's appropriate, based on layout values at the time that .show() is called. (Done either by setting values in the override stylesheet, or by manipulating the style attribute on the element. Probably the latter, because there's no guarantee we can uniquely target the dialog via a selector.) I don't really think this makes any sense. For example, it wouldn't handle viewport video changes as it's currently described. The way the spec is defined now, it's the static position that is set -- the 'top' property is unaffected except indirectly by its dependency on the static position. What's wrong with that? Can you elaborate on what viewport video changes are and what the problem is? I think I meant viewport width changes, sorry. As in, when you resize the viewport, it would either fail to move the dialog, or it would override the user's move, depending on how we implemented this, without the author really being able to do anything about it. The way the spec is written now, you can still trivially implement dragging; you just set 'top' appropriately based on the element's position. Then, onresize or whenever you want to revert to the default position, you remove the 'top' property. It all just works. I don't really see the problem here. It may not be a strong reason to change the spec, but in my experience, implementing this in terms of static position in WebKit/Blink was very challenging. As an example of the challenge, normally static position is computed for a box during its layout, which is too early for dialog: the dialog's dimensions must be known in order to center it, so it must have been laid out already. How does this differ from, e.g., computing 'auto' margins of shrink-wrapped blocks? Changing the static position after layout breaks much assumptions in the code and would seem to require invasive work across the render tree, layer tree, possibly painting, etc. In contrast, if CSS is manipulated after the first layout pass, the layout engine just works. So I found it convenient and stable to mutate CSS 'top' directly. I don't think mutating attributes is a sane approach to doing this. It feels like a hack, it interferes with author affordances, it makes it harder for us to distinguish script-set property values from UA-set property values, it makes it harder for authors to specifically override the UA, etc. That said there have been some spec changes since my last attempt that may make this easier, such as the dialog's cb is the icb. That also means you can just use offsetTop/Left to implement dragging so perhaps it's no longer helpful for getComputedStyle to return the centered top. Please do let me know if it is too difficult with the static position as defined. We could maybe consider other options like having a special computed value just for 'top', etc, the way we do for 'position'. On Tue, 27 Aug 2013, Ian Hickson wrote: On Mon, 26 Aug 2013, Ryosuke Niwa wrote: On Apr 22, 2013, at 12:38 PM, Ian Hickson i...@hixie.ch wrote: The current naming is based on window.showModalDialog() and window.close(). I agree the naming is weird, but being consistent is probably going to be more helpful on the long run. But that's because we have window.open but not an equivalent of window.close for window.showModalDialog, right? It seems more consistent to use show/hide or open/close as Matt suggested. Consistent with what? We have window.open()/window.close, and window.showModalDialog()/window.close(). We also have document.open()/document.close(), and so on (EventSource, etc). I suppose we could change show() to open(), but then we'd be inconsistent with showModalDialog() for openModal()... On Mon, 26 Aug 2013, Ojan Vafai wrote: IMO, showModalDialog is the legacy broken API we're stuck with. Better to name the new thing in a way that's self-consistent and consistent with everything else (i.e. openModal). I started doing this, since several people have asked about this and it seems the consistency between showModalDialog()/close() seems less
Re: [whatwg] Elements should be removed from the past names map once it's no longer associated with the form element
On Mon, 26 Aug 2013, Ryosuke Niwa wrote: I propose to change the specification to remove any elements that are no longer associated with the form from the past names map: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#past-names-map It's strange for elements to linger around forever in the past names map after the element get associated with a new form element. Since IE didn't support form attribute for a long time (or maybe still hasn't?), I don't think there is any compatibility concern. The change makes the elements associated with the form element more consistent and easier to reason about. We can make form[x].form === form an invariant for every x such that form[x] is a form control element. This was fixed in response to: On Mon, 26 Aug 2013, Boris Zbarsky wrote: I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23073 Let me know if there's still something to fix here. Note that there's no need to file a bug if feedback on the spec is sent to the list; I treat them both as input to the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canonical Image and Color
On Wed, 28 Aug 2013, Brian Blakely wrote: On Fri, Jul 12, 2013 at 1:32 PM, Ian Hickson i...@hixie.ch wrote: You are welcome to register these on the wiki and convince people to use them, sure. Would you kindly link me to the wiki? http://wiki.whatwg.org/wiki/MetaExtensions -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Notifications: usage feedback
This Notifications feedback comes from using them in FirefoxOS for the
email web app. It uses an alarm API to periodically wake up, do an
email sync, and if new messages, creates some Notifications. The web
app may also shut itself down if it was not already opened in a
visible state. The OS may also decide to kill it to use the memory for
some other app.
1) Ability to pass data with the Notification
Right now, we URL-encode some args to the iconURL to pass data to the
handler function that is registered via
navigator.mozSetMessageHandler('notification', function(){}) [1].
It would be better if I could just pass a JSON-friendly data object to
Notification instance and then have access to that data in the
notification callbacks that are triggered.
We cannot depend on notification.onclick to work since the app can be
closed after the notification is fired. It also seemed very unreliable
to depend on it, given garbage collection possibilities. So we cannot
reliably capture state using a function closure.
2) General notification callback entry point
We are avoiding use of notification.onclick/onclose and would prefer
to have a generic entry point to receive notification events. Right
now we use navigator.mozSetMessageHandler('notification',
function(){}).
but I would prefer to see a more official entry point in the spec. I
would go so far as to want to deprecate the .onclick and .onclose as
in practice they are not reliable, given that the app may be closed
down after firing the Notification but before it is clicked.
3) onclick fires onclose too?
It seemed a bit unclear in the spec, but right now FirefoxOS fires
onclose too for onclick actions, as the onclick pathway removes the
notification from the list of notifications.
This seems counterintuitive to me, I would have only expected one
event. Perhaps clarifying the onclick behavior would be good.
I would prefer to just see one event fired in this case, if
onclick/onclose are kept around. If the general notification callback
entry point is established, then just firing it once with the
event.clicked property set to true for the clicked route.
4) onclick does not bring web app to front
This may be part of just further defining the steps for the click
pathway in the spec, but at least in FirefoxOS right now, the
notification onclick pathway does not bring the app to the visible
front in all cases. The email app has to do some extra document.hidden
checking and try to bring itself to the front.
What I would rather see is by default the web page is brought to the
visible front, and then perhaps allow the app a way to cancel that
behavior perhaps via a preventDefault() type of mechanism on any
notification click event.
This would also reduce the need for an API that the app could call to
bring itself to the visible front. Right now, there is an
app.launch() API in FirefoxOS for this, but there are concerns that
giving apps the ability to launch themselves to the front could lead
to an abuse of that API.
5) Ability to set notification modes.
This one is a bit less defined. I would rather this one is discarded
than spending too much time on it if it meant losing track of the
points above:
For email notifications, we did not necessarily want the phone to
light up the screen on every notification and make a sound or vibrate
(particularly at night), but rather just register the notification and
have it show up in the notification count and listing.
While ideally there is UI for the user to control notification
behavior for all web apps, I can also see the case for allowing
notifications the ability to opt in to the notification modes it
prefers.
Any user settings would override the modes specified in the
notification, but for apps that did want to be nice, it would be a way
to avoid a very annoying first notification behavior, in the case of
email, not disturbing the user unless they did an explicit override.
This may be too tricky to specify, but I started a bugzilla bug for
FirefoxOS for this[2]. One suggestion was listing the preferred modes
in the web app manifest, but I can see an app may have different types
of notifications, so it would be more flexible to set per Notification
instance.
There is a dev-gaia thread[3] that prompted this feedback.
[1]
https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozSetMessageHandler
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=912645
[3] https://groups.google.com/forum/#!topic/mozilla.dev.gaia/NVacmcxGt2Q
James
Re: [whatwg] Supporting scanners on the web
On Fri, Sep 27, 2013 at 3:19 AM, Benjamin Smedberg benja...@smedbergs.uswrote: A couple questions I've thought about but don't have answers to: * Do/can PNG images contain information about their resolution, so that the site can reconstruct the actual page size? Yes: http://www.scantips.com/basics9p.html * Should we give the site any way to specify preferred resolution or color depth for an image? Or should the site be prepared process any images to the required resolution, convert to monochrome, etc. That sounds useful. These values could be just hints. * Should the spec recommend any specific MIME types for scanner page images? Most desktop scanners appear to default to .tiff, but that's not a normal web format: perhaps we should recommend that UAs convert to PNG. PNG sounds good given it's lossless and ubiqutious. Apps can transcode to JPEG (or any other format the browser supports encoding of) on the client if they want to. Is implementing a full scanning UI in a Web app in scope or out of scope? If it's in scope, then we'd need the ability to display incremental scan results, and we'd need to be able to do a preview vs full-view scan, and control the area scanned. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] [Workers] CSP and SharedWorkers
On Wed, Sep 25, 2013 at 8:00 PM, Kyle Huey m...@kylehuey.com wrote: It's unclear how SharedWorkers should interact with Content Security Policies. This came up during code review of the SharedWorker implementation in Gecko[0]. There was a public-webappsec thread[1] on this back in May that didn't really reach a conclusion and I'd like to drive towards one here. For both Shared Workers and Service Workers is seems pretty clear that we can't inherit the policy of the loading document. Any such constructs would feel non-sensical in too many situations. So here I think we should let the worker get its CSP from the script load itself. With Dedicated Workers we could in theory inherit the policy of loading document, but it feels like that creates a lot of inconsistency with Shared/Service Workers. So my off-the-top-of-my-head suggestion would be to always let workers get the CSP from the script load. Though one question is what to do for workers loaded from blob:, data: or filesystem:. Maybe we should disallow shared/service workers from those types of URLs, and make dedicated workers inherit the CSP when loaded from those URLs. Though I could see shared workers from filesystem: being useful. What do implementations do with regards to linking script to blob/data/filesystem? Are they treated like normal protocols, or are they treated like eval()? If they are treated like normal protocols then maybe we can simply not have any special rules for them and say that for now they never get a CSP. I don't have strong feelings about whether or not we should deny a page with a more liberal CSP from connecting to a SharedWorker with a more strict CSP, but I suspect others might. What do we do for iframes here. If nothing then I don't think we should do anything for workers either. / Jonas
Re: [whatwg] Supporting scanners on the web
On Thu, Sep 26, 2013 at 8:19 AM, Benjamin Smedberg benja...@smedbergs.us wrote: One of the use cases that has come up for why people are still using plugins is supporting scanning to the web, in particular multi-page scanning. It seems to me that we could hook this up to input type=file multiple, but that we should try to provide UAs with a hint that a page expects a document instead of images. What we've done in Firefox for Android is to treat input type=file accept=image/* as a hint that the page wants an image any source. So we give the user options to use any built-in gallery or camera apps for example. We could do the same on desktop platforms and display an additional button next to the normal select file button if we detected that there are additional image sources like cameras or scanners available. There's also been proposals around input type=file accept=image/* capture. This was supposed to mean invoke media specific capturing methods. I think there was also something like input type=file capture=camera being proposed which would specifically enable camera-backed capturing. * Should we give the site any way to specify preferred resolution or color depth for an image? Or should the site be prepared process any images to the required resolution, convert to monochrome, etc. The most requested ability is to resize images to a particular resolution. This is something that can be done using canvas, but not for videos or animated images. And currently you can't do it off the main thread, which is an issue for larger images. It would be nice to expose a image-resize API to the web. This way they could do things like resize images to the various sizes needed and just upload the resized images. Currently you have to upload the fullsized image, or you have to resize once to the maximum size you want and upload that, and then resize again on the server. But that results in lower image quality. Likewise it would be nice to have an API for re-encoding images without using canvas. This will likely be especially important if we decide on a jpeg successor to add support for. * Should the spec recommend any specific MIME types for scanner page images? Most desktop scanners appear to default to .tiff, but that's not a normal web format: perhaps we should recommend that UAs convert to PNG. Yes, definitely. / Jonas
Re: [whatwg] Supporting scanners on the web
On Fri, Sep 27, 2013 at 5:29 PM, Jonas Sicking jo...@sicking.cc wrote: The most requested ability is to resize images to a particular resolution. This is something that can be done using canvas, but not for videos or animated images. And currently you can't do it off the main thread, which is an issue for larger images. You can actually. You can draw the image to an offscreen canvas, scaling it, and then call toBlob() on the canvas, which is async. Nothing forces the image drawing and scaling part of that process to be sync. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
