Re: Intent to implement: File system provider API

On Sat, Jul 25, 2015 at 7:14 AM, Kershaw Chang wrote: > Since the addon model on Firefox OS is not implemented now, I still use the > old term "apps" in previous mail. > I also think it makes much more sense to make this API to be only available > for addons. Great! > In addition, do we have a w

Re: Proposed W3C Charters: All Groups, XML Activity

On Fri, Jul 24, 2015 at 2:23 PM, L. David Baron wrote: > # It's disappointing to see the W3C putting this much effort into XML work > # that is not related to the needs of the Web. We don't support this > # work, and would rather see the resources going into it going into things > # that would hel

Re: Intent to implement: File system provider API

On Fri, Jul 24, 2015 at 3:49 AM, David Rajchenbach-Teller wrote: > On 24/07/15 11:38, Jonas Sicking wrote: >> I think we should allow addons to implement something like this. But I >> don't think it's something that we should let apps do. >> >> / Jonas >

Re: Intent to implement: File system provider API

I think we should allow addons to implement something like this. But I don't think it's something that we should let apps do. / Jonas On Fri, Jul 24, 2015 at 1:13 AM, Kershaw Chang wrote: > Hi all, > > Summary: > File system provider API [1] is now supported by Google. This API allows > develope

Re: Hash table iterators, and a call for help

On Fri, Jul 24, 2015 at 1:59 AM, Nicholas Nethercote wrote: > On Fri, Jul 24, 2015 at 5:45 PM, Jonas Sicking wrote: >> On Thu, Jul 23, 2015 at 10:16 PM, Nicholas Nethercote >> wrote: >>> I wonder if converting all the uses of PLHashTable into PLDHashTable >>> w

Re: Hash table iterators, and a call for help

On Thu, Jul 23, 2015 at 10:16 PM, Nicholas Nethercote wrote: > I wonder if converting all the uses of PLHashTable into PLDHashTable > would instead be a better approach. Yes please! Though IIRC they are have different performance characteristics, which might make that challenging in some cases.

Re: Proposed W3C Charters: All Groups, XML Activity

On Thu, Jul 23, 2015 at 3:43 PM, L. David Baron wrote: > I'm not sure it's really a fight I want to take on right now, > though. Trying to kill things at W3C has generally not seemed worth the effort to me. It's better to ignore it and let it die out by itself due to lack of attention. But being

Re: [WebAPI] New Proposal of IMS Registration Manager

On Wed, Jul 22, 2015 at 3:38 AM, Bevis Tseng wrote: > To prevent exposing too much in the web api level unnecessarily, > instead of creating new attribute in Navigator.webidl, > we could define the ImsHandler as one attribute of MozMobileConnection and > remove mozImsManager from Navigator, since

Re: [WebAPI] New Proposal of IMS Registration Manager

On Wed, Jul 22, 2015 at 1:57 AM, Martin Thomson wrote: > I think that building these sorts of features into the web platform at > large is a very bad idea. I assume that this API is only going to be exposed to "certified apps". Effectively that means that it's no more exposed to the web than any

Re: Intent to implement HTMLMediaElement.srcObject partially

On Mon, Jul 20, 2015 at 12:27 AM, Robert O'Callahan wrote: > On Mon, Jul 20, 2015 at 6:33 PM, Jonas Sicking wrote: >> >> Good point. We also need to call >> URL.revokeObjectURL(this.mOldObjectURL); in the .src setter and in the >> dtor. > > > OK, but we s

Re: Intent to implement HTMLMediaElement.srcObject partially

On Sun, Jul 19, 2015 at 2:45 PM, Robert O'Callahan wrote: > On Thu, Jul 16, 2015 at 5:09 PM, Jonas Sicking wrote: >> >> On Wed, Jul 15, 2015 at 12:42 PM, Jan-Ivar Bruaroey >> wrote: >> > This means it will throw TypeError on set of: MediaSource objects, Blob

Re: Implement Fetch?

on anyones backlog. If you're interested, let me know and I'd be happy to point you to the parts that's needed to archive that specifically. / Jonas > Cheers, > David > > > On 17/07/15 22:24, Jonas Sicking wrote: >> I don't think the problem here is comin

