Intent to drop TSF (Text Services Framework) support on WinXP and WinServer 2003

[Masayuki Nakano]

Summary: Drop TSF support only from WinXP and WinServer 2003.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1205600

Platforms: Windows XP, Windows Server 2003 and Windows Server 2003 R2

Estimated or target release: Gecko 44

Background:

I've already given up to support TSF on WinXP and WinServer 2003 since 
the TSF on them are much immature and Natural Input which is Japanese 
IME bundled on WinXP behaves too much complicated but few users were 
used. Starting Gecko 41, TSF is enabled in default settings only on 
Vista or later. For enabling TSF on WinXP or WinServer2k3, user needs to 
change "intl.tsf.force_enable" to true from about:config.


Dropping this feature from WinXP will cause inconvenience to WinXP 
Tablet users. But I think that such users were already updated their 
devices to Android Tablet, iPad or newer Windows Tablet. So, it must not 
be worthwhile to support limited support of TSF on legacy Windows.


--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: easily getting allocation stacks for leaking objects

[Gerald Squelart]

Good stuff!

I hope you'll consider tracking AddRef's and Release's as well.

I recently experimented with that for a troubled RefCounted class [1], and it 
was very useful to find which AddRef didn't have its corresponding Release.

Cheers,
Gerald

[1] https://hg.mozilla.org/try/rev/8dffaf0d2acf
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: git-bz-moz and Bugzilla 2 factor authentication

[Andrew McCreight]

On Thu, Sep 17, 2015 at 6:50 AM, Ehsan Akhgari 
wrote:

> git bz edit and git bz push don't work, but the rest should, so please file
>> issues at https://github.com/mozilla/git-bz-moz or email me if you notice
>> them. (Oh, I think setting reviewer flags for Firefox product bugs doesn't
>> work, is a known issue.) The patches are still a little hacky and probably
>> don't cache as much as they should.
>>
>
> Hmm, I thought <
> https://github.com/mozilla/git-bz-moz/commit/4bdde9d270ff72f1a06943306b558dab29f2a3f7>
> had fixed setting the reviewer flags for Firefox product bugs.  Does that
> not work?
>


The method of setting multiple flags didn't seem to work with the REST API.
I was planning on following what bzexport does, which is query the server
for those flag values for the given product.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: easily getting allocation stacks for leaking objects

[Andrew McCreight]

On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart  wrote:

> Good stuff!
>
> I hope you'll consider tracking AddRef's and Release's as well.
>
> I recently experimented with that for a troubled RefCounted class [1], and
> it was very useful to find which AddRef didn't have its corresponding
> Release.
>

There's already refcount logging for this:
  http://www-archive.mozilla.org/performance/refcnt-balancer.html

It is generally too spammy to include in the TreeHerder log, but it can be
useful.

Andrew



>
> Cheers,
> Gerald
>
> [1] https://hg.mozilla.org/try/rev/8dffaf0d2acf
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: git-bz-moz and Bugzilla 2 factor authentication

[Ehsan Akhgari]

On 2015-09-15 5:37 PM, Andrew McCreight wrote:

Apparently Bugzilla 2fa breaks the weird cookie authentication method that
git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug,
but in the meanwhile I've been working on making git-bz-moz use the
Bugzilla backend of bexport, which is less hacky and supports using API
keys for authentication. Setting up an API key is extremely easy.

If you want to try it out, it is available from my github repo here:
   https://github.com/amccreight/git-bz-moz/tree/RestAPI


Thanks for doing this!


git bz edit and git bz push don't work, but the rest should, so please file
issues at https://github.com/mozilla/git-bz-moz or email me if you notice
them. (Oh, I think setting reviewer flags for Firefox product bugs doesn't
work, is a known issue.) The patches are still a little hacky and probably
don't cache as much as they should.


Hmm, I thought 
 
had fixed setting the reviewer flags for Firefox product bugs.  Does 
that not work?


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Changes in chrome JS code due to ES6 global lexical scope

