Re: [WebAPI] New Proposal of IMS Registration Manager
On Wed, Jul 22, 2015 at 3:38 AM, Bevis Tseng bts...@mozilla.com 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 it's only related to the IMS
registration and is also suitable to be part of MozMobileConnection that
already available in Navigator.
As long as the API is only exposed to certified content, and is
completely hidden from other pages, then I think you should feel free
to put the API whereever in the DOM that makes most sense to you.
If it turns out to be a problem in the future we can always modify the
API later.
I do agree with Martin that there's no point in 'moz' prefixing it,
but I don't have a strong opinion either way.
/ Jonas
On Wed, Jul 22, 2015 at 4:57 PM, Martin Thomson m...@mozilla.com wrote:
I think that building these sorts of features into the web platform at
large is a very bad idea.
I appreciate that we operate under different constraints for Firefox
OS devices that might have native support for IMS on the baseband chip
and that we don't have much hope of convincing the industry of their
folly. As a certified-only extension, it's still bad, but I recognize
that it may be an inevitability. Drop the moz/Moz prefixing though.
(I don't have enough time to go through this immediately: my time over
the next two weeks is highly constrained, so forgive me for not
engaging in this thread to the extent that you might like.)
On Tue, Jul 21, 2015 at 11:50 PM, Bevis Tseng bts...@mozilla.com wrote:
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 {
Promisevoid setEnabled(boolean enabled);
Promiseboolean getEnabled();
Promisevoid setPreferredProfile(ImsProfile profile);
PromiseImsProfile 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.
Re: [WebAPI] New Proposal of IMS Registration Manager
On Wed, Jul 22, 2015 at 1:57 AM, Martin Thomson m...@mozilla.com 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 of the APIs that we expose to Chrome JS code. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
API docs/evangelism/development teams meeting Thursday at 8 AM PDT
The Web API documentation community meeting, with representatives from the technical evangelism and the API development teams, will take place on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your time zone). Typical meetings include news about recent API development progress and future development plans, discussions about what the priorities for documenting and promoting new Web technologies should be, and the status of ongoing work to document and evangelize these technologies. We have an agenda, as well as details on how to join, here: https://etherpad.mozilla.org/API-docs-meeting-2015-07-23. If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! If you have topics you wish to discuss, please feel free to add them to the agenda. Also, if you're unable to attend but have information or suggestions related to APIs on the Web, their documentation, and how we promote these APIs, please add a note or item to the agenda so we can be sure to address it, even if you're unable to attend. -- Eric Shepherd Senior Technical Writer Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[WebAPI] New Proposal of IMS Registration Manager
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 {
Promisevoid setEnabled(boolean enabled);
Promiseboolean getEnabled();
Promisevoid setPreferredProfile(ImsProfile profile);
PromiseImsProfile 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
Re: GTK3 linux builds
Le 22/07/2015 01:07, Robert O'Callahan a écrit : 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? Also Distro Firefox could be some versions earlier than the version the user used -- could be dangerous for his profile. signature.asc Description: OpenPGP digital signature ___ 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
Does that include getting rid of /browser/ dependencies? Ideally, we'd like to be able to compile non-Firefox builds with our devtools. On Tue, Jul 21, 2015 at 11:54 PM, J. Ryan Stinnett jry...@gmail.com 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-developer-tools mailing list dev-developer-to...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-developer-tools -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [WebAPI] New Proposal of IMS Registration Manager
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 it's only related to the IMS
registration and is also suitable to be part of MozMobileConnection that
already available in Navigator.
Bevis
On Wed, Jul 22, 2015 at 4:57 PM, Martin Thomson m...@mozilla.com wrote:
I think that building these sorts of features into the web platform at
large is a very bad idea.
I appreciate that we operate under different constraints for Firefox
OS devices that might have native support for IMS on the baseband chip
and that we don't have much hope of convincing the industry of their
folly. As a certified-only extension, it's still bad, but I recognize
that it may be an inevitability. Drop the moz/Moz prefixing though.
(I don't have enough time to go through this immediately: my time over
the next two weeks is highly constrained, so forgive me for not
engaging in this thread to the extent that you might like.)
On Tue, Jul 21, 2015 at 11:50 PM, Bevis Tseng bts...@mozilla.com wrote:
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 {
Promisevoid setEnabled(boolean enabled);
Promiseboolean getEnabled();
Promisevoid setPreferredProfile(ImsProfile profile);
PromiseImsProfile 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
Re: Intent to implement: Moving DevTools to top level /devtools directory
Yes, it's something that we'd like to do, but it's not trivial. Sure creating a new product is easy, and moving bugs is fairly simple, but educating people is a thing, and fixing everyone's workflows and scripts is getting annoying, and it probably all adds up to something hard. So while I'd like to do it, it's behind other more important things (e.g. moving to /devtools) right now. Joe. On Tue, Jul 21, 2015 at 11:37 PM, Kevin Brosnan kbros...@gmail.com wrote: [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 jry...@gmail.com 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Help with removing __iterator__ from JS
On 7/21/2015 12:07 PM, Tom Schuster wrote: Aside: Please also try avoid using Iterator(). What would be the alternative to Iterator() when I need to iterate and easily assign both keys and values of an object to local variables? See for example https://bugzilla.mozilla.org/show_bug.cgi?id=980828: this.boundEventHandlers = [ for ([elementName, events] of Iterator(this.events)) for ([eventName, handler] of Iterator(events)) [elementName, eventName, handler.bind(this)] ]; There's more context on the bug for the specific example (the bug is about supporting destructuring in comprehensions in the first place) but my concern in general is that I've failed to find an alternative to Iterator() that is as expressive. Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Help with removing __iterator__ from JS
Hi Paolo,
The ES6 iterator protocol is what you're looking for. See:
*
https://hacks.mozilla.org/2015/04/es6-in-depth-iterators-and-the-for-of-loop/
*
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator
Alongside with the computed property syntax, you should be able to
achieve what you want. Something along the lines of:
function makeIterableEventList(el){
el[Symbol.iterator] = function(){ /* define iterator here*/ }
return el;
}
events: {
[Symbol.iterator]: function(){ /* define iterator here*/ }
mainview: makeIterableEventList({
focus(event) {},
}),
filter: makeIterableEventList({
input(event) {},
}),
},
this.boundEventHandlers = [
for ([elementName, events] of this.events)
for ([eventName, handler] of events)
[elementName, eventName, handler.bind(this)]
];
---
It should work in Firefox today (at least the Symbol.iterator and
computed object prop parts. Not 100% sure about the array comprehension
as I haven't tested)
David
Le 22/07/2015 14:42, Paolo Amadini a écrit :
On 7/21/2015 12:07 PM, Tom Schuster wrote:
Aside: Please also try avoid using Iterator().
What would be the alternative to Iterator() when I need to iterate and
easily assign both keys and values of an object to local variables?
See for example https://bugzilla.mozilla.org/show_bug.cgi?id=980828:
this.boundEventHandlers = [
for ([elementName, events] of Iterator(this.events))
for ([eventName, handler] of Iterator(events))
[elementName, eventName, handler.bind(this)]
];
There's more context on the bug for the specific example (the bug is
about supporting destructuring in comprehensions in the first place)
but my concern in general is that I've failed to find an alternative
to Iterator() that is as expressive.
Cheers,
Paolo
___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Linux builds now default to building with Gtk+3
Hi, If you've followed the recent discussion in the GTK3 linux builds thread, this will come with no surprise, but if not: - Next Linux nightly will have switched to Gtk+3. - As of now on mozilla-inbound, and later on other branches, local Linux (and other non-OSX unices) builds default to Gtk+3. - You will need to install Gtk+3 development files to do those local builds. `mach bootstrap` should be able to do this for you. - You can still do Gtk+2 builds by adding the following to your mozconfig: ac_add_options --enable-default-toolkit=cairo-gtk2 - You can still do Gtk+2 try builds by removing the gtk3.tar.xz entries in browser/config/tooltool-manifests/linux*/releng.manifest. - The Gtk+3 builds that were available on the elm branch will auto-update to normal nightlies in the next few days. - I will switch elm to do Gtk+2 builds, to ensure they don't break in the near future. I'm not sure how long I will keep that running. Big kudos go to, as far as I know, Andrew Comminos, for fixing all the remaining reds and oranges on the Gtk+3 build and allowed to make this possible. And to all the people involved in making the Gtk+3 port work in the first place. Cheers, Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [WebAPI] New Proposal of IMS Registration Manager
On Wed, Jul 22, 2015 at 11:06 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 22, 2015 at 3:38 AM, Bevis Tseng bts...@mozilla.com 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 it's only related to the IMS registration and is also suitable to be part of MozMobileConnection that already available in Navigator. As long as the API is only exposed to certified content, and is completely hidden from other pages, then I think you should feel free to put the API whereever in the DOM that makes most sense to you. Yes, the API is only available to certified content. After further consideration, we think that it's more suitable to be part of MozMobileConnection which is responsible for the control of the features provided in mobile network. If it turns out to be a problem in the future we can always modify the API later. I do agree with Martin that there's no point in 'moz' prefixing it, but I don't have a strong opinion either way. Will do. Thanks for all your feedback about this API. :) Bevis / Jonas ___ 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
On Wed, Jul 22, 2015 at 2:48 PM, Panos Astithas p...@mozilla.com wrote: If you are thinking about shipping them as part of browser.html, we still have XUL dependencies that we need to get rid of first and that work is independent from moving the code to a top-level devtools/ directory. We don't use XUL, but we can still open XUL windows. Would it be possible to use the devtools without chrome://browser/ being accessible? On Wed, Jul 22, 2015 at 1:48 PM, Paul Rouget p...@mozilla.com wrote: Does that include getting rid of /browser/ dependencies? Ideally, we'd like to be able to compile non-Firefox builds with our devtools. On Tue, Jul 21, 2015 at 11:54 PM, J. Ryan Stinnett jry...@gmail.com 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-developer-tools mailing list dev-developer-to...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-developer-tools -- Paul ___ dev-developer-tools mailing list dev-developer-to...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-developer-tools -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Enabling APZ on nightly desktop (OS X, Windows)
In the context of checkerboarding - we know there is more of it than we want, so we don’t need a lot of bugs on it at this point, but if you have an interesting or important example of it happening, please file it, and make it block the “paint-fast” bug 1154825 (do check for duplicates first - for example, the “bugzilla scrolling checkerboards a lot” is already known :) — - Milan On Jul 21, 2015, at 22:29 , Kartikaya Gupta kgu...@mozilla.com wrote: 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 ___ 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
If you are thinking about shipping them as part of browser.html, we still have XUL dependencies that we need to get rid of first and that work is independent from moving the code to a top-level devtools/ directory. On Wed, Jul 22, 2015 at 1:48 PM, Paul Rouget p...@mozilla.com wrote: Does that include getting rid of /browser/ dependencies? Ideally, we'd like to be able to compile non-Firefox builds with our devtools. On Tue, Jul 21, 2015 at 11:54 PM, J. Ryan Stinnett jry...@gmail.com 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-developer-tools mailing list dev-developer-to...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-developer-tools -- Paul ___ dev-developer-tools mailing list dev-developer-to...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-developer-tools ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