Re: Implement Fetch?

I don't think the problem here is coming up with an architecture, but rather having time to implement it. I think many of the specs you mention would be a lot easier if we implemented the "Hooks for security policies" proposal from [1]. There's already work going on for implementing the "New API f

Re: Intent to implement HTMLMediaElement.srcObject partially

On Wed, Jul 15, 2015 at 12:42 PM, Jan-Ivar Bruaroey wrote: > This means it will throw TypeError on set of: MediaSource objects, Blob > objects, and File objects, for now. For what it's worth, I think implementing Blob/File support would be quite trivial. Just make elem.srcObject = blob; interna

Re: Intent to implement W3C Manifest for web application

On Tue, Jul 14, 2015 at 3:00 PM, wrote: > > Some of the things raised: > > * It's not clear what problems manifest solves: do we really want to > replicate "native app" installation behavior on the Web? We don't have a good > history of making this work in various products. > * Extra HTTP req

Re: Busy indicator API

I think an API like: window.navigator.addBusyTask(promise); would be great. The API can be called any time and any number of times. The API would run the spinner until all provided promises are resolved. So if it's called twice with different promises, the spinner doesn't stop when one of the pro

Re: Linked Data must die. (was: Linked Data and a new Browser API event)

I'd definitely like to keep the implementation of whatever formats we use in Gaia given that this is still an experimental feature and the use cases are likely to evolve as we get user feedback. It seems to me that given that our use case here, beyond OG, is only our "internal" content, I.e. Gaia.

Re: Intent to migrate the permissions database to use origins instead of host names

On Tue, Jun 30, 2015 at 5:50 PM, Jonas Sicking wrote: > On Tue, Jun 30, 2015 at 4:16 PM, Ehsan Akhgari > wrote: >> On 2015-06-30 6:04 PM, Jonas Sicking wrote: >>> >>> There are actually one downside with this change. >>> >>> It means that if a

Re: Intent to migrate the permissions database to use origins instead of host names

On Tue, Jun 30, 2015 at 3:55 PM, Martin Thomson wrote: > I wonder, has the subject of double-keying been raised in this > context? It comes up frequently in this context. And when I say > double-keying, I mean forming a key from the tuple of the requesting > principal and the top level browsing c

Re: Intent to migrate the permissions database to use origins instead of host names

On Tue, Jun 30, 2015 at 4:16 PM, Ehsan Akhgari wrote: > On 2015-06-30 6:04 PM, Jonas Sicking wrote: >> >> There are actually one downside with this change. >> >> It means that if a user denies access to https://website.com to use >> cookies, then http://website.co

Re: Intent to migrate the permissions database to use origins instead of host names

There are actually one downside with this change. It means that if a user denies access to https://website.com to use cookies, then http://website.com will still have full ability to use cookies since it's a different origin. For a DENY policy it often makes more sense to deny a whole domain name

Re: Linked Data and a new Browser API event

On Fri, Jun 26, 2015 at 5:37 PM, Benjamin Francis wrote: > On 26 June 2015 at 08:00, Anne van Kesteren wrote: >> >> Is the idea to just keep adding events for each bit of >> information we might need from a document? > > That is how the Browser API works. I don't think that we should be terribly

Re: Linked Data and a new Browser API event

