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 Thunde
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
> Chinese fork of Thunderb
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 "safe" API to
> > third-party applications.
>
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 and RP_No_Referrer_W
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 that's a
> lot harder.
T
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
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 encoding
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 o
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
o
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
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 problems you see with
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 our
>> use? Especially if Servo is already us
-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
> developer could confirm.
<<< text/html; charset=utf-8: Unrecognized >>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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 acceptable.
>
How much RAM do
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?
> >
> > Under win32, the llinkage ti
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 t
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
a
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 9:
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
> > coll
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 rollout
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 i
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 1
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 are bound to specific
>>> origins (through a registry for leg
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 vendor origins for access to their devices
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 expose USB devices to
>>> third-party applications:
>>> 1)
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
--
lbir ye,ea yer.tn
27 matches
Mail list logo
