[WebAPI] New Proposal of IMS Registration Manager

[Bevis Tseng]

​​
​​Hi all,

I am from RIL team in Mozilla Taipei.
I'm glad to propose you a new module/web api called "IMS Registration
Manager". It is worth sharing you the details and having suggestion
and feedback from you! :)

IMS(IP Multimedia Subsystem) is a new infrastructure and is very
important in mobile network especially for the carriers that enable
LTE which relies more on IP-based network and technology compared to
circuit-switched one in 3G/2G mobile network.

With IMS enabled, carriers start to migrate current telephony services
(Call Control, Text messaging) from legacy network to reduce the
the maintenance expense on multiple infrastructures(LTE, GSM, CDMA).
The mirgation takes couple of years. That means multiple technology
will coexist for a while. Hence, an additional option for user to
toggle this feature in device side becomes required from both
carrier's and device vendor's perspective.
In addition to traditional services, with IMS, carriers can introduce
rich communication services like video call, video sharing, presence
and instant-messaging to the users.

This is also a big task to enable IMS in device side, so we'd like to
work on this step by step. Introducing "IMS Registration Manager" is
the first step to provide user 2 additional options in settings:
1. To enable/disable IMS.
   There is no obvious difference from UX perspective when making
   voice call or text messaging even the underlying technology is
   changed.
   (Note: audio quality will be better because AMR-WB is introduced.)
2. To choose the preferred IMS Porfile to have better service
   quality according to the network condition where the device user
   is located. The device will register to IMS network with preferred
   bearrer that user seleted. Possible options are:
   [wifi-preferred, wifi-only, cellular-preferred, cellular-only]

Based on these requirements, the following webidl is proposed:

enum ImsCapability {
  "voice-over-cellular",
  "voice-over-wifi",
  "video-over-cellular",
  "video-over-wifi"
};

enum ImsProfile {
  "wifi-preferred",
  "wifi-only",
  "cellular-preferred",
  "cellular-only"
};

interface MozImsRegManager {
  getter MozImsRegHandler? handler(unsigned long index);
 // with multi-sim support, will be null if not supported
 // by the device configuration.

  readonly attribute unsigned long length;
   // with multi-sim supported, the
   // value will be the same to the
   // number of service-id/radio
   // interfaces available in device.
};

interface MozImsRegHandler : EventTarget {
Promise setEnabled(boolean enabled);
Promise getEnabled();
Promise setPreferredProfile(ImsProfile profile);
Promise getPreferredProfile();

readonly attribute ImsCapability? capability;
  // available when ims registered.

readonly attribute DOMString? error;
  // available when the ims is not
  // registration to provide possible
  // error cause.

attribute EventHandler oncapabilitychange;
   // triggered if capability or error is changed.
};

partial interface Navigator {
  [Throws, Pref="dom.ims.enabled",
   CheckPermissions="ims", // or "mobileconnection"
   AvailableIn="CertifiedApps", UnsafeInPrerendering]
  readonly attribute MozImsRegManager mozImsManager;
};

Any suggestion on this is really appreciated. :)

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

PSA: Enabling APZ on nightly desktop (OS X, Windows)

[Kartikaya Gupta]

Just a heads-up that I just pushed bug 1157746 to inbound, which
enables async scrolling for trackpad/wheel scrolling by default for
nightly OS X desktop builds. It requires e10s, and so if you have e10s
disabled it has no effect for you. If you have e10s enabled, you
should see smoother/more responsive scrolling, and probably more
"checkerboarding" (scrolling into unpainted content areas).

Note that this is currently NOT riding the trains, we will leave it
enabled on Nightly only until it is more baked, but it should be
stable enough for general usage. Bug 1178298 tracks letting it ride
the trains. Please file bugs in the Core::Panning and Zooming
component if you see anything misbehaving. If you need to turn it off
for whatever reason, you can set the layers.async-pan-zoom.enabled
pref back to false.

Assuming this doesn't get backed out, I intend to also enable the same
thing on Windows in the next day or two (bug 1157745). Linux will take
a bit longer since there are some test failures we need to sort out
first.

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

Re: GTK3 linux builds

[Mike Hommey]

