Fennec/Android turns on Quantum CSS (stylo) as default

2017-11-22 Thread Makoto Kato
Last month, I enabled building stylo as default even if Fennec.  Now
in 59 cycle and all tests are passed, so I will turn on stylo [*1]
soon.

If you found new issue, please file a bug in Core :: CSS Parsing and
Computation with "stylo: " in the subject.


-- Makoto Kato

[*1] https://bugzilla.mozilla.org/show_bug.cgi?id=1366049
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Fennec/Android turns on Quantum CSS (stylo) as default

2017-11-22 Thread Astley Chen
Cool! Thanks for the hard work to make it happen!

As for mobile constraints, we are concerning the code size and memory
usage. Do we know what’s the impact for now?

Makoto Kato 於 2017年11月22日 週三,下午6:09寫道:

> Last month, I enabled building stylo as default even if Fennec.  Now
> in 59 cycle and all tests are passed, so I will turn on stylo [*1]
> soon.
>
> If you found new issue, please file a bug in Core :: CSS Parsing and
> Computation with "stylo: " in the subject.
>
>
> -- Makoto Kato
>
> [*1] https://bugzilla.mozilla.org/show_bug.cgi?id=1366049
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
-- 

—-
Best Regards,
Astley Chen | Mozilla Taiwan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Fennec/Android turns on Quantum CSS (stylo) as default

2017-11-22 Thread Makoto Kato
When enabling stylo, explicit memory will be 2-3% grow on Linux from
AWSY, so android will be same rate

Also, APK size grows 1.5MB now.  But stylo team is working to remove
old style system.


-- Makoto Kato

On Wed, Nov 22, 2017 at 7:38 PM, Astley Chen  wrote:
> Cool! Thanks for the hard work to make it happen!
>
> As for mobile constraints, we are concerning the code size and memory usage.
> Do we know what’s the impact for now?
>
> Makoto Kato 於 2017年11月22日 週三,下午6:09寫道:
>>
>> Last month, I enabled building stylo as default even if Fennec.  Now
>> in 59 cycle and all tests are passed, so I will turn on stylo [*1]
>> soon.
>>
>> If you found new issue, please file a bug in Core :: CSS Parsing and
>> Computation with "stylo: " in the subject.
>>
>>
>> -- Makoto Kato
>>
>> [*1] https://bugzilla.mozilla.org/show_bug.cgi?id=1366049
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
> --
>
> —-
> Best Regards,
> Astley Chen | Mozilla Taiwan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Fennec/Android turns on Quantum CSS (stylo) as default

2017-11-22 Thread Tom Ritter
On Wed, Nov 22, 2017 at 8:08 AM, Makoto Kato  wrote:
> When enabling stylo, explicit memory will be 2-3% grow on Linux from
> AWSY, so android will be same rate
>
> Also, APK size grows 1.5MB now.  But stylo team is working to remove
> old style system.

Is there a timeframe for when --disable-stylo will stop working? Will
it be supported in ESR 59?

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


Re: Fennec/Android turns on Quantum CSS (stylo) as default

2017-11-22 Thread Jet Villegas
Do you have a use case for shipping the ESR with --disable-stylo? We want
to be very quick about removing the legacy C++ style system as it adds
significant impedance to new feature development. I have not heard of any
site breakage that would warrant keeping --disable-stylo after Stylo is in
Fennec.

--Jet

On Wed, Nov 22, 2017 at 7:39 AM, Tom Ritter  wrote:

> On Wed, Nov 22, 2017 at 8:08 AM, Makoto Kato 
> wrote:
> > When enabling stylo, explicit memory will be 2-3% grow on Linux from
> > AWSY, so android will be same rate
> >
> > Also, APK size grows 1.5MB now.  But stylo team is working to remove
> > old style system.
>
> Is there a timeframe for when --disable-stylo will stop working? Will
> it be supported in ESR 59?
>
> -tom
> ___
> 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: Fennec/Android turns on Quantum CSS (stylo) as default

2017-11-22 Thread Tom Ritter
On Wed, Nov 22, 2017 at 9:51 AM, Jet Villegas  wrote:
> Do you have a use case for shipping the ESR with --disable-stylo? We want to
> be very quick about removing the legacy C++ style system as it adds
> significant impedance to new feature development. I have not heard of any
> site breakage that would warrant keeping --disable-stylo after Stylo is in
> Fennec.

Without --disable-style, Tor hits
https://bugzilla.mozilla.org/show_bug.cgi?id=1390583 and is in a bad
position.

Hope is to have this fixed by ESR 59, but it's a difficult issue to
work through.

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


Re: Fennec/Android turns on Quantum CSS (stylo) as default

2017-11-22 Thread Tom Prince
On Wed, Nov 22, 2017 at 8:51 AM Jet Villegas  wrote:

> Do you have a use case for shipping the ESR with --disable-stylo?
>

Thunderbird in a similar position to Tor. Our current build system is on
fairly old infrastructure that has issues compiling stylo. I'm busy porting
it to taskcluster, and hope to have it ready for ESR59, but it would give
me peace of mind if the old system was still working when ESR59 branched.

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


Re: Fennec/Android turns on Quantum CSS (stylo) as default

2017-11-22 Thread Emilio Cobos Álvarez
On 11/22/2017 05:15 PM, Tom Ritter wrote:
> On Wed, Nov 22, 2017 at 9:51 AM, Jet Villegas  wrote:
>> Do you have a use case for shipping the ESR with --disable-stylo? We want to
>> be very quick about removing the legacy C++ style system as it adds
>> significant impedance to new feature development. I have not heard of any
>> site breakage that would warrant keeping --disable-stylo after Stylo is in
>> Fennec.
> 
> Without --disable-style, Tor hits
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390583 and is in a bad
> position.
> 
> Hope is to have this fixed by ESR 59, but it's a difficult issue to
> work through.