On Thu, Jun 25, 2015 at 7:19 PM, Benjamin Francis wrote: > and JSON-LD (because it supports Gaia's more complex use cases). Hi Ben, My only concern here is that if you pin a contact, it seems to me that it would be good if the name and picture of that homescreen UI should be quickly updated if t

Re: Browser API: iframe.executeScript()

On Wed, Jun 17, 2015 at 12:02 AM, Tim Guan-tin Chien wrote: > How about the risk of having API users intentionally creating local > APIs? For example, people can implement support for apple-touch-icon> just in Gaia. > > I was told this is a concern back in B2G v1.0. I think that's fine. It's def

Re: Browser API: iframe.executeScript()

On Tue, Jun 16, 2015 at 10:33 AM, Bobby Holley wrote: > On Tue, Jun 16, 2015 at 10:06 AM, Paul Rouget wrote: > >> What would be the right approach to allow such a feature? >> Would adding a new permission help? >> > Well, it sorta depends on what you're trying to accomplish. browser.html is > sup

Re: Browser API: iframe.executeScript()

On Tue, Jun 16, 2015 at 9:08 AM, Bobby Holley wrote: > Do privileged and certified apps currently have the ability to perform > universal XSS? Because this would give them that, certainly. The Browser API runs content in a separate cookie jar. That means that the browser API from a security point

Re: Voting in BMO

On Fri, Jun 12, 2015 at 3:49 AM, Ehsan Akhgari wrote: > On 2015-06-11 2:51 PM, Jared Wein wrote: >> >> DevTools does something like this with UserVoice. I don't think we should >> get rid of voting unless we replace it with something else (UserVoice is a >> good alternative). >> >> There are plent

Re: Intent to remove: support for old drag events

On Wed, Jun 10, 2015 at 12:35 PM, Ehsan Akhgari wrote: > On 2015-06-09 10:17 AM, Neil Deakin wrote: >> >> In bug 1162050, we'd like to remove support for the old non-standard >> drag events, which were left in for a period of compatibility. > > This is great! I agree it's great if we can remove t

Re: The War on Warnings

On Thu, Jun 4, 2015 at 5:38 AM, Robert O'Callahan wrote: > Usually I use NS_WARNING to mean "something weird and unexpected is > happening, e.g. a bug in Web page code, but not necessarily a browser bug". > Sometimes I get useful hints from NS_WARNING spew leading up to a serious > failure. Yup.

Re: The War on Warnings

FWIW, I suspect it'll be hard to put a dent in the number of warnings that we emit unless we either change all instances of NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn, or unless we change NS_ENSURE_SUCCESS(rv, rv) to not warn. It feels like right now we have three incompa

Re: Linked Data and a new Browser API event

On Mon, Jun 1, 2015 at 4:31 PM, Anne van Kesteren wrote: > On Sun, May 31, 2015 at 5:09 AM, Jonas Sicking wrote: >> We should use whatever formats people are using to mark up pages. If that is >> microdata we should use that. If it's RDF we should use that. If its JSONLD &

Re: Linked Data and a new Browser API event

We should use whatever formats people are using to mark up pages. If that is microdata we should use that. If it's RDF we should use that. If its JSONLD we should use that. The API that is used to extract the data is irrelevant. That will be an internal API anyway. Effectively we should think of t

Re: Using rust in Gecko. rust-url compatibility

On Tue, May 5, 2015 at 7:10 PM, Valentin Gosu wrote: > On 6 May 2015 at 04:58, Doug Turner wrote: >> > On May 5, 2015, at 12:55 PM, Jonas Sicking wrote: >> > >> > On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu >> > wrote: >> >> As some of you

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

On Wed, May 6, 2015 at 10:08 AM, Anne van Kesteren wrote: > On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari wrote: >> * Restricting this API to resources loaded from a secure origin also doesn't >> help in any way in practice. It doesn't address your original concern _at >> all_ (since your malici

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

On Wed, May 6, 2015 at 8:42 AM, Doug Turner wrote: > >> On May 6, 2015, at 7:30 AM, Tantek Çelik wrote: >> >> >> Not pure vandalism. The user data loss is a side-effect of other incentives. >> >> E.g. trivial "attacker" incentive: all those share-button-happy >> news/media sites are likely to aut

Re: Is there an e10s plan for multiple content processes?

On Tue, May 5, 2015 at 4:34 PM, Nicholas Nethercote wrote: > On Wed, May 6, 2015 at 2:12 AM, Bill McCloskey wrote: >> >> Regarding process-per-core or process-per-domain or whatever, I just want >> to point out that responsiveness will improve even beyond process-per-core. > > You're probably rig

Re: Using rust in Gecko. rust-url compatibility

On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu wrote: > As some of you may know, Rust is approaching its 1.0 release in a couple of > weeks. One of the major goals for Rust is using a rust library in Gecko. > The specific one I'm working at the moment is adding rust-url as a safer > alternative to

Re: Is there an e10s plan for multiple content processes?

On Tue, May 5, 2015 at 12:42 AM, Nicholas Nethercote wrote: > On Mon, May 4, 2015 at 11:53 PM, Leman Bennett (Omega X) > wrote: >> >> I heard that there was rumor of a plan to limit process count spawn to >> per-domain. But I've not seen offhand of a bug filed for it or anything else >> that rela

Re: ES6 features (let, yield) and DOM workers and B2G

On Wed, Apr 29, 2015 at 9:05 AM, Andrew Sutherland wrote: > E) B2G-Specific: > E1) Set "dom.workers.latestJSVersion" for only B2G's trunk, which has no > releases planned for the foreseeable future. This feels like painting ourselves into a corner. > E2) On B2G have certified apps get JSVERSION_