On Wed, Jul 22, 2015 at 11:07:23AM +1200, Robert O'Callahan wrote:
> On Wed, Jul 22, 2015 at 10:59 AM, Mike Hommey  wrote:
> 
> > Done.
> >
> > https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=939320b957c5
> 
> 
> Excellent!
> 
> 
> > - deciding how to handle the situation for people who don't have gtk3
> >   installed on their system. Currently, firefox will silently fail to
> >   restart after the upgrade.
> >
> 
> How many people is that? Do we run on GTK 3.0 or is 3.4 required?

I suspect a lot of people running KDE will only have gtk2 installed for
Firefox, and gtk3 not installed.

> If GTK3 isn't present can we start distro Fireofx instead?

If people are using mozilla builds, they are unlikely to have the distro
package installed.

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

Re: GTK3 linux builds

[Robert O'Callahan]

On Wed, Jul 22, 2015 at 10:59 AM, Mike Hommey  wrote:

> Done.
>
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=939320b957c5


Excellent!


> - deciding how to handle the situation for people who don't have gtk3
>   installed on their system. Currently, firefox will silently fail to
>   restart after the upgrade.
>

How many people is that? Do we run on GTK 3.0 or is 3.4 required?

If GTK3 isn't present can we start distro Fireofx instead?

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GTK3 linux builds

[Mike Hommey]

On Tue, Jul 21, 2015 at 10:31:10PM +1200, Robert O'Callahan wrote:
> On Tue, Jul 21, 2015 at 7:04 PM, Mike Hommey  wrote:
> 
> > On Mon, Jul 20, 2015 at 09:22:05PM -0400, Jeff Muizelaar wrote:
> > > On Mon, Jul 20, 2015 at 6:18 PM, Mike Hommey  wrote:
> > > >
> > > > There are a few remaining perma reds and oranges, FWIW.
> > >
> > > Which ones? I don't see anything on elm.
> >
> > Well, it looks like they are now all gone. :)
> >
> 
> Great! Let's switch now, before they come back! :-)

Done.
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=939320b957c5
Still left to do:
- switching local builds to gtk3 (bug 1186229)
- deciding whether it's ready to actually ride the trains
- deciding how to handle the situation for people who don't have gtk3
  installed on their system. Currently, firefox will silently fail to
  restart after the upgrade.

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

Re: Intent to implement: Moving DevTools to top level /devtools directory

[Kevin Brosnan]

[tangentially related] Are there plans ot move DevTools to a product in
Bugzilla to match this code layout?

Kevin

On Tue, Jul 21, 2015 at 2:54 PM, J. Ryan Stinnett  wrote:

> The DevTools team is planning to move our code out of
> /browser/devtools and /toolkit/devtools and into a new top level
> /devtools directory.
>
> The main goals of this are to reduce confusion for new DevTools
> contributors and help us better organize our work in the future. It
> will also aid future users of the code in understanding what pieces
> they need to include.
>
> There should be no impact to DevTools features shipped in different
> products: Firefox desktop will continue to be the only product that
> ships the DevTools front end, and all others will ship the DevTools
> server only.
>
> It is my understanding that the DevTools team received approval for a
> new top level directory from Brendan several years ago.
>
> Bug: https://bugzil.la/912121
>
> (Replies to dev-platform.)
>
> - Ryan
> ___
> 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

Intent to implement: Moving DevTools to top level /devtools directory

[J. Ryan Stinnett]

The DevTools team is planning to move our code out of
/browser/devtools and /toolkit/devtools and into a new top level
/devtools directory.

The main goals of this are to reduce confusion for new DevTools
contributors and help us better organize our work in the future. It
will also aid future users of the code in understanding what pieces
they need to include.

There should be no impact to DevTools features shipped in different
products: Firefox desktop will continue to be the only product that
ships the DevTools front end, and all others will ship the DevTools
server only.

It is my understanding that the DevTools team received approval for a
new top level directory from Brendan several years ago.

Bug: https://bugzil.la/912121

(Replies to dev-platform.)

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

Re: Collecting web platform features implementation status

[Tom Schuster]

I see 3 (now 4) old pull requests that are unmerged.

On Tue, Jul 21, 2015 at 8:19 PM, Anthony Ricaud  wrote:

> On 16/07/15 21:26, Anthony Ricaud wrote:
>
>> Potch and I are working on a website to present Mozilla's point of view
>> on various web platform features. Other browsers have similar websites
>> [1] [2] [3]. This project has been in lingo for a while so, to get it
>> out the door, we're going to focus on one information: what is Mozilla's
>> opinion on features that have not been shipped yet. We see 4 possible
>> answers: in development, favorable, not favorable, no opinion.
>>
>> In order to get accurate data and update it regularly, we need your
>> help. Please go to the following etherpad and insert any information
>> that can help us:
>> https://etherpad.mozilla.org/gecko-web-platform-dashboard
>>
>> Thanks for your help!
>>
>> [1] https://www.chromestatus.com/features
>> [2] https://status.modern.ie
>> [3] http://www.webkit.org/status.html
>>
> Reminder: We need your help! Please submit a pull request against
> https://github.com/Rik/platform-status/blob/master/features.json.
>
> (I've only received one pull request since moving this JSON to Github :( )
>
> ___
> 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: Collecting web platform features implementation status

[Anthony Ricaud]

On 16/07/15 21:26, Anthony Ricaud wrote:

Potch and I are working on a website to present Mozilla's point of view
on various web platform features. Other browsers have similar websites
[1] [2] [3]. This project has been in lingo for a while so, to get it
out the door, we're going to focus on one information: what is Mozilla's
opinion on features that have not been shipped yet. We see 4 possible
answers: in development, favorable, not favorable, no opinion.

In order to get accurate data and update it regularly, we need your
help. Please go to the following etherpad and insert any information
that can help us:
https://etherpad.mozilla.org/gecko-web-platform-dashboard

Thanks for your help!

[1] https://www.chromestatus.com/features
[2] https://status.modern.ie
[3] http://www.webkit.org/status.html
Reminder: We need your help! Please submit a pull request against 
https://github.com/Rik/platform-status/blob/master/features.json.


(I've only received one pull request since moving this JSON to Github :( )
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Today, 21 Jul 2015 at 4:00PM PDT

[Jet Villegas]

Today's MemShrink meeting is brought to you by NukeCrossCompartmentWrappers
and "browser-y" compartment principals:
https://bugzilla.mozilla.org/show_bug.cgi?id=1174950

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 21 Jul 2015, 4:00 PM PDT
*
http://arewemeetingyet.com/Los%20Angeles/2015-07-21/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
* Triage Etherpad: https://etherpad.mozilla.org/memshrinktriage
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implement Fetch?

[Patrick McManus]

On Tue, Jul 21, 2015 at 5:01 PM, Honza Bambas  wrote:

> The main offenders here are:
> - synchronous "on-*-request" global notifications
>


I believe this is mostly what :sicking refers to when he talks about
[1] https://etherpad.mozilla.org/BetterNeckoSecurityHooks
and I agree that would be useful work..

but casual readers of this thread shouldn't be too depressed - a bunch of
high data volume consumers do manage to take their data events off the main
thread just fine and has been pointed out I/O is definitely not taking
place there.


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

Re: Implement Fetch?

[Honza Bambas]

On 7/18/2015 1:42, Kyle Huey wrote:

To be abundantly clear, no I/O should be happening (or is, to my knowledge)
on the main thread when you use XHR. The limitation today is that various
Necko state operations (e.g. opening a channel) can only happen on the main
thread.


The main offenders here are:
- synchronous "on-*-request" global notifications that are notified via 
the observer service (main thread only) and are widely used by various 
add-ons to hook/block/modify requests and responses that may block.  
This is legacy code.  Async or different hook api would have to be 
designed to replace it.  Problem is that all those that hook to these 
callbacks want to examine and modify or even block the requests, so it 
needs to be sync in most cases.  Everyone want everything...
- nsLoadGroup/nsDocShell et al are strictly main thread but this is just 
about adding locks to the "right places"


I have some plans (no bug# I think) to move at least some of the main 
thread loops we need to do now (not a few!) before we even start reading 
the network response from the cache or send out a network request.  This 
may also mean to prepare land for starting network loads (AsyncOpen a 
channel) off the main thread.


Requirements list from your side appreciated.

-hb-





But that doesn't mean that we are doing I/O there.

- Kyle
On Jul 18, 2015 4:43 AM, "David Rajchenbach-Teller" 
wrote:



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

Need help in resolving compilation issues in building extension

[shansymantec]

Hi,

We build our Firefox binary extension with FF sdk. Our binary extension has 
been successfully built til FF 39 SDK. When I tried to build our extension for 
FF 40 beta 5 sdk in VS 2013, I am facing the following compilation issues.

The same project is built successfully when i point it to FF 39 SDK.  

Could you please provide why there is issue being reported in 
SDK\VS12\MSVC\VC\include\xlocale(1725), SDK\VS12\MSVC\VC\include\xlocinfo(194), 
and in SDK\VS12\MSVC\VC\include\typeinfo(112).
Let me know if you need any info further


Compiler output (detailed)
==

Compiler output (detailed)
==

1>  cl /c /I..\coCoreFW /IE:\perforce\nco_r8.7.12\src\\Include\EVCert 
/IE:\perforce\nco_r8.7.12\src\\Include\SymData 
/I"E:\perforce\nco_r8.7.12\SDK\\VS10\Firefox-SDKs" 
/I"E:\perforce\nco_r8.7.12\SDK\\VS10\Firefox-SDKs\40.0.0\include" 
/I"E:\perforce\nco_r8.7.12\SDK\\VS10\Firefox-SDKs\40.0.0\include\js" 
/I"E:\perforce\nco_r8.7.12\SDK\\VS10\Firefox-SDKs\40.0.0\include\nspr" 
/IE:\perforce\nco_r8.7.12\SDK\\VS10\AutoProtect\Include 
/IE:\perforce\nco_r8.7.12\SDK\\Common\Platform7.1A\include 
/IE:\perforce\nco_r8.7.12\SDK\\Common\WTL\Include 
/IE:\perforce\nco_r8.7.12\SDK\\VS12\MSVC\VC\include 
/IE:\perforce\nco_r8.7.12\SDK\Common\InstallToolBox\Include 
/IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include 
/IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include\Events 
/IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include\Helpers 
/IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include\Interfaces 
/IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include 
/IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include\S
 ervices /IE:\perforce\nco_r8.7.12\src\\Framework2.0\Common\Events 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccGenericLog 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccGenericEvent 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccIPC 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccJobMgr 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccLib 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccSettings 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccService 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccVerifyTrust 
/IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccSubSDK /IRelease\ 
/IE:\perforce\nco_r8.7.12\SDK\\Common\Platform\include 
/IE:\perforce\nco_r8.7.12\SDK\VS10\\msvc\vc\ATLMFC\include 
/IE:\perforce\nco_r8.7.12\SDK\VS10\\msvc\vc\include 
/IE:\perforce\nco_r8.7.12\SDK\\Common\WTL\include 
/IE:\perforce\nco_r8.7.12\src\\include 
/IE:\perforce\nco_r8.7.12\src\\Include\WPP /Zi /W4 /WX- /O1 /Oy- /D WIN32 /D 
NDEBUG 
 /D _WINDOWS /D _USRDLL /D _WTL_NO_CSTRING /D _BIND_TO_CURRENT_VCLIBS_VERSION=1 
/D COFIREFOXPLUGIN_EXPORTS /D LOG_PERFORMANCE /D _WPP_TRACING /D NDEBUG /D 
WIN32 /D _WIN32 /D _CRT_RAND_S /D 
"WPP_CONTROL_HEADER=\"E:\perforce\nco_r8.7.12\src\\include\WPP\WPPGuid.h\"" /D 
_WPP_TRACING /D _USING_V110_SDK71_ /D _WINDLL /D _UNICODE /D UNICODE /X /GF 
/Gm- /EHsc /MD /GS /Gy- /fp:precise /fp:except- /Zc:wchar_t /Zc:forScope /GR- 
/openmp- /Yu"StdAfx.h" /Fp"Release\coFireFoxPluginBeta.pch" /Fo"Release\\" 
/Fd"Release\vc90.pdb" /Gd /TP /analyze- /errorReport:prompt /MP4 
DOMDocumentImpl.cpp (TaskId:18)
1>  _WPP_TRACING
1>  _USING_V110_SDK71_
1>   (TaskId:18)
1>  DOMDocumentImpl.cpp (TaskId:18)
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\typeinfo(112): error C2504: 
'exception' : base class undefined
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\typeinfo(144): error C2504: 
'exception' : base class undefined
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C2039: 
'_Collvec' : is not a member of '`global namespace''
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C2146: 
syntax error : missing ';' before identifier '_Collvec'
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C4430: 
missing type specifier - int assumed. Note: C++ does not support default-int
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C2602: 
'Previous::std::_Locinfo::_Collvec' is not a member of a base class of 
'Previous::std::_Locinfo'
1>  E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57) : see 
declaration of 'Previous::std::_Locinfo::_Collvec' (TaskId:18)
1>  E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(55) : see 
declaration of 'Previous::std::_Locinfo' (TaskId:18)
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C2868: 
'Previous::std::_Locinfo::_Collvec' : illegal syntax for using-declaration; 
expected qualified-name
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(58): error C2039: 
'_Ctypevec' : is not a member of '`global namespace''
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(58): error C2146: 
syntax error : missing ';' before identifier '_Ctypevec'
1>E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(58): error C4430: 
missing

Re: Array.concat

[Amit Zur]

On Tuesday, July 21, 2015 at 4:01:53 PM UTC+3, Till Schneidereit wrote:
> On Tue, Jul 21, 2015 at 12:19 PM, Mike de Boer  wrote:
> 
> > Hi Amit,
> >
> > These are called 'Generics' and are available in Firefox as of JavaScript
> > 1.6 - see
> > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods
> > <
> > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods
> > >
> >
> > Please don't rely on them being available cross-browser, but they are
> > quite easy to shim: a quick duckduckgo search took me to
> > https://github.com/plusdude/array-generics <
> > https://github.com/plusdude/array-generics>, which seems to get the job
> > done.
> >
> 
> And perhaps also don't use them in Firefox: they're a non-standard feature
> we'd rather get rid of, if we could. We *might* be able to at some point in
> the future, but only if people abstain from using them.

Thanks for the info guys
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Array.concat

[Till Schneidereit]

On Tue, Jul 21, 2015 at 12:19 PM, Mike de Boer  wrote:

> Hi Amit,
>
> These are called ‘Generics’ and are available in Firefox as of JavaScript
> 1.6 - see
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods
> <
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods
> >
>
> Please don’t rely on them being available cross-browser, but they are
> quite easy to shim: a quick duckduckgo search took me to
> https://github.com/plusdude/array-generics <
> https://github.com/plusdude/array-generics>, which seems to get the job
> done.
>

And perhaps also don't use them in Firefox: they're a non-standard feature
we'd rather get rid of, if we could. We *might* be able to at some point in
the future, but only if people abstain from using them.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Help with removing __iterator__ from JS

[David Rajchenbach-Teller]

If I recall correctly, the difficulty with the OS.File removal is that
some clients of this code were taking advantage of the old API in ways
that do not match the new one. I will try and take another look at it
over the summer.

Cheers,
 David

On 21/07/15 13:07, Tom Schuster wrote:
> Hello!
> 
> We have an old JS extension that allows objects to modify how they
> behave when used with for-in. However this extension will never make it
> into ES6 and is actually incompatible with how iteration is defined
> there. So please don't use __iterator__anymore.
> 
> I would really appreciate your help with removing __iterator__ from the
> OS.File interface, which makes very heavy use of this feature. Bug
> 938704 hasn't seen any serious work since 2013.
> 
> We also need to look into the addon-sdk, where many of the custom
> collection types implement __iterator__ and thus addon authors might
> iterate over them with for-in ...
> 
> Aside: Please also try avoid using Iterator().
> 
> Thank you,
> Tom
> 
> 
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
> 


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charters: All Groups, XML Activity

[James Graham]

On 21/07/15 11:29, Ms2ger wrote:


This entire Activity is a distraction from the real needs of the web,
and if the W3C is serious about its motto, it should focus on those
rather than providing support and hosting conferences for people's
petty side projects that have no bearing on the web.

However, I'll already be happy if we can kill the XForms zombie.
Apparently they've had a group in plh's Domain for years, and never
produced anything of consequence, and now that he's finally managed to
kick them out, they want to return through this back door. If the
handful of people who still care about it want to continue wasting
each other's time, they can always start a Community Group, or move to
another standards development organization.


I agree with everything Ms2ger said. I don't think that working on 
non-web technologies is helpful to the W3C's stated mission, and I think 
we should encourage those who wish to develop such standards to do so at 
other venues, leaving the W3C free to give much-needed focus to 
web-related work.

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

Help with removing __iterator__ from JS

[Tom Schuster]

Hello!

We have an old JS extension that allows objects to modify how they behave
when used with for-in. However this extension will never make it into ES6
and is actually incompatible with how iteration is defined there. So please
don't use __iterator__anymore.

I would really appreciate your help with removing __iterator__ from the
OS.File interface, which makes very heavy use of this feature. Bug 938704
hasn't seen any serious work since 2013.

We also need to look into the addon-sdk, where many of the custom
collection types implement __iterator__ and thus addon authors might
iterate over them with for-in ...

Aside: Please also try avoid using Iterator().

Thank you,
Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GTK3 linux builds

[Robert O'Callahan]

On Tue, Jul 21, 2015 at 7:04 PM, Mike Hommey  wrote:

> On Mon, Jul 20, 2015 at 09:22:05PM -0400, Jeff Muizelaar wrote:
> > On Mon, Jul 20, 2015 at 6:18 PM, Mike Hommey  wrote:
> > >
> > > There are a few remaining perma reds and oranges, FWIW.
> >
> > Which ones? I don't see anything on elm.
>
> Well, it looks like they are now all gone. :)
>

Great! Let's switch now, before they come back! :-)

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charters: All Groups, XML Activity

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/21/2015 05:36 AM, L. David Baron wrote:
> The W3C is proposing revised charters for all of the working groups
>  in the XML Activity:
> 
> https://lists.w3.org/Archives/Public/public-new-work/2015Jul/.html
>
>
> 
http://www.w3.org/XML/2015/05/activity-proposal.html (which has a
> brief summary of the work)
> 
> recharter: Efficient XML Interchange Working Group 
> http://www.w3.org/XML/2015/05/exi-charter.html
> 
> recharter: XML Query Working Group 
> http://www.w3.org/XML/2015/05/query-charter.html
> 
> recharter: XML Core Working Group 
> http://www.w3.org/XML/2015/05/xml-core-charter.html
> 
> recharter: XML Processing Model Working Group 
> http://www.w3.org/XML/2015/05/xproc-charter.html
> 
> recharter: XSLT Working Group 
> http://www.w3.org/XML/2015/05/xsl-charter.html
> 
> bring back to life: XForms Working Group 
> http://www.w3.org/XML/2015/05/xforms-charter.html
> 
> 
> Mozilla has the opportunity to send comments or objections through
>  Thursday, July 30.
> 
> Please reply to this thread if you think there's something we
> should say as part of this charter review, or whether you think we
> should explicitly abstain.  (Note that we can only explicitly
> abstain from the set of charters as a whole, not individually, at
> least on the ballot form, though I suppose we could do so in
> prose.)
> 
> (My inclination is at minimum to explicitly abstain, with comments
>  that they shouldn't expect browser implementation.)
> 

I'd personally prefer to shut down the entire Activity. None of these
groups will help "lead the web to its full potential" (if that's still
the W3C's motto). They are completely out of touch with what's happened
on the Web is the last decade, exemplified by the following quote from
the XML Core proposed charter:

> The Working Group has current plans to:
> 
> 1. Publish a sixth edition of XML 1.0 as an Edited Recommendation,
> to include the changes for the LEIRI specification, at such time
> as IRI-bis is final.

This entire Activity is a distraction from the real needs of the web,
and if the W3C is serious about its motto, it should focus on those
rather than providing support and hosting conferences for people's
petty side projects that have no bearing on the web.

However, I'll already be happy if we can kill the XForms zombie.
Apparently they've had a group in plh's Domain for years, and never
produced anything of consequence, and now that he's finally managed to
kick them out, they want to return through this back door. If the
handful of people who still care about it want to continue wasting
each other's time, they can always start a Community Group, or move to
another standards development organization.

HTH
Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJVrh8gAAoJEOXgvIL+s8n2OG0H/ioMX2t9p01ngpsKhmsX5yAC
rNvBAf+yhkT6AanCXmXvdnvUbYXjo2zgSQmxPrhRkLWIYQHTjQN4guMoc1v5HljW
JE2Aa5xT5tbKPQ2p/6smwQZyBWZxa7OwapefzrtRBXILyqOFeTG4qqgnd7Hvw1Nx
N9G0e+JgiQjpvZLA3+gncLqpFwpGvQ6RIisfdFlO3QCJy6W4z2skzpLwk3oEEvuk
umLYl2w6bHycn5XNEFrggZ+/q/gYzUP0hWF9+fuaHbvnPsAHAtsBPEt4tt3ocLQY
Pggmb4HYF7LVmrLCo5r8iHOOWVO16iFkDa0X3YRW37AOJ3j7qLUAlKD6qnApAco=
=OzSY
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Array.concat

[Mike de Boer]

Hi Amit,

These are called ‘Generics’ and are available in Firefox as of JavaScript 1.6 - 
see 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods
 


Please don’t rely on them being available cross-browser, but they are quite 
easy to shim: a quick duckduckgo search took me to 
https://github.com/plusdude/array-generics 
, which seems to get the job done.

Hope that helps,

Mike.

> On 21 Jul 2015, at 10:42, Amit Zur  wrote:
> 
> Hi,
> 
> I've noticed that Array.concat is defined in Firefox (in addition to 
> Array.prototype.concat).
> I couldn't find any reference for this in MDN.
> It seems to work as expected, accepting any number of arrays as arguments and 
> concatenating them.
> But is this a standard method of the Array constructor?
> 
> Thanks,
> Amit
> ___
> 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

Array.concat

[Amit Zur]

Hi,

I've noticed that Array.concat is defined in Firefox (in addition to 
Array.prototype.concat).
I couldn't find any reference for this in MDN.
It seems to work as expected, accepting any number of arrays as arguments and 
concatenating them.
But is this a standard method of the Array constructor?

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

Re: GTK3 linux builds

[ishikawa]

On 2015年07月21日 16:04, Mike Hommey wrote:
> On Mon, Jul 20, 2015 at 09:22:05PM -0400, Jeff Muizelaar wrote:
>> On Mon, Jul 20, 2015 at 6:18 PM, Mike Hommey  wrote:
>>>
>>> There are a few remaining perma reds and oranges, FWIW.
>>
>> Which ones? I don't see anything on elm.
> 
> Well, it looks like they are now all gone. :)
> 
> Mike
> 

GTK2 had a few issues:
See, for example, the next bug which was originally noticed when I was
composing e-mail messages in thuderbird.

https://bugzilla.gnome.org/show_bug.cgi?id=696624

Bug 696624 -
Summary:Japanese (Korean/Chinese) XIM input mode indicator has not been
working unde...

[Originally, I submitted the following mozilla bugzilla entry because
I did not realize it was NOT the problem of TB/FF per se.
https://bugzilla.mozilla.org/show_bug.cgi?id=854825
Bug 854825 - Japanese (Korean/Chinese) XIM input mode indicator has not been
working for TB and FF under linux. (with known solution)  ]

Unfortunately, it was not possible to catch/grab attentions of GTK library
developers any more now that GTK3 was their main focus.
(Yet, surprisingly the bug was carried over to GTK3 library, too.
So hoping to attention, I submitted a bugzilla entry:
Bug 731190 -
Summary:XIM input mode indicator does not work. (It shows black box, 
e.g.)
https://bugzilla.gnome.org/show_bug.cgi?id=731190
[Although the bugzilla did not mention any fix, I think the
today's code may have fixed the issue in a really different manner. I don't
even see the
same function any more in the current code if I am not mistaken.]

Yes, sticking with the old and proven software module has a merit, but
when we find it has a hitherto unknown bug, we are often faced with the
problem that original developers are no longer interested in fixing such old
library.

I think it is about time we move to GTK3 library.


CI



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

Re: GTK3 linux builds

[Mike Hommey]

On Mon, Jul 20, 2015 at 09:22:05PM -0400, Jeff Muizelaar wrote:
> On Mon, Jul 20, 2015 at 6:18 PM, Mike Hommey  wrote:
> >
> > There are a few remaining perma reds and oranges, FWIW.
> 
> Which ones? I don't see anything on elm.

Well, it looks like they are now all gone. :)

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