Re: Deprecating XUL in new UI

[zbraniecki]

On Monday, January 23, 2017 at 12:03:35 PM UTC-8, Eric Shepherd wrote:
> It seems to me, anyway, that the ideal solution would be to enhance HTML 
> (ideally in the spec) with the features needed to build a full-fledged 
> desktop UI. That would be fabulous not just for Firefox making the transition 
> to defining its UI in HTML, but could potentially be adopted by other 
> projects and platforms that use JavaScript and HTML to build apps (such as 
> Electron).

This is, by the way, what we're doing with Intl.

We're replacing all of our Intl APIs with TC39 ECMA402 backed Intl APIs (driven 
by CLDR) and when we find a limitation, we introduced a `mozIntl` chrome-only 
API which serves us as a place where we close the gap while maintaining future 
compatibility and at the same time we use it to test ideas for future ECMA402 
extensions.

This model has been received really well by TC39 so far and keeps us on a path 
with a multi-win:

1) We're aligned with the spec work
2) We're championing a lot of the spec work
3) We have a reason to believe that eventually, all of mozIntl will end up in 
ECMA402
4) Moving things from mozIntl into Intl once it gets into spec is easy

I can totally imagine us doing it for HTML.

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

Re: Aarch64 as higher than tier-3?

[Henri Sivonen]

On Mon, Jan 23, 2017 at 9:00 PM, Kevin Brosnan  wrote:
> AArch64 (ARMv8) has been shipping on Android phones since Q3 2014.

Furthermore, the flagships all seem to have 4 GB of RAM now. It's not
clear to me if ARMv7 userland processes on AArch64 Android kernel get
2 GB or 3 GB of virtual address space, so it's not exactly clear to me
to what extent we are currently failing to use the RAM on the latest
phones, but in any case, the physical RAM is already in the territory
where the pointer size starts to matter.

(The context of my question was, however, understanding how soon we
might have higher than tier-3 configs that have NEON available
unconditionally.)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Status of support for Android on ARMv7 without NEON

[Henri Sivonen]

On Mon, Jan 23, 2017 at 8:03 PM, Nicholas Alexander
 wrote:
> On Mon, Jan 23, 2017 at 9:58 AM, Henri Sivonen  wrote:
>>
>> Do we support Android on ARMv7 without NEON?
>
>
> Ralph Giles told me just a few days ago that yes, we support ARMv7 with and
> without NEON.

OK. That makes it impractical to use NEON in Rust at this time then
(even with optimism about currently nightly-only Rust features
becoming available for Firefox code soon enough).

> Right now, we ship only a single Fennec APK that supports Android API 15+.

Thanks. I thought we we shipping a couple of different APKs for
different API levels.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: sysconf(_SC_NPROCESSORS_ONLN) is apparently not reliable on Android / ARM

[Jim Blandy]

There are plans to move the js/src/threading primitives into MFBT, so I
don't think the core count is out of scope.


On Mon, Jan 23, 2017 at 11:53 AM, Gabriele Svelto 
wrote:

> On 23/01/2017 18:44, Gian-Carlo Pascutto wrote:
> > If only we had some crossplatform runtime that abstracted such system
> > specifics away from us
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=663970) then maybe we
> > wouldn't have to re-fix the same bugs every 5 years.
>
> On this topic, I've heard multiple times from multiple sources to steer
> away from NSPR for cross-platform stuff and use MFBT instead as much as
> possible. But MFBT doesn't even come close to supporting all the
> system-specific stuff that NSPR supports. Do we plan on extendind MFBT
> to cover what's missing?
>
>  Gabriele
>
>
>
> ___
> 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 disable service workers and push in 52 ESR

[Lawrence Mandel]

We disabled some features (iirc Hello and Pocket) in ESR45. The preference
is to keep ESR inline with what's in the mainline release but we're also
supporting ESR on a best effort basis. I think the rationale in this thread
for disabling service workers and push in ESR52 makes sense if we're not
going to be able to maintain these features and they don't yet have broad
adoption that is going to see a significant risk of web compat issues.

Lawrence

On Mon, Jan 23, 2017 at 3:07 PM, Eric Shepherd 
wrote:

> Any time something is disabled or removed from ESR, please be sure the
> developer docs team knows about it, because that’s something that has to be
> reflected in our documentation. I’m not aware of many (if any)
> documentation that says something exists in version X but not in ESR
> version X; that’s an inaccuracy we need to avoid and to fix where already
> present.
>
> > On Jan 18, 2017, at 10:49 AM, Ben Kelly  wrote:
> >
> > Hi all,
> >
> > I'd like to disable service workers in 52 ESR.  This would also require
> > disabling push notifications.
> >
> > A year ago we decided to disable service workers in 45 ESR because it was
> > very new and unstable:
> >
> > https://groups.google.com/forum/#!msg/mozilla.dev.platform/yuNHtDhl3lY/
> VWXOa8N9AgAJ
> >
> > While things have stabilized since then we are in process of making a
> major
> > architectural change in order to support multiple content processes
> > (multi-e10s).  This will make it very difficult to uplift fixes.  Once
> the
> > new architecture has stabilized we should be able to enable SW in the
> next
> > ESR.
> >
> > Thoughts?
> >
> > Thanks.
> >
> > Ben
> > ___
> > 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: Intent to disable service workers and push in 52 ESR

[Eric Shepherd]

Any time something is disabled or removed from ESR, please be sure the 
developer docs team knows about it, because that’s something that has to be 
reflected in our documentation. I’m not aware of many (if any) documentation 
that says something exists in version X but not in ESR version X; that’s an 
inaccuracy we need to avoid and to fix where already present.

> On Jan 18, 2017, at 10:49 AM, Ben Kelly  wrote:
> 
> Hi all,
> 
> I'd like to disable service workers in 52 ESR.  This would also require
> disabling push notifications.
> 
> A year ago we decided to disable service workers in 45 ESR because it was
> very new and unstable:
> 
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/yuNHtDhl3lY/VWXOa8N9AgAJ
> 
> While things have stabilized since then we are in process of making a major
> architectural change in order to support multiple content processes
> (multi-e10s).  This will make it very difficult to uplift fixes.  Once the
> new architecture has stabilized we should be able to enable SW in the next
> ESR.
> 
> Thoughts?
> 
> Thanks.
> 
> Ben
> ___
> 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: Deprecating XUL in new UI

[Eric Shepherd]

It seems to me that the XUL to HTML transition is a big job that needs to be 
done with care. Would it make sense to try to work toward additions to HTML 
and/or additions of prefixed attributes and the like to add the needed 
behaviors to HTML wherever possible before trying to hack out a transition?

It seems to me, anyway, that the ideal solution would be to enhance HTML 
(ideally in the spec) with the features needed to build a full-fledged desktop 
UI. That would be fabulous not just for Firefox making the transition to 
defining its UI in HTML, but could potentially be adopted by other projects and 
platforms that use JavaScript and HTML to build apps (such as Electron).

If we can set a goal of getting a list of the features needed and spec out how 
we’d revise HTML to support those same functionalities (or at least 
functionalities that will get the job done), it would be good for everyone.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ 
Blog: http://www.bitstampede.com/ 
Twitter: http://twitter.com/sheppy

> On Jan 23, 2017, at 11:12 AM, Boris Zbarsky  wrote:
> 
> On 1/23/17 10:31 AM, David Bolter wrote:
>> Should (can) it die in the Quantum development timeframe?
> 
> In my opinion, no.
> 
>> What does that do to shipping risk?
> 
> Makes it super-high.
> 
>> I realize churn creates risk, but I seem to recall XBL
>> is getting in the way for Quantum styling?
> 
> Not as much as having to rewrite all our in-tree XBL in not-yet-existing 
> technologies would get in the way...
> 
> -Boris
> 
> ___
> 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: PSA: sysconf(_SC_NPROCESSORS_ONLN) is apparently not reliable on Android / ARM

[Gabriele Svelto]

On 23/01/2017 18:44, Gian-Carlo Pascutto wrote:
> If only we had some crossplatform runtime that abstracted such system
> specifics away from us
> (https://bugzilla.mozilla.org/show_bug.cgi?id=663970) then maybe we
> wouldn't have to re-fix the same bugs every 5 years.

On this topic, I've heard multiple times from multiple sources to steer
away from NSPR for cross-platform stuff and use MFBT instead as much as
possible. But MFBT doesn't even come close to supporting all the
system-specific stuff that NSPR supports. Do we plan on extendind MFBT
to cover what's missing?

 Gabriele




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

Re: Emoji and Bugzilla

[Eric Shepherd]

Yeah, we’re *so* going to start seeing bugs that are done entirely in emoji. I 
don’t look forward to decoding them, although I’m sure they’ll be incredibly 
clever and fun. :)