[Shu-yu Guo]

Hello all,

​We are in the process of implementing the global lexical scope per ES6.
This changes the semantics of global level 'let' and 'const' bindings from
our non-standard semantics to standard semantics.

Currently, global 'let' and 'const' bindings ​introduce properties onto the
global object. Global 'let' behaves identically to 'var', and global
'const' is like 'var', with the exception that the property it introduces
is read-only. Since they behave essentially like 'var', they can be
redeclared and there is no TDZ (i.e., you can use them before their
declarator is reached, resulting in an undefined).

​In ES6, this changes.

1. Global 'let' and 'const' are no longer properties on the global object.
They go into a separate global lexical scope.

2. Global 'let' and 'const' may not be redeclared at the global level with
'let', 'const', or 'var'.

3. Global 'let' and 'const' are subject to temporal dead zone (TDZ)
semantics. If they are referenced before their declarator is executed, a
ReferenceError is thrown. For example,

dump(x); // will throw instead of print undefined.
let x = 42;

4. The global lexical scope is extensible. This means dynamic scope (lol!):


function f() { dump(x); }
f(); // prints undefined​
​


​let x = 42;
f(); // prints 42


As you can imagine, these changes break all our chrome code. Almost all the
errors are due to 1) and 2).

Due to 1), there are many places where code expects 'let' and 'const'
bindings are expected to be properties. Cu.import is a common offender:

Foo.jsm:
const SOME_CONSTANT = 42;

foo.js:
// SOME_CONSTANT isn't a property on the global scope returned by Cu.import
const { SOME_CONSTANT } = Cu.import("Foo.jsm", {})

Due to 2), there are thousands of places where we redeclare Ci, Cc, Cu,
etc. Many tests redeclare 'let' and 'const' bindings. Test harnesses also
like to inject code with 'let'.


I am in the process of slowly fixing the world.

​Because ​until now, our global 'let' semantics have been identical to
those of 'var', I have already landed a patch that mass replaces global
'let' with 'var' as part of bug 1202902.

Because there is no direct syntactic replacement for 'const', I am combing
through the code on a case by case basis.

For Firefox devs, I ask 2 things:

1) For bindings expected to be properties on the global scope, please do
that explicitly with |this.foo = ...| or 'var' and stop using 'let' and
'const'.

2) Understand the semantics of Cu.import. From reading the code, this seems
commonly misunderstood. The API is |Cu.import(path, targetObj)|. In
pseudocode, what Cu.import does is:

... executes script pointed to path ...

for (symbol of jsmGlobalScope.EXPORTED_SYMBOLS) {
​  targetObj[symbol] = jsmGlobalScope[symbol];
}
​
​return jsmGlobalScope;
​
​That is, Cu.import's return value is the *entire global scope* of the JSM.
It isn't targetObj. It doesn't respect EXPORTED_SYMBOLS. You can get
anything you want out of the global scope of the JSM.​

The relevant bugs are bug 1202902 and bug 589199.

Please reach out on IRC if you have questions.
-- 
   shu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mach mozregression command

[Benoit Girard]

Yes that's a good point and a perfectly sensible. Thanks for the handy
wrapper!

On Wed, Sep 16, 2015 at 5:37 PM, J. Ryan Stinnett  wrote:

> On Wed, Sep 16, 2015 at 1:42 PM, Benoit Girard 
> wrote:
> > I just
> > hope that we continue to maintain mozregression as a standalone tool and
> > that this wrapper doesn't cause us to miss regressions in it.
>
> The mach wrapper essentially just calls "pip install mozregression"[1]
> and passes args along, so the standalone tool should be safe.
>
> [1]:
> https://dxr.mozilla.org/mozilla-central/rev/9ed17db42e3e46f1c712e4dffd62d54e915e0fac/tools/mach_commands.py#398
>
> - Ryan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: easily getting allocation stacks for leaking objects

[Andrew McCreight]

On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight 
wrote:

>
>
> On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart 
> wrote:
>
>> Good stuff!
>>
>> I hope you'll consider tracking AddRef's and Release's as well.
>>
>> I recently experimented with that for a troubled RefCounted class [1],
>> and it was very useful to find which AddRef didn't have its corresponding
>> Release.
>>
>
> There's already refcount logging for this:
>   http://www-archive.mozilla.org/performance/refcnt-balancer.html
>
>
Olli points out that I should actually link to the more modern page for
this:

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Refcount_tracing_and_balancing

Anybody who wants help with refcount logging should feel free to get in
touch with me and I can help walk them through it.


> It is generally too spammy to include in the TreeHerder log, but it can be
> useful.
>
> Andrew
>
>
>
>>
>> Cheers,
>> Gerald
>>
>> [1] https://hg.mozilla.org/try/rev/8dffaf0d2acf
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

About 's future...

[helpcrypto helpcrypto]

Hi all


As previously raised on this list, there's a open wardiscussion about
removing [1]

Some people, like Sir Tim Berners-Lee doesn't seem to agree with that,
hence another thread is taking place at [2]

For Google, it seems the decision has been made, nothing is going to
change, and   could dissappear on Chrome 47 [3].

As MDN has marked the element as deprecated (according to WHATWG, I guess)
and there is -at least- one related bug open [4]:


*I will love someone @mozilla giving an official position, a blog post or
saying something (even "we haven't decided anything yet") about this issue,
and -if it's going to happen- aproximate date of the removal.*


Thanks a lot.

[1]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack
[2] https://lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html
[3] https://code.google.com/p/chromium/issues/detail?id=514767
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1024871
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About 's future...

[helpcrypto helpcrypto]

On Thu, Sep 17, 2015 at 8:59 PM, Rob Stradling 
wrote:

> The existence of this bug...
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1191414
> "gather telemetry on usage of "
>
> ...would seem to suggest that Mozilla "haven't decided anything yet".
>

IMHO that's not a good approach. A coomon user uses  each 3 years
or so...so percents will be very low, but impact on organizations based on
this will be severe.
Consider also there people that doesn't have telemetry on (blame me).

Regards
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: easily getting allocation stacks for leaking objects

[Nick Fitzgerald]

Note that for JS objects (and JS strings very soon), you can track
allocation stacks with the Debugger API:

https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory

On Thu, Sep 17, 2015 at 10:55 AM, Andrew McCreight 
wrote:

> On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight 
> wrote:
>
> >
> >
> > On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart 
> > wrote:
> >
> >> Good stuff!
> >>
> >> I hope you'll consider tracking AddRef's and Release's as well.
> >>
> >> I recently experimented with that for a troubled RefCounted class [1],
> >> and it was very useful to find which AddRef didn't have its
> corresponding
> >> Release.
> >>
> >
> > There's already refcount logging for this:
> >   http://www-archive.mozilla.org/performance/refcnt-balancer.html
> >
> >
> Olli points out that I should actually link to the more modern page for
> this:
>
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Refcount_tracing_and_balancing
>
> Anybody who wants help with refcount logging should feel free to get in
> touch with me and I can help walk them through it.
>
>
> > It is generally too spammy to include in the TreeHerder log, but it can
> be
> > useful.
> >
> > Andrew
> >
> >
> >
> >>
> >> Cheers,
> >> Gerald
> >>
> >> [1] https://hg.mozilla.org/try/rev/8dffaf0d2acf
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: easily getting allocation stacks for leaking objects

[Gerald Squelart]

On Friday, September 18, 2015 at 3:55:27 AM UTC+10, Andrew McCreight wrote:
> On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight
> wrote:
> >
> > On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart
> > wrote:
> >
> >> Good stuff!
> >>
> >> I hope you'll consider tracking AddRef's and Release's as well.
> >>
> >> I recently experimented with that for a troubled RefCounted class [1],
> >> and it was very useful to find which AddRef didn't have its corresponding
> >> Release.
> >
> > There's already refcount logging for this:
> >   http://www-archive.mozilla.org/performance/refcnt-balancer.html
> >
> Olli points out that I should actually link to the more modern page for
> this:
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Refcount_tracing_and_balancing
> 
> Anybody who wants help with refcount logging should feel free to get in
> touch with me and I can help walk them through it.
> 
> 
> > It is generally too spammy to include in the TreeHerder log, but it can be
> > useful.
> >
> > Andrew