Have you tried recently? There's a bunch of work that happened in bug
1341234 and related bugs, which fix similar issues to the ones you were
having I think.

I'm happy to help on bindgen's side if there are fixes needed, same for TB.

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


About --disable-stylo [was: Re: Fennec/Android turns on Quantum CSS (stylo) as default]

2017-11-22 Thread Sylvestre Ledru


On 22/11/2017 17:25, Tom Prince wrote:
> On Wed, Nov 22, 2017 at 8:51 AM Jet Villegas  wrote:
>
>> Do you have a use case for shipping the ESR with --disable-stylo?
>>
> Thunderbird in a similar position to Tor. Our current build system is on
> fairly old infrastructure that has issues compiling stylo. I'm busy porting
> it to taskcluster, and hope to have it ready for ESR59, but it would give
> me peace of mind if the old system was still working when ESR59 branched.
>
Even if we end up keeping the option and the legacy code,
you won't get any testing of the old code path from Firefox pre-release
channels.
This might be risky for Tb & tor.

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


Re: About --disable-stylo [was: Re: Fennec/Android turns on Quantum CSS (stylo) as default]

2017-11-22 Thread Tom Ritter
On Wed, Nov 22, 2017 at 10:36 AM, Sylvestre Ledru  wrote:
>
>
> On 22/11/2017 17:25, Tom Prince wrote:
>> On Wed, Nov 22, 2017 at 8:51 AM Jet Villegas  wrote:
>>
>>> Do you have a use case for shipping the ESR with --disable-stylo?
>>>
>> Thunderbird in a similar position to Tor. Our current build system is on
>> fairly old infrastructure that has issues compiling stylo. I'm busy porting
>> it to taskcluster, and hope to have it ready for ESR59, but it would give
>> me peace of mind if the old system was still working when ESR59 branched.
>>
> Even if we end up keeping the option and the legacy code,
> you won't get any testing of the old code path from Firefox pre-release
> channels.
> This might be risky for Tb & tor.

I've been (slowly) working on getting unit tests working for our MinGW
build with some herculean help from dmajor. Current status is that I
need to debug and dig into
https://bugzilla.mozilla.org/show_bug.cgi?id=1411401#c10

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


Re: Intent to implement: scroll-boundary-behavior

2017-11-22 Thread Botond Ballo
For those following along, please note that this CSS property has been
renamed from 'scroll-boundary-behavior' to 'overscroll-behavior'.

The spec is accordingly now at [1], and the preference for controlling
the feature has changed correspondingly.

Cheers,
Botond

[1] https://wicg.github.io/overscroll-behavior/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to remove: WebVR on insecure contexts

2017-11-22 Thread Kearwood Kip Gilbert
Summary: 
WebVR on insecure contexts (i.e. web sites served over non-HTTPS) is deprecated 
and will soon stop working in Firefox. 

Sites wanting to use WebVR should switch to HTTPS if they have not already. 

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

Link to standard: 
https://w3c.github.io/webvr/spec/1.1/

WebVR is a powerful feature that exposes sensor inputs that can capture 
biometric data (ie. distance of eyes to ground when user is standing).  
Immersive WebVR sites must be inherently trusted with this information.  The 
risks are greater if the transport is not encrypted.

Timeframe: 
We will immediately remove WebVR on insecure origins in FF59’s Nightly.  This 
should give developers some time to test their sites in Nightly until it rides 
the trains to FF59 in release.  WebVR is enabled by default in release FF57 and 
can be used to access insecure sites until they are updated.


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


Intent to ship: webvtt region

2017-11-22 Thread bechen
We are going to enable the webvtt region preference soon. It is a very useful 
feature for the developer/content provider to place the caption in a specific 
area(region). And in the feature, we can apply css styles on it.

Related Bugs:
Bug 1415821 - [webvtt] support multi-line region parsing.
Bug 1338030 - [webvtt] implement the region functionality.
Bug 1415805 - [webvtt] enable region preference

Link to standard:
https://w3c.github.io/webvtt/#regions

Platform coverage:
All platforms

Target release:
Hopefully, FF59.

Preference behind which this is implemented:
"media.webvtt.regions.enabled"

Do other browser engines implement this?
Safari (I need to confirm)

Tests: WPT tests

Next:
1. The "1smooth scroll up" feature of region we are not implement yet. We need 
some works to achieve that which required by live caption.
Bug 1416143 - [webvtt] region scroll up functionality.
2. cue-region pseudo element
Bug 1338031 - [webvtt] implement the ::cue-region pseudo element
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Hiding 'new' statements - Good or Evil?

2017-11-22 Thread gsquelart
Should we allow hiding 'new' statements, or keep them as visible as possible?


Some context:
Recently in bug 1410252 I added a MakeNotNull(args...) function that does 
`NotNull(new T(args...))`, in the style of MakeUnique and others. It also 
works with RefPtr.

My first goal was to avoid the unnecessary nullptr-check in the NotNull 
constructor, since our new is infallible by default.

And I thought that hiding the naked new statement was a nice side benefit, as I 
was under the impression that it was A Good Thing in modern C++. (Though I 
think the main reason for that, was to prevent leaks when handling exceptions 
in multi-allocation expressions, so it doesn't apply to us here.)

Now, a colleague remarked that this was making the memory allocation less 
obvious.
"What about MakeUnique?" I asked; "I'm used to them now" he retorted. :-P


So, what do you all think?
- Should I remove MakeNotNull?
- Or should we allow/encourage more MakeX functions instead of X(new...)? I'm 
thinking MakeRefPtr might be nice.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform