Re: Web IDL review checklist updated

[Boris Zbarsky]

On 4/3/17 3:53 PM, Kyle Huey wrote:

There should probably be something about checking that the spec is
something other vendors are interested in, or that Mozilla has a good
reason to go ahead without them.


Ah, good point.  I added a thing about ensuring that an intent to 
implement is sent, and that the reviewer would not be objecting to said 
intent in the first place.


-Boris

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

Re: Rationalising Linux audio backend support

[ajones]

On Thursday, 23 March 2017 17:42:02 UTC+13, jtkel...@gmail.com  wrote:
> On Wednesday, March 22, 2017 at 1:35:06 PM UTC-5, Botond Ballo wrote:
> > Based on this new information, might there be room to reconsider this 
> > decision?
> 
> Even if you do not reconsider the full decision, could you at least turn it 
> back on for v52, so it can ride the ESR train? This has also been mentioned 
> in the bug in question. 

That would mean having to support ALSA until the ESR expires.

> This would give users a longer period of time to try and transition to 
> PulseAudio or find a solution like apulse to keep Firefox audio working for 
> them. And it would give you more time to accept patches on the ALSA backend, 
> without impeding work on the 5.1 audio support for PulseAudio. 
> 
> Users would have to consciously choose to use the ESR version once v53 comes 
> out, hence you will be sure that they will be aware of the potential dropping 
> of ALSA support. 
> 
> It seems a simple fix to give the disgruntled users something and ease 
> hostilities, making things easier on all the devs involved, and give the 
> users a feeling that Mozilla listens, so they won't have another reason to 
> leave. 

The problem with re-enabling ALSA is that people will get the impression that 
we're still actively maintaining it. We're no longer maintaining the ALSA 
backend.

> Clearly a lot of people are affected. A lot of smaller distros use Firefox as 
> their default, and do not want to include PulseAudio which adds a further 
> complication and is unnecessary for nearly every other Linux app.

The maintenance cost of the ALSA backend in Firefox has an externality to these 
distributions. They can just use --enable-alsa and maintain the ALSA backend 
themselves.


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

Re: Rationalising Linux audio backend support

[doncuppjr]

I want to say thank you for all the wonderful work that the Mozilla team does 
to create this product. Fantastic. I am equally impressed that you took the 
time to ask some basic questions like "what percentage of our Linux users are 
using ALSA vs Pulse". That was very courteous, but I don't think it comes from 
an understanding of how Linux is used in some very common deployment 
scenario's. 

It might happen from time to time that a new user starts their digital life on 
the Linux platform, but I would bet that most users are migrants. A new user 
might click through dialogs and accept defaults, including telling others about 
what he does, but a regular Linux user is little more paranoid. The 
administrators of such systems would be very adept and likely arrived at Linux 
as a solution for it's scalability. Now when we talk about things that scale, 
we are usually talking about huge numbers, in the thousands and tens of 
thousands. Organizations with those kinds of numbers don't usually like be 
counted, and so the very adept admins( the biggest distributors of linux ) will 
disable telemetry as a part of their deployment process. Check SALT, Chef, 
Puppet, CF Engine and so on.

In short, by relying on telemetry to determine what Linux users do or have, you 
have likely limited your perspective to the newest, least knowledgable and most 
likely to leave users available on the platform.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to change editor newline behavior

[Benjamin Smedberg]

I'd like to encourage you to set up a test plan for this. My impression of
the risk profile of this work is that we could easily break some really
important use-cases, and it's likely that sites customize for gecko
behavior and rely on it, either accidentally or on purpose. This is
definitely the kind of thing that would be worth rolling out carefully and
perhaps slowly. Will this behavior be behind a pref which is easy to flip,
test, and roll out?

--BDS

On Sun, Apr 2, 2017 at 8:52 AM, Aryeh Gregor  wrote:

> In our rich-text editor (used in Firefox for designMode and
> contenteditable), when the user hits Enter, we have historically always
> inserted a .  This does not match any other browsers, which use  or
>  as line separators.  In bug 1297414, I'm changing our behavior to use
>  as a line separator.  This matches Blink/WebKit.
>
> So if you have the text "foobar" and hit Enter in between the "foo" and the
> "bar", previously you would get "foobar", and soon you will get
> "foobar".  The defaultParagraphSeparator command can
> be used to change the separator to "p" instead (which matches Edge's
> default behavior last I checked).
>
> Pages or embedders that want to keep the old behavior can run the following
> command: document.execCommand("defaultParagraphSeparator", false, "br").
>
> This change is not likely to affect high-profile sites that use rich-text
> editing (webmail etc.), because due to browser incompatibility, these sites
> all override this behavior anyway.
>
> Our new behavior is as specified in the essentially unmaintained editing
> specification that I wrote several years ago, and tested by the
> web-platform-tests editing suite.  (Except that the "br" value to
> defaultParagraphSeparator is unspecified, and is a Mozilla-specific
> extension for backwards compatibility.)
> ___
> 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: Web IDL review checklist updated

[Kyle Huey]

On Mon, Apr 3, 2017 at 9:07 AM, Boris Zbarsky  wrote:
> I just updated https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist to
> remove some no-longer relevant bits and add various new parts.
>
> The primary audience for this document are people doing Web IDL reviews
> (bcced; you can see the list at
> ),
> but obviously anyone _requesting_ such review should consider running
> through the list before doing so.
>
> Suggestions for further additions (or just edits of the page!) are much
> appreciated.
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

There should probably be something about checking that the spec is
something other vendors are interested in, or that Mozilla has a good
reason to go ahead without them.

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

Re: Switching to async/await from Task.jsm/yield

[Dave Townsend]

On Mon, Apr 3, 2017 at 9:38 AM, Joshua Cranmer  
wrote:

> On 3/16/2017 5:29 PM, Dave Townsend wrote:
>
>> For a long time now we've been writing JS code that waits for promises
>> using Task.jsm and generator functions. Recently though the JS team added
>> support for the JS standard way of doing this, async/await:
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe
>> rence/Statements/async_function
>>
>> Writing code in standard JS is always better for the web, makes it easier
>> to onboard new engineers and allows for better support in developer tools.
>> So I'd like to propose that we switch to the standard way of writing these
>> functions immediately. New code should use async/await instead of Task.jsm
>> going forwards.
>>
>> Florian has some rough plans to automatically rewrite existing usages of
>> Task.jsm to the standard JS forms so for now don't worry much about going
>> and submitting patches to fix up existing code. Once that is done we can
>> remove Task.jsm from the tree.
>>
>> Does anyone object to any of this?
>>
>
> Is it possible to make those scripts public so as to be able to run them
> on comm-central?


They aren't written yet but once they are they will definitely be
available.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Joshua Cranmer ]

On 3/16/2017 5:29 PM, Dave Townsend wrote:

For a long time now we've been writing JS code that waits for promises
using Task.jsm and generator functions. Recently though the JS team added
support for the JS standard way of doing this, async/await:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

Writing code in standard JS is always better for the web, makes it easier
to onboard new engineers and allows for better support in developer tools.
So I'd like to propose that we switch to the standard way of writing these
functions immediately. New code should use async/await instead of Task.jsm
going forwards.

Florian has some rough plans to automatically rewrite existing usages of
Task.jsm to the standard JS forms so for now don't worry much about going
and submitting patches to fix up existing code. Once that is done we can
remove Task.jsm from the tree.

Does anyone object to any of this?


Is it possible to make those scripts public so as to be able to run them 
on comm-central?


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Web IDL review checklist updated

[Boris Zbarsky]

I just updated https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist 
to remove some no-longer relevant bits and add various new parts.


The primary audience for this document are people doing Web IDL reviews 
(bcced; you can see the list at 
), 
but obviously anyone _requesting_ such review should consider running 
through the list before doing so.


Suggestions for further additions (or just edits of the page!) are much 
appreciated.


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

ESLint binary location change: Update your editors (after next merge)

[Mark Banner]

Continuing with the ESLint improvements, we've just landed a change 
 on autoland that 
moves some of the files for ESLint setup to the root directory of 
mozilla-central. It should merge later today if all goes well.


The change means that you should no longer need to tell your editor 
plugins for a specific location of the ESLint binary.


Previously you would have needed to specify 
|tools/lint/eslint/node_modules/.bin|, but no longer. All new developers 
need to do is install the appropriate plug-ins 
.


