Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

On Fri, Dec 4, 2015 at 3:55 PM, R Kent James wrote: > Yonggang Luo, I've been trying to figure out how to understand what you > are doing for over a year now without success. You've been doing some > amazing work, and I get the vague impression that you are working on a >

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

Yonggang Luo, I've been trying to figure out how to understand what you are doing for over a year now without success. You've been doing some amazing work, and I get the vague impression that you are working on a Chinese fork of Thunderbird. Now you are proposing some specific changes to

Re: WebUSB

On Thu, Dec 3, 2015 at 11:48 PM, Jonas Sicking wrote: > On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan > wrote: > > 1) What I suggested: Whitelist vendor origins for access to their devices > > and have vendor-hosted pages ("Web drivers"?) expose

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

On 12/4/2015 3:06 AM, 罗勇刚(Yonggang Luo) wrote: When I trying submit a patch to thunderbird community, that's always need to create a bug in bug.mozilla.org, and that's very hard to use and slow. The merging progress are very slow. That's why I am hesitate to contributing things back. Do you a

Re: WebUSB

On Fri, Dec 4, 2015 at 8:04 PM, Robert O'Callahan wrote: > However, for USB the "Web driver" approach seems better than that, to me. > It makes it easy to update the vendor library to fix security bugs and > update the API. If the Web API is baked into the device firmware

Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

Hi, I have written a proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust: https://docs.google.com/document/d/13GCbdvKi83a77ZcKOxaEteXp1SOGZ_9Fmztb9iX22v0/edit I'd appreciate comments--especially from the owners of the uconv module and from people who have worked on

Re: Intent to ship: referrerpolicy attribute

On Fri, Dec 4, 2015 at 8:57 AM, Jonas Sicking wrote: > I think our implementation still has the problem that specifying > referrerpolicy="none-when-downgrade" on an element has no effect. This > is because the ReferrerPolicy enum uses the same value for RP_Unset, > RP_Default

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

On Fri, Dec 4, 2015 at 5:54 PM, Henri Sivonen wrote: > On Fri, Dec 4, 2015 at 3:18 PM, Ted Mielczarek wrote: >> 2) Instead of a clean-room implementation, would it be possible to fix >> the problems you see with rust-encoding so that it's suitable for

Re: FYI: e10s will be enabled in beta 44/45

On 2015-12-04 9:02 AM, jmath...@mozilla.com wrote: Hey all, FYI e10s will be enabled in beta/44 in a limited way for a short period time through an experiment. [1] The purpose of this experiment is to collect e10s related performance measurements specific to beta. The current plan is to then

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2015 04:54 PM, Henri Sivonen wrote: > On Fri, Dec 4, 2015 at 3:18 PM, Ted Mielczarek > wrote: >> 1) What does Servo do, just use rust-encoding directly? > > That is my understanding, but it would be good if a Servo >

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

On Fri, Dec 4, 2015 at 3:18 PM, Ted Mielczarek wrote: > 1) What does Servo do, just use rust-encoding directly? That is my understanding, but it would be good if a Servo developer could confirm. > 2) Instead of a clean-room implementation, would it be possible to fix > the

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

On Fri, Dec 4, 2015, at 06:53 AM, Henri Sivonen wrote: > Hi, > > I have written a proposal to a) rewrite Gecko's encoding converters > and b) to do it in Rust: > https://docs.google.com/document/d/13GCbdvKi83a77ZcKOxaEteXp1SOGZ_9Fmztb9iX22v0/edit > > I'd appreciate comments--especially from the

FYI: e10s will be enabled in beta 44/45

Hey all, FYI e10s will be enabled in beta/44 in a limited way for a short period time through an experiment. [1] The purpose of this experiment is to collect e10s related performance measurements specific to beta. The current plan is to then enabled e10s in beta/45 for a respectable chunk of

Re: FYI: e10s will be enabled in beta 44/45

LastPass bring the browser to a crawl making it almost impossible to use. If we have users using LastPass on the beta population using e10s we're going to have a lot of people upset. https://bugzilla.mozilla.org/show_bug.cgi?id=1008768 On 15-12-04 10:44 AM, Ehsan Akhgari wrote: > On 2015-12-04

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

<<< text/html; charset=utf-8: Unrecognized >>> ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

On Saturday, December 5, 2015 at 12:33:56 AM UTC+8, Nathan Froyd wrote: > On Fri, Dec 4, 2015 at 8:52 AM, luoyonggang wrote: > > > Do you a guess of _why_ they are slow? > > How serious is the slowness? > > How much faster would it need to be to be acceptable? > > > >

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

On Fri, Dec 4, 2015 at 8:52 AM, luoyonggang wrote: > Do you a guess of _why_ they are slow? > How serious is the slowness? > How much faster would it need to be to be acceptable? > > Under win32, the llinkage time of xul.dll is 5minutes on ssd machine, > that's not

Re: Intent to implement and ship: FIDO U2F API

On 12/04/2015 06:56 PM, smaug wrote: Looks like the spec could be made implementable by fixing https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api "provide a namespace object u2f of the following interface" doesn't mean

Re: Intent to implement and ship: FIDO U2F API

Looks like the spec could be made implementable by fixing https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api "provide a namespace object u2f of the following interface" doesn't mean anything, so either there is supposed

Re: SPS Profiles are now captured for entire subprocess lifetime

Thanks Mike for your hard work pushing this through! In theory it does let us profile e10s on TAlos, but I'm sure well will find more usability issues. It's unclear if they will be a blocker or not. If there's outstanding issues I don't think we know about them. Please file them and CC me on any

Re: SPS Profiles are now captured for entire subprocess lifetime

Part of the way. The last bit is to de-duplicate all of the Profiler.js scripts in talos, and get them to use the asynchronous mechanisms for profile gathering and writing (since they're currently using dumpProfileToFile, which prevents us from getting out-of-process profiles). That'll be in bug

Re: WebUSB

r On Fri, Dec 4, 2015 at 2:25 PM, Robert O'Callahan wrote: > On Fri, Dec 4, 2015 at 1:56 PM, Eric Rescorla wrote: > >> On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan >> wrote: >> >>> There are three possible approaches I can see to

Re: WebUSB

On Fri, Dec 4, 2015 at 1:56 PM, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan > wrote: > >> There are three possible approaches I can see to expose USB devices to >> third-party applications: >> 1) What I suggested: Whitelist

Re: WebUSB

On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan wrote: > On Wed, Dec 2, 2015 at 10:00 AM, Eric Rescorla wrote: > >> On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan >> wrote: >> >> I'd really like to see WebUSB with USB device IDs

Re: WebUSB

On Fri, Dec 4, 2015 at 2:43 PM, Eric Rescorla wrote: > > Sure. Conversely, I don't find myself convinced by your position. > > Would be happy to talk about this live if you think that's useful. > Probably not ... these are judgement calls that are difficult to resolve. Rob --

Re: FYI: e10s will be enabled in beta 44/45

On Friday, December 4, 2015 at 9:44:36 AM UTC-6, Ehsan Akhgari wrote: > On 2015-12-04 9:02 AM, jmath...@mozilla.com wrote: > > Hey all, > > > > FYI e10s will be enabled in beta/44 in a limited way for a short period > > time through an experiment. [1] The purpose of this experiment is to > >

Re: FYI: e10s will be enabled in beta 44/45

On Friday, December 4, 2015 at 11:08:08 AM UTC-6, Armen Zambrano G. wrote: > LastPass bring the browser to a crawl making it almost impossible to > use. If we have users using LastPass on the beta population using e10s > we're going to have a lot of people upset. Not an issue since initial