Re: ES6 features (let, yield) and DOM workers and B2G

On Wed, Apr 29, 2015 at 9:05 AM, Andrew Sutherland wrote: > > A) The JS concept of versions goes away, at least for web content and ES6 > features (in the next few weeks). This covers things like > https://bugzil.la/855665 on making let work without requiring JS 1.7. I think this is the right so

Re: RFC: Navigation transitions

On Tue, Apr 28, 2015 at 6:49 AM, Christopher Lord wrote: > > > On Tue, Apr 28, 2015 at 4:26 AM, Jonas Sicking wrote: >> >> This is awesome!! I completely agree that the Google proposal is much >> too complicated for an initial take on solving transitions. >> >

Re: RFC: Navigation transitions

This is awesome!! I completely agree that the Google proposal is much too complicated for an initial take on solving transitions. I agree with Anne that this should be doable by adding CSS rules to a normal stylesheet rather than using a special linking mechanism. If that sounds good to you, then

Re: Intent to implement: Frame Timing API

Please make sure to do a security review so that this doesn't expose any sensitive information accidentally. In particular, is there any way to use this API to use :visited hacks along with timing information to see if a user has visited a particular URL? / Jonas On Mon, Apr 27, 2015 at 2:27 AM,

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On Fri, Apr 10, 2015 at 7:15 PM, Boris Zbarsky wrote: > On 4/10/15 7:43 PM, Jonas Sicking wrote: >> >> One option is to make the xpidl interface always return a File, but >> make the .webidl interface return files or blobs. > > Why, exactly? If we want to do this, j

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On Fri, Apr 10, 2015 at 4:31 PM, Boris Zbarsky wrote: > On 4/10/15 6:23 PM, Jonas Sicking wrote: >> >> Is there a reason to upgrade to File? > > Yes. FileList claims to return Files. > > We could change that to have it return Blobs, of course, and then make sure &

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On Fri, Apr 10, 2015 at 11:24 AM, Boris Zbarsky wrote: > 1) The setter treats its single argument as a sequence. Any Blobs > that are not already Files get upgraded to Files, identical to how > https://xhr.spec.whatwg.org/#create-an-entry behaves. Is there a reason to upgrade to File? I thought

Re: IndexedDB transactions are no longer durable by default, and other changes

On Sat, Apr 4, 2015 at 3:15 PM, Gian-Carlo Pascutto wrote: > On 4/04/2015 12:22, Jonas Sicking wrote: > >> I tried to explain this, but I don't think it was particularly clear. >> >> Once the "complete" event has fired, the data has been completely >&

Re: IndexedDB transactions are no longer durable by default, and other changes

On Fri, Apr 3, 2015 at 11:47 PM, Gian-Carlo Pascutto wrote: > >> The IndexedDB API does not currently have a way to say "no, really, I >> want to make sure that this important data is saved to disk before I >> continue". > > Do our internal APIs offer this? > > Android can kill Firefox at any time

Re: PSA: Upcoming changes to the creation of Necko channels

On Fri, Apr 3, 2015 at 4:27 AM, Ehsan Akhgari wrote: > Next week, I'm planning to land the patches to bug 1149853 which enables > Gecko to track which RequestContext [1] a network fetch is being performed > for. > > This will enable us to correctly signal the context for which a given > request wa

Re: IndexedDB transactions are no longer durable by default, and other changes

On Thu, Apr 2, 2015 at 9:19 PM, ben turner (bent) wrote: > On Wednesday, April 1, 2015 at 6:26:04 PM UTC-7, Jonas Sicking wrote: >> This might match what you are saying. > > Yep! > >> My understanding is that at that point both the >> child and the parent can crash

Re: IndexedDB transactions are no longer durable by default, and other changes

On Thu, Apr 2, 2015 at 3:00 AM, ben turner (bent) wrote: > On Wednesday, April 1, 2015 at 2:12:40 PM UTC-7, somb...@gmail.com wrote: >> - Crash-wise, are we talking about only the parent process crashing, or >> are we talking about the child process crashing too? > > I was talking just about the p

Re: [meta] "Intent to implement" - captured some docs on wikimo

intent to ..." should > go to dev-platform to provide direction should anything actually go > out of date and someone is potentially confused. > > Thanks, > > Tantek > > On Tue, Mar 31, 2015 at 3:10 PM, Jonas Sicking wrote: >> Will someone be maintaining this pag

Re: [meta] "Intent to implement" - captured some docs on wikimo

Will someone be maintaining this page? I'm worried that having an out-of-date page might create more confusion than information. / Jonas On Tue, Mar 31, 2015 at 3:58 AM, Tantek Çelik wrote: > Having followed the "Intent to implement" emails for a while, and > noticing that there was already an e

Re: Intent to implement and ship: document.origin

>>> I think it would be weird if the >>> invariants that hold for and new URL() don't hold for Location. >> >> That's already the case for tons of invariants. > > I don't think so. The various component attributes all return what you'd > expect. I still think the value added by making window.loc

Re: Intent to implement and ship: document.origin

Pinging this old thread since nothing seems to have happened since it was last discussed. My recommendation is still to make location.origin return the "origin of the document" rather than "the origin of the URL". I would be surprised if that didn't fix many more pages than it broke. I think maki

Re: Intent to deprecate: persistent permissions over HTTP

On Fri, Mar 6, 2015 at 10:12 AM, wrote: >> >> You might say that having a local network attacker able to see what >> your webcam is looking at is not scary, but I'm going to disagree. >> Also c.f. RFC 7258. > > I asked for something very specific: popups. What is the threat model for the > popup

Re: Permission UI

On Tue, Mar 3, 2015 at 11:36 PM, Anne van Kesteren wrote: > On Wed, Mar 4, 2015 at 12:48 AM, Justin Dolske wrote: >> I don't actually think about:permissions is a good start, or that it's >> implemented "most of the complicated bits." Quite the opposite, really: it >> was a useful experiment, but

Re: [dev-servo] UI Workers

On Mon, Feb 23, 2015 at 4:26 PM, Jonas Sicking wrote: > On Mon, Feb 23, 2015 at 4:01 PM, Robert O'Callahan > wrote: >> On Tue, Feb 24, 2015 at 12:09 PM, Jonas Sicking wrote: >>> >>> I think this would fall over more often than not. >>> >>

Re: [dev-servo] UI Workers

On Mon, Feb 23, 2015 at 4:01 PM, Robert O'Callahan wrote: > On Tue, Feb 24, 2015 at 12:09 PM, Jonas Sicking wrote: >> >> I think this would fall over more often than not. >> >> Most developers will not write their code to be resilient in the face >> of b

Re: [dev-servo] UI Workers