> On Jan 17, 2017, at 10:01 PM, Emma Humphries  wrote:
> 
> As the BMO team announced earlier, we're going to be allowing emoji in user 
> inputs in Bugzilla.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1253535 
> 
> 
> We have not committed to a date to release this feature as it requires a 
> production database change which we haven't been able schedule yet. 
> 
> Meanwhile, this change means that as an Bugzilla API consumer, you will need 
> to be ready to accept emoji in your systems.
> 
> In particular, if your client application uses MySQL, you'll need to update 
> your databases and tables to use utf8mb4 instead of utf8 encoding, otherwise 
> if you try writing strings containing emoji, they would be truncated at the 
> first emoji which would be a  situation. Adjust that caveat as needed for 
> other data stores such as Postgres.
> 
> If your application will need time to be able to support emoji, please 
> contact the bmo team. Otherwise we'll assume you're  with this change and 
> not .
> 
> Also, once we turn this feature on, some of our users will think themselves 
> clever and create bugs with  as the title. If the bug contains little else 
> than that, it's probably a  and can be closed as INVALID.
> 
> -- Emma ()
> ___
> 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

Sandboxing plans for Media, WebRTC and Networking

[Randell Jesup]

Since some discussions at the all-hands around audio sandboxing and
mtransport's blocking linux sandbox tightening, and discussions with the
necko team, I decided to explore the options available to us, before we
got too far down a path-of-least-resistance.  The following is the
result of that analysis and discussions with people involved
(Media/WebRTC/Networking/Sandboxing teams).

The full document with details on the pluses and minuses of each option
is here:
https://docs.google.com/document/d/1cwc153l1Vo6CDuzCf7M7WbfFyHLqOcPq3JMwwYuJMRQ

  Randell Jesup

Media, WebRTC and Network Sandboxing plans

This document is meant to lay out the options for Media and Webrtc
sandboxing, as well as options for Necko.  Changes need to made here in
order to tighten the Content sandboxes further, in particular for Audio
input/output and because some mtransport code (ICE/TURN) uses OS calls
for IP/interface discovery that we want to lock down.  Before we start
making changes, we should vet the design and determine if it makes sense
to move more code & where the moved code should live - Master (“Chrome
Process” in MDN docs), Content, or a separate sandbox.

Conclusion: I recommend two new sandboxes in the short term (option 4.5
below) - one for Audio in/out and Video in, one for mtransport.  (We
combine with the audio/video one if the sandboxes cause too much
(memory, startup) overhead.)  For later stages, we should first consider
sandboxing Necko protocols (especially new/external ones) ala GMP, and
finally we should consider adding to the media sandbox MSG, WebAudio,
gUM, and PeerConnection/pipeline code.  That last would be a much larger
change, though with some significant architectural security advantages
potentially.

The current state:
* Video input lives in Master (CamerasParent) and talks to CamerasChild in 
Content
* Video display is handled by Compositor (via independent sandbox and IPC 
channel)
* Audio input and output are handled in Content - both by cubeb in
  full_duplex, and output by cubeb and input by webrtc.org code for
  non-full-duplex.
* WebRTC networking code (media/mtransport) handles ICE/TURN and routing
  RTP/RTCP over the ICE/TURN channels via IPC, using UDPSocket/TCPSocket
  code with packet filters. 
* mtransport talks to PeerConnections and JSEP/signaling
* Some IP/interface discovery code in mtransport makes OS calls from Content
* PeerConnections run in the Content code
* WebRTC codecs run there too, except for things like OpenH264 (in GMP sandbox)
* MediaDecoders run in Content (jya has made some changes here on some
  platforms; DXVA decoders run in the GPU process) 
* Codecs run in Content, GPU , or in GMP sandboxes (especially EME)
* Mac may do similarly in the future
* MediaStreamGraph (MSG) runs in each Content process, as needed.  In
  some cases if used by chrome code it will run in Master as well.
* MSG runs either off a timer (if there’s no sound output) or off of
  audio driver callbacks on OS driver threads (with sound output).
* There can be multiple MSGs in the same process (for example for
  disconnected non-realtime MSGs used for WebAudio, and in the future
  multiple MSGs to handle output device selection) 
* WebAudio runs as part of MSG
* Necko code (used by HTTP/etc and by mtransport for low-level IO) runs
  in Master
  This includes protocols, encryption, cache and many other bits

Needs:
* For sandboxing work, we want to lock down Content process such that
  audio must move out of Content. 
* Deadlines for output data must be met to avoid underruns; tougher
  though doable when the request must transit IPC 
* mtransport needs to stop making OS calls from Content

Wants:
* Minimize complexity
* IPC adds complexity, especially when anything is synchronous.
* Complexity adds bugs
* Complexity slows down maintenance and makes code harder to understand
* Security
* A sandbox is more secure than the Master process
* Especially for code that touches arbitrary data from outside -
  i.e. codec data (encode (can come from canvas) or especially decode),
  and network data (packets can contain most anything if it gets by the
  packet filter, which is mostly about origin). 