I've updated the devmo page  
to reflect these changes.


If you need help, feel free to ping me on irc if I'm about, or drop by 
#eslint.


Note: you can delete the old tools/lint/node_modules safely.

Mark

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

Re: Intent to implement: CSS property `line-height-step`

[Koji Ishii]

After some more thoughts, I thought this conversation clarified my feeling
of wrongness, so I added a section to explain that.

https://drafts.csswg.org/css-rhythm/#eastasia

Hope this makes better understanding for this CJK feature.

On Mon, Apr 3, 2017 at 2:39 AM, Koji Ishii  wrote:

> Hi Jet, thank you for cc'ing me.
>
> I'm having difficulty to convince authors to use features when it's behind
> the flag, so it's a bit circling. But we found some sites are, logically
> speaking, implementable only with line-height-step, and their biggest wish
> is interoperability, because supporting down-level browsers is troublesome.
> That being another reason to make convincing sites difficult, with or
> without flag.
>
> One such example is . The site owner had to
> develop SASS plugin because Compass  reference/compass/typography/vertical_rhythm/> doesn't provide vertical
> rhythm for vertical flow, but we confirmed that this site is fully
> implementable by line-height-step. I've got several other cases from Japan
> digital-publishing industry but they're not available on public internet
> unfortunately, so they don't suffice your request. They're not really using
> the behind-the-flag feature, but could they be examples?
>
> cc'ed a few more people, who presented the needs of vertical rhythm in
> Sapporo industry meetup a few years ago, and as far as I understand, they
> will be presenting vertical rhythm again in Tokyo meetup. I hope they can
> present more cases.
>
> Just in case my words in the past were misleading, I do agree with
> usefulness of line grid and box height stepping. They complement
> line-height-step, covers cases where line-height-step doesn't, or make it
> more robust. I do agree, depends on use cases, especially in Latin, they're
> more useful than line-height-step.
>
> If Gecko is going to work on all 3 features -- line grid, box step, and
> line step -- this is super great. We wish to revisit them in future too.
> But other features having useful cases doesn't look like a reason not to
> work on line height step to me, when line-height-step complements line grid
> and box stepping (and vice-versa of course,) and CJK has been strongly
> demanding vertical rhythm for more than a decade even the simplest one.
> We're going to try to make CJK happy first, then try to spread to other
> authors, but other engines can take different orders, or make all of them
> happy at once. It's just great.
>
>
> On Sun, Apr 2, 2017 at 12:42 AM, Jet Villegas 
> wrote:
>
>> During recent discussions with Koji Iishi, we said we would consider
>> this feature for implementation if we could find examples of content
>> authored for this feature that satisfy use cases from web and/or print
>> designers. I'd still love to see those examples ( authored by someone
>> outside the working group) before we commit to an implementation. In
>> other words, we said we'd do it if it was relatively straightforward
>> to implement *and* web authors outside the CSSWG has used the
>> experimental Chromium feature and is happy with the rendering.
>>
>> Koji: have you found such examples?
>>
>> Thanks,
>>
>> --Jet
>>
>>
>> On Thu, Mar 30, 2017 at 9:11 PM, Tommy Kuo  wrote:
>> > **Summary**
>> >
>> > I am intent to implement the property `line-height-step`. And it would
>> be disabled behind the pref `layout.css.line-height-step.enabled` by
>> default. It is a property to make authors create the content with vertical
>> rhythm easier.
>> >
>> > **Link to standard**
>> >
>> > CSS Rhythmic Sizing
>> > 
>> >
>> >
>> > **Bug Link**
>> >
>> > Bug 1343819 - Implement CSS property `line-height-step`
>> > 
>> >
>> > **Tests**
>> >
>> > There are already some test cases on web-platform-tests.
>> > > >
>> >
>> > **Status on Other Browsers**
>> >
>> > *Blink*
>> >
>> > Blink is implemented in Issue 2704343003.
>> > 
>> >
>> > Currently, this property only available in Chromium Developer Build 59.
>> To try this feature, you need to enable "Experimental Web Platform
>> features" in chrome://flags.
>> >
>> > *WebKit & Edge*
>> >
>> > Not support.
>> >
>> > **More About It**
>> >
>> > Vertical rhythm is a principle of typography. It is about spacing text.
>> More generally, it is about vertical stacked elements. We can create a more
>> comfortable layout with vertical rhythm.
>> >
>> > We can imagine that we're put all elements on a sheet of lined paper.
>> The sizes of elements are according to the size between the lines.
>> >
>> > For example, we set the font-size as 12px. And the line-height is 1.5x
>> of font-size, so it is 18px. We assume we want to put all elements on a
>> lined paper and the line size is 18px. For the 