On Mon, Feb 23, 2015 at 3:02 PM, Robert O'Callahan wrote: > On Tue, Feb 24, 2015 at 10:57 AM, Gordon Brander > wrote: >> >> It's funny: I have come to the opposite conclusion for the same reason. >> >> The Good: getting 60fps interactions and animations in web apps using a >> proven approach (UI

Re: [dev-servo] UI Workers

On Mon, Feb 23, 2015 at 12:07 PM, Robert O'Callahan wrote: > On Tue, Feb 24, 2015 at 8:56 AM, Jonas Sicking wrote: >> >> On Mon, Feb 23, 2015 at 10:56 AM, Gavin Sharp >> wrote: >> > What does it mean to "save your for later viewing"? >> >

Re: [dev-servo] UI Workers

a sense, broad adoption is what we *should* hope for with most platform features that we implement. / Jonas > On Mon, Feb 23, 2015 at 10:36 AM, Jonas Sicking wrote: >> On Sun, Feb 22, 2015 at 3:45 AM, Robert O'Callahan >> wrote: >>> On Fri, Feb 20, 2015 at 9:11 PM, Jon

Re: UI Workers

On Sun, Feb 22, 2015 at 3:45 AM, Robert O'Callahan wrote: > On Fri, Feb 20, 2015 at 9:11 PM, Jonas Sicking wrote: >> >> On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan >> wrote: >> > Should UIWorkers have access to the full Worker API? It seems like

Re: [dev-servo] UI Workers

On Fri, Feb 20, 2015 at 8:11 AM, Julien Wajsberg wrote: > Le 20/02/2015 04:25, Robert O'Callahan a écrit : >> On Fri, Feb 20, 2015 at 4:02 PM, James Long wrote: >> >> Personally I think what we *really* need to be working on is making >> all of the DOM APIs asynchronous. That's what Servo

Re: [dev-servo] UI Workers

On Thu, Feb 19, 2015 at 7:11 PM, James Long wrote: > Note however that people in the native app world believe that it's > very important that whatever applies the animations is run on the same > thread that handles input. Otherwise it's very easy for animations to > get out-of-sync. Does that mea

Re: UI Workers

On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan wrote: > Should UIWorkers have access to the full Worker API? It seems like there's > no reason not to give them that. There's two use-cases that I think argues against that. First off I'd like to enable saving a webpage for later viewing. Right

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

On Wed, Feb 11, 2015 at 1:52 AM, Anne van Kesteren wrote: > On Wed, Feb 11, 2015 at 10:42 AM, Jonas Sicking wrote: >> Has the group looked at expanding the feature set of cookies to allow >> better CSRF protection? > > Mike has: > > > https://mikewest.github.io

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

On Wed, Feb 11, 2015 at 12:47 AM, Daniel Veditz wrote: > (2) The "Entry Point Regulation for Web Applications" deliverable seems >> >> to have serious risks of breaking the ability to link. It's not >> clear that the security benefits of this specification outweigh the >> risks to the

Re: Intent to ship: CSS display:contents

On Mon, Feb 2, 2015 at 1:33 PM, L. David Baron wrote: > On Monday 2015-02-02 11:27 -0800, paul.ir...@gmail.com wrote: >> Hey Mats, the use cases are not obvious to me, but I didn't follow the >> original www-style threads on this so I'm lacking context. (A the spec >> doesn't help either) >> >>

Re: Intent to implement: CSS Grid Layout Module Level 1

On Tue, Feb 3, 2015 at 11:40 AM, Mats Palmgren wrote: > On 02/03/2015 04:51 PM, Jonas Sicking wrote: >> >> Can we also expose this to certified apps so that our Gaia developers can >> start experimenting with using grids? > > There isn't any useful layout co

Re: Intent to implement: CSS Grid Layout Module Level 1

Yes! Can we also expose this to certified apps so that our Gaia developers can start experimenting with using grids? / Jonas On Feb 2, 2015 2:25 PM, "Mats Palmgren" wrote: > Summary: > CSS Grid defines a two-dimensional grid-based layout system, optimized for > user interface design. In the gri

Re: Evaluating the performance of new features

On Sun, Feb 1, 2015 at 3:28 AM, Kyle Huey wrote: > Do we have actual evidence that indexeddb performance is a problem? I've > never seen any. Yup. I think this is a very good question. Did the people writing https://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature gather a

Re: Evaluating the performance of new features

On Thu, Jan 29, 2015 at 6:52 PM, Vladan Djeric wrote: > > Definitely not intending to point you out here Vladan. However, it would be cool if we fixed our IndexedDB implementation rather than told our own dev

Re: HTTP/2 and User-Agent strings?

On Tue, Jan 27, 2015 at 1:31 PM, Chris Peterson wrote: > On 1/27/15 9:29 AM, Jonas Sicking wrote: >> >> We keep telling websites to not use the UA string, however we've so >> far been very bad at asking them why they use the UA string and then >> cre

Re: HTTP/2 and User-Agent strings?

On Tue, Jan 27, 2015 at 1:16 AM, Chris Peterson wrote: > Firefox, Chrome, and IE only support HTTP/2 over TLS, even though the spec > does not require it. What if browser vendors similarly agreed to never send > the User-Agent header over HTTP/2? > > If legacy content relies on User-Agent checks,

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

On Fri, Jan 16, 2015 at 12:58 AM, Anne van Kesteren wrote: > * "Permissions API" this has been tried several times before. Given > that there's hardly any involvement from UX in standards, it's not > clear that this is a good idea. See also > http://robert.ocallahan.org/2011/06/permissions-for-web

Re: Network Predictive Actions re-enabled on Nightly

On Thu, Jan 15, 2015 at 6:44 PM, Patrick Cloke wrote: > Even if not a large privacy concern, I doubt I'll see a beneficial tradeoff > from reducing my connection times by 100ms. I'm sure other people will find > this super beneficial, however. I'll probably give it a try before deciding > what to

Re: W3C Proposed Recommendation: longdesc

On Wed, Jan 7, 2015 at 3:19 AM, Marco Zehe wrote: > My recommendation: Take a deep breath, and move on to more important things. Yeah, I agree with this. We should treat this as a learning experience and suck up having to maintain the relatively small implementation. / Jonas ___

Re: W3C Proposed Recommendation: longdesc

On Tue, Jan 6, 2015 at 3:13 PM, L. David Baron wrote: > (I'm not happy about this spec; for a good description of why, see > http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html . > I'm also under the impression that they're using Mozilla's > "implementation" of it as support fo

Re: Getting rid of already_AddRefed?

On Tue, Dec 23, 2014 at 1:03 PM, Jeff Walden wrote: > On 12/23/2014 10:48 AM, L. David Baron wrote: >> Our convention has always been to pass raw pointers, generally with >> the assumption that the caller is expected to ensure the pointer >> lives across the function call. > > Like Eric, I would l

Re: Cross origin communication and the navigator.connect API

On Tue, Dec 16, 2014 at 11:00 AM, Alex Russell wrote: > On Mon, Dec 15, 2014 at 6:25 PM, Jonas Sicking wrote: >> >> On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell >> wrote: >> > On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking wrote: >> >> >>

Re: Cross origin communication and the navigator.connect API

On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell wrote: > On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking wrote: >> >> On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell >> wrote: >> >> One solution would be to at that point allow the SW from the other >> >&g

Re: Cross origin communication and the navigator.connect API

On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell wrote: >> So for example if cross-site communication is initiated >> when the user press a button, the response to that button push can >> take unacceptably long. > > This is, perhaps, a good reason for a discovery system; one layered on top > of direc

Re: Sane/possible to implement/standardize opt-in (user and page) mobile "show password" behavior for HTML input type=password?

On Fri, Dec 12, 2014 at 3:12 PM, Martin Thomson wrote: > Why not simply provide a way to show the password always? I believe that > Microsoft always provides the little eye icon in their new password input > fields. If anything, I'd have this feature on by default. Ooh, this is an interesting i

Re: Sane/possible to implement/standardize opt-in (user and page) mobile "show password" behavior for HTML input type=password?

On Fri, Dec 12, 2014 at 2:59 PM, Andrew Sutherland wrote: > Is it reasonable to try and standardize support for an "allow-show-password" > boolean attribute and corresponding allowShowPassword property on HTML > inputs with type=password? There would also be a showPassword property. > When allowS

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

On Fri, Dec 12, 2014 at 2:39 PM, Ehsan Akhgari wrote: > On 2014-12-12 5:33 PM, Jonas Sicking wrote: >> >> Awesome! I think this would be great to have for the integration tests >> in B2G as well. > > > It is already live for all mochitest-plains run on b2g, or did

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

Awesome! I think this would be great to have for the integration tests in B2G as well. / Jonas On Fri, Dec 12, 2014 at 10:34 AM, Ehsan Akhgari wrote: > We had a session on intermittent test failures in Portland < > https://etherpad.mozilla.org/ateam-pdx-intermittent-oranges>, and one of > the th

Re: Cross origin communication and the navigator.connect API

On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell wrote: >> One solution would be to at that point allow the SW from the other >> origin to install itself, which means that you can then just talk to >> it as a normal installed SW. However installing a SW could take >> significant amount of time. On th

Re: Intent to Implement: User Timing API

Yes! On Thu, Dec 11, 2014 at 5:11 PM, Kyle Machulis wrote: > Summary: We've already got the performance resource timing API implemented > (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but never got around > to implementing the user timing API. This would allow users to set unique > ma

Re: Cross origin communication and the navigator.connect API

On Thu, Dec 11, 2014 at 11:17 AM, Alex Russell wrote: > For the purposes of API composition, either this (or navigator.connect()) > will do. One thing that we'll need to solve in a lot of the scenarios discussed in this thread, including navigator.connect(), cross origin SW fetch() and WebActivit

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell wrote: > On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari > wrote: >> >> On 2014-12-10 7:45 PM, Jonas Sicking wrote: >>> >>> On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking wrote: >>>> >>>&g

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking wrote: > On Wed, Dec 10, 2014 at 1:02 PM, wrote: >>> 2) Users could more easily write infinite loops between SWs, since at no >>> point would they be guaranteed to bottom out at the network. >> >> I'm more wor

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 1:02 PM, wrote: >> 2) Users could more easily write infinite loops between SWs, since at no >> point would they be guaranteed to bottom out at the network. > > I'm more worried about the memory implications for low-spec devices of the > russian-doll design for SW fetches

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 12:11 PM, wrote: > "Work with" is a bit too vague here. I think you're suggesting to change > which SW cross-origin fetch() calls are routed to. Right now, > https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#on-fetch-request-algorithm > (called from https

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari wrote: > The downside of this approach is of course relying on the service providers > to get their SWs registered, which may require the user to navigate to the > service provider's origin, but I suppose that matches the security model of > the UA pr

Re: Intent to implement and ship: document.origin

On Dec 2, 2014 1:41 PM, "Boris Zbarsky" wrote: > > On 12/2/14, 8:17 AM, Kevin Grandon wrote: >> >> We currently use location.origin quite frequently in gaia, and we also use it in workers. > > > So the difference between location.origin and document.origin is that the latter is the origin of the d

Re: Default storage

On Nov 29, 2014 3:54 PM, "Ben Kelly" wrote: > > For new quota clients like SW Cache, what storage should we now use? Default? I was previously using persistent. Yes, you should almost always use default. The only two exceptions are: * if the API supports explicit syntax for choosing something o

Re: Array.prototype.includes available in Nightly *only* & String.prototype.contains renamed to includes

Has TC39 discussed how to handle the fact that there are a couple of classes in the DOM, like DOMStringList, which we'd like to replace with normal JS Arrays. But these DOM classes have a .contains function which so far has meant that such a switch was not possible due to the arrays not having a .c

Re: Intent to implement: CSS display:contents

ext? / Jonas On Fri, Nov 21, 2014 at 2:24 PM, Jonas Sicking wrote: > Awesome! I've looked forward to this for a long time! > > / Jonas > > On Thu, Nov 20, 2014 at 11:01 AM, Mats Palmgren wrote: >> Summary: >> Styling an element with display:contents will inhib

Re: Intent to implement: CSS display:contents

Awesome! I've looked forward to this for a long time! / Jonas On Thu, Nov 20, 2014 at 11:01 AM, Mats Palmgren wrote: > Summary: > Styling an element with display:contents will inhibit generating > a box for the element, but its children and pseudo-elements still > generate boxes as normal. > > B

<    1   2   3   4   >