Thanks for the links Andrew, I'll give it a go next time!
g.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes in chrome JS code due to ES6 global lexical scope

[Boris Zbarsky]

On 9/17/15 8:26 PM, Shu-yu Guo wrote:

​The first call to f() does not throw.


It actually does, because the bareword lookup for "x" fails.  You get 
"ReferenceError: x is not defined".


If you replaced "x" with "window.x" or "self.x" or "this.x" or something 
I think you'd get the behavior you describe.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Canvas CaptureStream

[Andreas Pehrson]

Targeting Firefox 43, I intend to turn Canvas CaptureStream on by default
for all platforms. It has been developed behind the
`canvas.capturestream.enabled` preference, and landed behind that pref in
Firefox 41.

Other UAs intending to ship it are at least Chromium/Blink, who have
started work in this bug:
https://code.google.com/p/chromium/issues/detail?id=524218.

Pref-flipping-bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1177276
Specification: https://w3c.github.io/mediacapture-fromelement/
Documentation:
https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/captureStream


- Andreas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Is Services.scriptloader.loadSubScript safe?

[arthuredelstein]

Does anyone know, if an extension injects a script into a content page using 
Services.scriptloader.loadSubScript, is there any danger of leaking something 
with chrome privileges to the page?

Here's a short example of how I'm hoping to use loadSubScript: 
https://github.com/arthuredelstein/torbutton/blob/596c1a84dd4db474ffe04c95e43dac3c804b6cd2/src/modules/utils.js#L89

Thanks in advance for any advice!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes in chrome JS code due to ES6 global lexical scope

[Neil]

Shu-yu Guo wrote:


4. The global lexical scope is extensible. This means dynamic scope (lol!):


function f() { dump(x); }
f(); // prints undefined​
​


​let x = 42;
f(); // prints 42


Would you mind clarifying what this is supposed to demonstrate? It looks 
to me that this is demonstrating TDZ semantics, and under ES6 the first 
call to f() will throw.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is Services.scriptloader.loadSubScript safe?

[Bobby Holley]

If you want your subscript to work reliably, you should run it in a sandbox
with an Expanded Principal [1] whose sandboxPrototype points to the content
window object. Otherwise, your code will be subject to breakage by pages
that muck with global state.

If you don't care about that, you might as well just do
contentWindow.eval(yourCode).

[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.Sandbox#Expanded_principal

On Thu, Sep 17, 2015 at 4:05 PM,  wrote:

> Does anyone know, if an extension injects a script into a content page
> using Services.scriptloader.loadSubScript, is there any danger of leaking
> something with chrome privileges to the page?
>
> Here's a short example of how I'm hoping to use loadSubScript:
> https://github.com/arthuredelstein/torbutton/blob/596c1a84dd4db474ffe04c95e43dac3c804b6cd2/src/modules/utils.js#L89
>
> Thanks in advance for any advice!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes in chrome JS code due to ES6 global lexical scope

[Shu-yu Guo]

On Thu, Sep 17, 2015 at 5:18 PM, Neil  wrote:

> Shu-yu Guo wrote:
>
> 4. The global lexical scope is extensible. This means dynamic scope (lol!):
>>
>> 
>> function f() { dump(x); }
>> f(); // prints undefined​
>> ​
>>
>> 
>> ​let x = 42;
>> f(); // prints 42
>> 
>>
>> Would you mind clarifying what this is supposed to demonstrate? It looks
> to me that this is demonstrating TDZ semantics, and under ES6 the first
> call to f() will throw.
>

​The first call to f() does not throw. These are two separate 
tags, and during the execution of the first