* Complex code (codecs) often has hidden bugs, and fuzzing helps but
  doesn’t guarantee holes don’t exist. 
* ICE/TURN is pretty complex networking code, and a good chunk of it is
  in legacy C (no refcounting/etc). 
* Developing new wireline protocols (such as QUIC) in userspace adds new
  risks, especially as fixes and improvements will be rapidly iterated
  on, and they’re exposed to crafted packets. 
* Failure of the code in a sandbox doesn’t give up the whole system
* Firewalling (sandboxing) vulnerable media/networking code from Content
  is also useful, since a break of the media/networking code would
  require a sandbox escape to get access to raw content (passwords, bank
  data, etc). 
* This is part of why GMP is used (though not the only reason).
* Running imported code in a sandbox, especially 

Re: Aarch64 as higher than tier-3?

[Ryan VanderMeulen]

On 1/23/2017 1:00 PM, Henri Sivonen wrote:

Are there any plans to support Aarch64 as a tier higher than tier-3?
For Android or the upcoming Aarch64 flavor of Windows 10 maybe?



Is Google shipping a 64-bit Android emulator for aarch64 yet? Last I 
knew, they only supported x86 for their 64-bit emulator.

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

Re: Aarch64 as higher than tier-3?

[Gian-Carlo Pascutto]

On 23-01-17 19:21, Benjamin Smedberg wrote:
> I expect that Android arm64 is similar, but I don't have any context at
> all: are aarch64 phones shipping or expected to ship?

Most new high end Android models are AArch64 AFAIK.

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

Re: Aarch64 as higher than tier-3?

[Benjamin Smedberg]

I've started an discussion about the arm64 windows version, but we don't
have any news/decision yet. We may need to for market reasons, but the cost
in terms of release engineering, release testing and to some extent feature
testing is not trivial.

I expect that Android arm64 is similar, but I don't have any context at
all: are aarch64 phones shipping or expected to ship?

--BDS

On Mon, Jan 23, 2017 at 1:00 PM, Henri Sivonen  wrote:

> Are there any plans to support Aarch64 as a tier higher than tier-3?
> For Android or the upcoming Aarch64 flavor of Windows 10 maybe?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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: Status of support for Android on ARMv7 without NEON

[Gian-Carlo Pascutto]

On 23-01-17 18:58, Henri Sivonen wrote:
> Do we support Android on ARMv7 without NEON?
> 
> Does the answer differ for our different API level builds?

I believe that as of currently, we do fully support this. All our code
that has NEON codepaths uses runtime detection for NEON presence. In the
past, this was a point of attention for our WebRTC code when pulling
from upstream, and I've occasionally verified that this works correctly
by testing on a Galaxy Tab 10.1, which has the Tegra 2 chip. As far as I
know that is actually the only somewhat common chip that has the
unfortunate ARMv7-but-no-NEON configuration.

Our minimum API level is 15, which still supports this device.

To answer what is presumably your next question, Telemetry should be
able to answer what kind of userbase there still is on this
configuration (as NEON presence is IIRC in basic system data). I expect
it to be pretty slim.

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

Re: Status of support for Android on ARMv7 without NEON

[Nicholas Alexander]

On Mon, Jan 23, 2017 at 9:58 AM, Henri Sivonen  wrote:

> Do we support Android on ARMv7 without NEON?
>

Ralph Giles told me just a few days ago that yes, we support ARMv7 with and
without NEON.  This is relevant to the Oxidation project.

I may have been incorrect; I'm CCing Ralph to verify or correct me.


> Does the answer differ for our different API level builds?
>

Right now, we ship only a single Fennec APK that supports Android API 15+.

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

Aarch64 as higher than tier-3?

[Henri Sivonen]

Are there any plans to support Aarch64 as a tier higher than tier-3?
For Android or the upcoming Aarch64 flavor of Windows 10 maybe?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Status of support for Android on ARMv7 without NEON

[Henri Sivonen]

Do we support Android on ARMv7 without NEON?

Does the answer differ for our different API level builds?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: sysconf(_SC_NPROCESSORS_ONLN) is apparently not reliable on Android / ARM

[Gian-Carlo Pascutto]

On 23-01-17 17:27, Lars Hansen wrote:
> sysconf(_SC_NPROCESSORS_ONLN) is used a number of places in the tree to get
> a core count for parallel algorithms.  The web says that that phrase does
> not really return the number of available cores on ARM Linuxish systems in
> general, including Android - because the return value does not account for
> cores that are sleeping for power saving reasons.  (I've confirmed this
> locally on an ARM board.)  So you may get lucky when you ask.  Or not.
> 
> sysconf(_SC_NPROCESSORS_CONF) works better here.
> 
> JS engine issue with some background and links to other discussions:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1333059.

If only we had some crossplatform runtime that abstracted such system
specifics away from us
(https://bugzilla.mozilla.org/show_bug.cgi?id=663970) then maybe we
wouldn't have to re-fix the same bugs every 5 years.

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

PSA: sysconf(_SC_NPROCESSORS_ONLN) is apparently not reliable on Android / ARM

[Lars Hansen]

sysconf(_SC_NPROCESSORS_ONLN) is used a number of places in the tree to get
a core count for parallel algorithms.  The web says that that phrase does
not really return the number of available cores on ARM Linuxish systems in
general, including Android - because the return value does not account for
cores that are sleeping for power saving reasons.  (I've confirmed this
locally on an ARM board.)  So you may get lucky when you ask.  Or not.

sysconf(_SC_NPROCESSORS_CONF) works better here.

JS engine issue with some background and links to other discussions:
https://bugzilla.mozilla.org/show_bug.cgi?id=1333059.

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

Re: Deprecating XUL in new UI

[Boris Zbarsky]

On 1/23/17 10:31 AM, David Bolter wrote:

Should (can) it die in the Quantum development timeframe?


In my opinion, no.


What does that do to shipping risk?


Makes it super-high.


I realize churn creates risk, but I seem to recall XBL
is getting in the way for Quantum styling?


Not as much as having to rewrite all our in-tree XBL in not-yet-existing 
technologies would get in the way...


-Boris

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

Re: Deprecating XUL in new UI

[David Bolter]

On Tue, Jan 17, 2017 at 12:55 PM, Bobby Holley 
wrote:

> On Tue, Jan 17, 2017 at 8:56 AM, Boris Zbarsky  wrote:
>
> > On 1/16/17 4:28 PM, Matthew N. wrote:
> >
> >> Does it just work from XHTML documents?
> >>
> >
> > Yes, as far as I know.
> >
> > Is our implementation of Web Components ready to replace it and riding
> the
> >> trains?
> >>
> >
> > No.
> >
>
>
> From the perspective of the platform, my general experience is that XBL is
> much, much more of a PITA than XUL itself. I would be very skeptical of a
> plan to start using some form of heavily-XBL-reliant HTML.
>
> I have generally ambivalent feelings towards XUL, but XBL cannot die fast
> enough.
>

Should (can) it die in the Quantum development timeframe?  What does that
do to shipping risk? I realize churn creates risk, but I seem to recall XBL
is getting in the way for Quantum styling?

Cheers,
David


>
> bholley
>
>
> >
> > -Boris
> >
> > ___
> > 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: Deprecating XUL in new UI

[David Bolter]

Hi all, so as not to leave this hanging:

On Tue, Jan 17, 2017 at 9:24 AM, Axel Hecht  wrote:

> Am 16/01/2017 um 21:43 schrieb Dave Townsend:
>
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>>
> Accessibility? Not sure how big the difference is there between XUL and
> HTML.
>

Thanks for bringing this up. There is almost no difference and we're
covered here.

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

[Firefox Desktop] Issues found: January 16th to January 20th

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, January 16 - January 20 (week 3).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:

https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



RELEASE CHANNEL
IDSummaryProductComponentIs a regressionAssigned to1331637 
DnD uploads empty 
folders on onedrive.comCoreDrag and DropNONOBODY


BETA CHANNEL
none

AURORA CHANNEL
IDSummaryProductComponentIs a regressionAssigned to1331648 
Only one event is 
registered when plugging / unplugging camera on Ubuntu for 
mediaDevices.ondevicechangeCoreWebRTC: Audio/VideoNOMunro Mengjue 
Chiang1331950 Only 
the sound plays on youtube when RDM is active and a device 
selectedFirefoxDeveloper Tools: Responsive Design ModeNONOBODY1332671 
Changing the 
search engines list doesn't enable the "Restore defaults" 
buttonFirefoxSearchYESNOBODY


NIGHTLY CHANNEL
IDSummaryProductComponentIs a regressionAssigned to1331866 
Same result on 
stress testing website with the HW acceleration ON or 
OFFCoreGraphicsTBDGeorge Wright


ESR CHANNEL
none


Regards,
Andrei Vaida
Team Lead
SOFTVISION
The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.


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