Re: Rationalising Linux audio backend support

[Jean-Yves Avenard]

On Fri, Mar 31, 2017 at 3:49 PM, Chris Coulson
 wrote:
> The Firefox package in Ubuntu is maintained by 1 contributor in his
> spare time and myself who is only able to do the minimum in order to
> provide updates, so Ubuntu flavors that don't ship Pulseaudio need to
> step up to maintain this code if they want it to continue working and
> don't want it to be disabled again in a future update.

Sorry for hijacking.

But ubuntu's firefox build doesn't enable rust.

A side effect is that FLAC support (and other codecs in MP4)  isn't
enabled as a consequence.

Any chances to get that enabled?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS property `line-height-step`

[Koji Ishii]

Hi Jet, thank you for cc'ing me.

I'm having difficulty to convince authors to use features when it's behind
the flag, so it's a bit circling. But we found some sites are, logically
speaking, implementable only with line-height-step, and their biggest wish
is interoperability, because supporting down-level browsers is troublesome.
That being another reason to make convincing sites difficult, with or
without flag.

One such example is . The site owner had to develop
SASS plugin because Compass <
http://compass-style.org/reference/compass/typography/vertical_rhythm/>
doesn't provide vertical rhythm for vertical flow, but we confirmed that
this site is fully implementable by line-height-step. I've got several
other cases from Japan digital-publishing industry but they're not
available on public internet unfortunately, so they don't suffice your
request. They're not really using the behind-the-flag feature, but could
they be examples?

cc'ed a few more people, who presented the needs of vertical rhythm in
Sapporo industry meetup a few years ago, and as far as I understand, they
will be presenting vertical rhythm again in Tokyo meetup. I hope they can
present more cases.

Just in case my words in the past were misleading, I do agree with
usefulness of line grid and box height stepping. They complement
line-height-step, covers cases where line-height-step doesn't, or make it
more robust. I do agree, depends on use cases, especially in Latin, they're
more useful than line-height-step.

If Gecko is going to work on all 3 features -- line grid, box step, and
line step -- this is super great. We wish to revisit them in future too.
But other features having useful cases doesn't look like a reason not to
work on line height step to me, when line-height-step complements line grid
and box stepping (and vice-versa of course,) and CJK has been strongly
demanding vertical rhythm for more than a decade even the simplest one.
We're going to try to make CJK happy first, then try to spread to other
authors, but other engines can take different orders, or make all of them
happy at once. It's just great.


On Sun, Apr 2, 2017 at 12:42 AM, Jet Villegas  wrote:

> During recent discussions with Koji Iishi, we said we would consider
> this feature for implementation if we could find examples of content
> authored for this feature that satisfy use cases from web and/or print
> designers. I'd still love to see those examples ( authored by someone
> outside the working group) before we commit to an implementation. In
> other words, we said we'd do it if it was relatively straightforward
> to implement *and* web authors outside the CSSWG has used the
> experimental Chromium feature and is happy with the rendering.
>
> Koji: have you found such examples?
>
> Thanks,
>
> --Jet
>
>
> On Thu, Mar 30, 2017 at 9:11 PM, Tommy Kuo  wrote:
> > **Summary**
> >
> > I am intent to implement the property `line-height-step`. And it would
> be disabled behind the pref `layout.css.line-height-step.enabled` by
> default. It is a property to make authors create the content with vertical
> rhythm easier.
> >
> > **Link to standard**
> >
> > CSS Rhythmic Sizing
> > 
> >
> >
> > **Bug Link**
> >
> > Bug 1343819 - Implement CSS property `line-height-step`
> > 
> >
> > **Tests**
> >
> > There are already some test cases on web-platform-tests.
> > 
> >
> > **Status on Other Browsers**
> >
> > *Blink*
> >
> > Blink is implemented in Issue 2704343003.
> > 
> >
> > Currently, this property only available in Chromium Developer Build 59.
> To try this feature, you need to enable "Experimental Web Platform
> features" in chrome://flags.
> >
> > *WebKit & Edge*
> >
> > Not support.
> >
> > **More About It**
> >
> > Vertical rhythm is a principle of typography. It is about spacing text.
> More generally, it is about vertical stacked elements. We can create a more
> comfortable layout with vertical rhythm.
> >
> > We can imagine that we're put all elements on a sheet of lined paper.
> The sizes of elements are according to the size between the lines.
> >
> > For example, we set the font-size as 12px. And the line-height is 1.5x
> of font-size, so it is 18px. We assume we want to put all elements on a
> lined paper and the line size is 18px. For the normal text, we just put
> them align the lines. If there is a title with 24px, to follow the vertical
> rhythm, the size of the title should be multiple of the line size. We add
> 6px to both over-side and under-side of the title, and the size of the
> title would be 36px (2 * 18).
> >
> >
> > - Tommy
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > 

Re: Rationalising Linux audio backend support

[Georg Fritzsche]

Given Ubuntus popularity, we decided to first reach out to that
distribution.
With limited resources and other work, we haven't reached out much further
yet.

Recently, there was some progress:
Fedora is apparently submitting Telemetry
.
Arch Linux now sends Telemetry
.

However, we do depend on work from the distributions.
If you want to work with us on this, please reach out by filing a bug
,
mail to me or fhr-dev, or catch us on IRC in #telemetry.

Thanks,
Georg

On Sat, Apr 1, 2017 at 2:48 PM,  wrote:

> Den fredag 31 mars 2017 kl. 15:49:50 UTC+2 skrev Chris Coulson:
> > On 31/03/17 05:52, burmar...@gmail.com wrote:
> > > Ubuntu just re-enabled ALSA on their latest Firefox 52.0.2 release. Go
> Ubuntu!
> > It's enabled, but please see the small-print in the changelog
> > description at
> > https://launchpad.net/ubuntu/+source/firefox/52.0.2+build1-
> 0ubuntu0.16.04.1.
> > The Firefox package in Ubuntu is maintained by 1 contributor in his
> > spare time and myself who is only able to do the minimum in order to
> > provide updates, so Ubuntu flavors that don't ship Pulseaudio need to
> > step up to maintain this code if they want it to continue working and
> > don't want it to be disabled again in a future update.
> >
>
> On the other hand, Ubuntu is one of the most popular distros. So this
> action should push firefox in the right direction. Does anyone have an idea
> about the Debian policy? Fedora?
> ___
> 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

[Firefox Desktop] Issues found: March 27th to March 31th

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *March 27 - March 31* (week 13).


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*
none

*BETA CHANNEL*

ID  Summary Product Component   Is a regression 
Assigned to
1351618 
Stub Installer freezes when installing Firefox
Firefox
Installer
NO  NOBODY
1351666 
	Compact themes not kept in the list of my themes from customize when 
switching through light themes

Firefox
Theme
NO  NOBODY
1352397 
[Linux] Caesars Slots hangs/crashes on loading
Core
Plug-ins
TBD NOBODY
1352404 
Use "you"/"your" in preference strings, not "me"/"my"/"I"
Firefox
Preferences
NO  NOBODY

**
*
AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1352420  	[Preferences] The distance between 
the text and the "Learn More" links should be smaller in DRM Content, 
Tracking Protection and Data Choices sections

Firefox
Preferences
NO  NOBODY
1352384 
Facebook notifications sounds are blocked
Core
Audio/Video: Playback   TBD NOBODY


*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1350932  	[Mac] BBC videos take too long to 
play or fails to play at all

CoreAudio/Video: Playback
	YES 
 
	Jean-Yves Avenard 
1352081  	Google Maps experiences flickering 
when ending the GPU Process

Core
Graphics
NO  NOBODY

*
ESR CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1350847 
	Unable to dismiss the image pop-out container on Linkedin using mouse 
events

Core
Layout: Images
TBD NOBODY
1350851 
calendar.yahoo.com doesn't send the right intermediate certificates
Tech Evangelism
Desktop
TBD NOBODY



Regards,
Cornel Ionce
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