Re: Intent to implement: CSS {background,mask}-repeat-{x/y} properties

[Tommy Kuo]

Hi Mike, 

There is a site[1] using these properties. And the related bug is here[2].

[1]: http://ocando.vnz.la/
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1273244

-- 
Tommy Kuo / Software Engineer
ku...@mozilla.com

Mozilla Taiwan


On December 16, 2016 at 05:18:36, Mike Taylor (mi...@mozilla.com) wrote:

[3]: http://ocando.vnz.la/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Eric Rescorla]

It seems pretty premature in this process to trying to hack around the API
not expressing what we wanted to make. If what we want to express is "is
this link free" then let's make the API say that.

-Ekr


On Thu, Dec 15, 2016 at 4:17 PM, Martin Thomson  wrote:

> On Fri, Dec 16, 2016 at 10:28 AM, Boris Zbarsky  wrote:
> > 2)  Figure out a way to map the one bit of information we actually want
> to
> > expose into some sort of values that look like the existing API. Change
> the
> > spec as needed to allow tweaks we want to make here (e.g. to allow having
> > the max speed thing not be defined or always be 0 or always +Infinity, or
> > always NaN, or always 42 or something).
>
> Patrick suggested that we send a fixed downlink (+Infinity is always
> correct by the spec) always and use wifi/cellular.  I assume that we
> need to pick one of those in the case that we can't/don't know, but I
> like that plan.
>
> We could create a new API as well, but I'm not sure what it would *do*.
> ___
> 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: Rust required to build Gecko

[Ralph Giles]

Today we've pushed the change to enable rust language code by default
in Firefox builds. The changes are on the autoland branch right now,
so this will affect your builds from mozilla-central or gecko-dev
starting tomorrow. This brings our default developer build in line
with what we've been doing with official builds. Thanks to everyone
who helped make this happen.

As a reminder, you'll now need `rustc` and `cargo` in the PATH of your
build environment, just like with python and the C/C++ compiler. You
can install rust with `./mach bootstrap`. After that you can stay on
the latest stable release by running `rustup update` every 6 weeks or
so. If you want more control I recommend manually running the
installer and update tool from https://rustup.rs/

More information about using Rust code in Firefox can be found at
https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code

Cheers,
 -r


On Thu, Nov 24, 2016 at 2:49 PM, Ralph Giles  wrote:
> tl;dr This is a heads-up that all gecko developers should install rust.
>
> Next week I plan to switch our default build config to require Rust
> when building Firefox.[1] If you compile Firefox from the C++ source,
> please install the Rust language environment now.
>
> You can install Rust by running `./mach bootstrap` which will download
> and run the rustup installer for you.[2]
>
> We recommend the installer at https://rustup.rs/ (despite being beta)
> because it makes staying up to date and cross-compilation easy. If you
> want more control, or to experiment with rust, you can install
> directly from that website.
>
> The main thing is to have up-to-date versions of the `rustc` and
> `cargo` executables in the path of your build shell. Rust releases
> every six weeks, just like Firefox, and we generally require the
> latest stable release to compile mozilla-central. You can stay current
> by running `rustup update`.
>
> You'll still be able to build without a rust compiler by adding:
>
>   ac_add_options --disable-rust
>
> to your mozconfig. This is a temporary work-around; we expect to
> remove that option and require Rust unconditionally early next year as
> non-optional features start to depend on it.
>
> Rust language in Gecko is an important part of Project Quantum. I'm
> excited to be taking this next step toward that future. We first
> shipped Rust code to users in Firefox 48, so it's long past time this
> aspect of our default builds matched what we release.[3]
>
> Thanks for your attention,
>  -r
>
> [1] Enabling rust is https://bugzil.la/1283898
> [2] bootstrap support landed Tuesday in https://bugzil.la/1286799
> [3] If you have issues with the installer or build, please file issues
> blocking our tracking bug at https://bugzil.la/oxidation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Martin Thomson]

On Fri, Dec 16, 2016 at 10:28 AM, Boris Zbarsky  wrote:
> 2)  Figure out a way to map the one bit of information we actually want to
> expose into some sort of values that look like the existing API. Change the
> spec as needed to allow tweaks we want to make here (e.g. to allow having
> the max speed thing not be defined or always be 0 or always +Infinity, or
> always NaN, or always 42 or something).

Patrick suggested that we send a fixed downlink (+Infinity is always
correct by the spec) always and use wifi/cellular.  I assume that we
need to pick one of those in the case that we can't/don't know, but I
like that plan.

We could create a new API as well, but I'm not sure what it would *do*.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Boris Zbarsky]

On 12/15/16 6:15 PM, Ehsan Akhgari wrote:

(I personally agree with most of what you said, except that I'm
convinced that we should expose that one bit.)


Exposing this one bit makes a lot of sense to me.


From a more practical perspective, we have two shipping implementations
of this API.  What are you proposing to do with that for starters?


After we finish crying?  I think we fundamentally have two options:

1)  Create a new API, convince everyone to ship it and deprecate the 
other thing, and eventually hopefully remove it.


2)  Figure out a way to map the one bit of information we actually want 
to expose into some sort of values that look like the existing API. 
Change the spec as needed to allow tweaks we want to make here (e.g. to 
allow having the max speed thing not be defined or always be 0 or always 
+Infinity, or always NaN, or always 42 or something).



Note that Chrome has some use counters on this API:


Right, those are all above their removal thresholds.  But I should note 
that we've recently removed other things with high use counters once we 
determined that a lot of that was from tracking scripts...  That said, 
the NetInfoOnChange counter is not likely to be tracking script.


I assume this is just data from Chrome, not webviews?

-Boris

P.S.  I wish our DOM counters had a display like this, both in terms of 
searchability and performance.  :(

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

Re: Intent to ship: NetworkInformation

[Ehsan Akhgari]

On 2016-12-15 2:53 PM, Boris Zbarsky wrote:
> On 12/15/16 2:39 PM, Ehsan Akhgari wrote:
>> FWIW I was one of the people who were involved in the discussions around
>> this for Firefox OS.  From what I remember, the argument for shipping
>> this API was that web developers have been asking for this for years,
>> and they are basically happy to know the distinction between cellular
>> data and other transports, and infer whether the connection "costs
>> money".
> 
> OK.  That does seem like a useful thing to expose, but it's precisely
> one bit of information, right?

Yes.

> Why are we exposing all this other stuff
> instead?

I'm not personally trying to advocate for this API, I was merely
reflecting the other side of the conversation from my memory.

(I personally agree with most of what you said, except that I'm
convinced that we should expose that one bit.)

>From a more practical perspective, we have two shipping implementations
of this API.  What are you proposing to do with that for starters?

Note that Chrome has some use counters on this API:

* https://www.chromestatus.com/metrics/feature/popularity#NetInfo
* https://www.chromestatus.com/metrics/feature/popularity#NetInfoType
*
https://www.chromestatus.com/metrics/feature/popularity#NetInfoOnTypeChange
* https://www.chromestatus.com/metrics/feature/popularity#NetInfoOnChange
*https://www.chromestatus.com/metrics/feature/popularity#NetInfoDownlinkMax
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[smaug]

On 12/15/2016 09:53 PM, Boris Zbarsky wrote:

On 12/15/16 2:39 PM, Ehsan Akhgari wrote:

FWIW I was one of the people who were involved in the discussions around
this for Firefox OS.  From what I remember, the argument for shipping
this API was that web developers have been asking for this for years,
and they are basically happy to know the distinction between cellular
data and other transports, and infer whether the connection "costs
money".


OK.  That does seem like a useful thing to expose, but it's precisely one bit 
of information, right?  Why are we exposing all this other stuff instead?

-Boris



Even "costs money" based on the transport type is very unreliable. Coming from 
a country where basically all the mobile data plans
are unlimited (and cheap), it mostly just annoys when some OSes warn about use of mobile data to download lots of data (like updates) because of its 
possible cost. Rather bad UX.

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

Re: Intent to ship: NetworkInformation

[Tantek Çelik]

On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky  wrote:
> On 12/15/16 12:20 PM, Ben Kelly wrote:
>>
>> Its more information than nothing.
>
>
> I'm not sure it is.  At least when you have nothing you _know_ you have
> nothing, so might think about other ways to find out what you want to know.
> This way you think you know something but you don't.

Agreed with Boris. "more information than nothing" is not an absolute
value, when that information is deceiving, which as others have
pointed out in this thread, is quite likely to occur with non-trivial
frequency in common uses of this API (the "if bandwidth>x then slow
download" example proves this point).

E.g. a high % of the time, (most of the time when I'm not at home or
work), I am on a 4G (high bandwidth) mifi (metered cost).

This API would report misleading results for me 100% of the time I am
on my mifi, and for anyone else on a 4G mifi.

Real experience, all (AFAIK) the "sync to cloud automatically" code
out there makes this mistake, e.g. iCloud, DropBox etc., so I've had
to turn all of it off or just not use it.

Let's learn from the error of "native" implementations/uses of this
kind of API / use thereof and not repeat that mistake on web,
certainly not ship an API that misleads web developers into doing the
wrong thing.


>> Bluetooth networking is also a thing.
>
>
> That's a good point.
>
>> I think being able to distinguish this stuff provides some value even if
>> its not perfect for all cases.  And I don't see how it causes any harm.
>
>
> I think it causes harm to give people information they have no business
> having ("wifi" vs "ethernet") and it does harm to given them information
> that's likely to be bogus (the last hop speed in the wifi/ethernet cases).

Precisely. Obvious harms:

1. Privacy compromise without obvious user benefit
2. Causes web apps to waste user bandwidth/financial resources

If the response to that is "but doing it right is too hard", then
don't do it all.

> Maybe the answer is that we should just reconsider the set of types that
> gets exposed and how they get mapped to connection speeds

I'm not sure that would sufficiently address harm 2.

As far as I can tell, the only useful bit of information (as bz
pointed out) is the

Am I on a cell data connection "for sure or maybe not"?
a) Where cell data "for sure" -> will *almost certainly cost the user*
b) Whereas "or maybe not" -> you have no idea whether it will cost the
user or not, do not make any assumptions.

Given that the one pseudo-code example provided earlier in this thread
makes the mistake of using case (b) to errantly initiate bandwidth/$
wasting downloads (which may not even be necessary), I think this API
has not been well thought through in terms of actual user benefit, and
needs further incubation.

Not to mention we shouldn't even be getting to an "Intent to *ship*"
on something we expect to standardize that hasn't even been published
as a FPWD yet (which only *starts* the count-down clock to IPR
commitment).

Implementing behind a flag should be good enough for prototyping
purposes to advocate for moving this from WICG to WPWG, and if that
transition doesn't happen for whatever reason it's a very clear sign
the tech is insufficiently incubated (or otherwise problematic) and we
shouldn't be shipping this. We're not even at that point yet!

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

Re: WoT Gateway Implementation

[Benjamin Francis]

Oops, I sent this to the wrong platform list :)

Moving to mozilla.dev@mozilla.org

On 15 December 2016 at 11:57, Benjamin Francis  wrote:

> Hi,
>
> In the last platform meeting
> 
> we talked about kicking off the implementation of some of the key
> components of the platform, one of which is the WoT gateway implementation.
> As HomeWeb will initially be the main (only) consumer of this component, I
> wanted to make a suggestion about its implementation.
>
> We already have the fxbox  source code to use
> as a starting point, but before we just go ahead and fork all those
> repositories under http://github.com/moziot/ (the new home of the
> platform source code?) I'd like to suggest that we use the right tools for
> the right jobs:
>
>- Protocol adaptors - Rust
>- WoT API - NodeJS
>
> Reasons for using Rust for Protocol Adaptors:
>
>- Protocol adaptors (or whatever we end up calling them) are
>essentially hardware drivers that talk to an underlying hardware component
>(e.g. a ZigBee/ZWave/Bluetooth radio over a UART connection). This is
>exactly the type of systems programming use cases that Rust was designed
>for.
>- This low level work is particularly performance and timing sensitive
>and these requirements justify the overhead of using/learning and
>cross-compiling a low level language.
>- Rust is a modern and safe programming language which happens to be
>maintained by Mozilla, which means we can add features that are missing and
>improve it where necessary (we already added support for a new ARM chipset
>on the HomeWeb project).
>
> Reasons for using Node for WoT APIs:
>
>- NodeJS is now a very popular language for server side web
>development and has a huge existing community and collection of modules to
>draw from. Using NodeJS will help attract community contribution from web
>developers who can easily add their own modules when hacking on the 
> project.
>- By comparison Rust is still relatively immature as a language for
>web development as you can read about here
>. It's likely that our platform will need
>to interact with a large range of existing software and services,
>especially once third parties start to use it for their own projects. Rust
>may hold us back here while we wait for it to mature.
>- SensorWeb already started implementing the SensorThings API in
>NodeJS. I'd suggest we will eventually want to share code between the cloud
>and gateway WoT API  implementations.
>
> Using Rust for low level components and NodeJS for the WoT API seems to me
> like a good compromise and has a parallel in Gecko where we use both
> C++/Rust and JavaScript for different jobs.
>
> However, using two separate languages comes at a cost (both cognitive and
> complexity-wise). I personally have zero experience of writing Rust and
> while I know it's possible
> 
> to call Rust components from NodeJS I've never actually done it. I'm
> interested to hear other peoples' views on this (without descending into
> needless bikeshedding or a holy war!), particularly if anyone has
> experience of using these two languages together. How feasible is this?
>
> Ben
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS {background,mask}-repeat-{x/y} properties

[Mike Taylor]

Hi Tommy,

On 11/27/16 9:59 PM, Tommy Kuo wrote:

Currently, for web compatibility, I think we should implement these properties.


Do we know about any sites that are broken due to background-repeat-x/y?

(apologies in advance if you link to a bug that has me commenting on it...)

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Boris Zbarsky]

On 12/15/16 12:20 PM, Ben Kelly wrote:

Its more information than nothing.


I'm not sure it is.  At least when you have nothing you _know_ you have 
nothing, so might think about other ways to find out what you want to 
know.  This way you think you know something but you don't.



Bluetooth networking is also a thing.


That's a good point.


I think being able to distinguish this stuff provides some value even if
its not perfect for all cases.  And I don't see how it causes any harm.


I think it causes harm to give people information they have no business 
having ("wifi" vs "ethernet") and it does harm to given them information 
that's likely to be bogus (the last hop speed in the wifi/ethernet cases).


Maybe the answer is that we should just reconsider the set of types that 
gets exposed and how they get mapped to connection speeds


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

Re: Intent to ship: NetworkInformation

[Boris Zbarsky]

On 12/15/16 2:39 PM, Ehsan Akhgari wrote:

FWIW I was one of the people who were involved in the discussions around
this for Firefox OS.  From what I remember, the argument for shipping
this API was that web developers have been asking for this for years,
and they are basically happy to know the distinction between cellular
data and other transports, and infer whether the connection "costs
money".


OK.  That does seem like a useful thing to expose, but it's precisely 
one bit of information, right?  Why are we exposing all this other stuff 
instead?


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

Re: Intent to ship: NetworkInformation

[Ehsan Akhgari]

On 2016-12-15 11:14 AM, Boris Zbarsky wrote:
> On 12/15/16 11:00 AM, Ben Kelly wrote:
>> We are shipping the connection type information on android already. 
>> Since
>> FF32 as far as I can tell.
> 
> That's... not great.  Especially since there was no intent to ship at
> the time.

FWIW Chromium also ships this API on Android and ChromeOS:
.
 It seems that they ship both the type and typechange events:
.

FWIW I was one of the people who were involved in the discussions around
this for Firefox OS.  From what I remember, the argument for shipping
this API was that web developers have been asking for this for years,
and they are basically happy to know the distinction between cellular
data and other transports, and infer whether the connection "costs
money".  On Android at least native apps also use the same crude
measure.  I think there was also an argument around the lines of asking
this being so common that a subset of users who actually do have paid
cellular data plans are used to rely on this distinction.

The limitations of this API and how little meaning it is actually
conveying to the developers was generally well understood, but the
counter argument for that would be that it's pretty clear we're never
going to be able to give the app accurate information unless we know
about what servers they want to talk to, and perhaps other load
characteristics, and even then we'd probably need to measure the
bandwidth, which could cost money, defeating the whole purpose; and with
that in mind, it's better to expose something now rather than nothing.

I have to say I personally don't find the last argument reasonable for
downlinkMax, but I can understand it for type.

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

Re: Intent to ship: NetworkInformation

[Ehsan Akhgari]

On 2016-12-15 11:14 AM, Boris Zbarsky wrote:
> On 12/15/16 11:00 AM, Ben Kelly wrote:
>> We are shipping the connection type information on android already. 
>> Since
>> FF32 as far as I can tell.
> 
> That's... not great.  Especially since there was no intent to ship at
> the time.

FWIW Chromium also ships this API on Android and ChromeOS:
.
 It seems that they ship both the type and typechange events:
.

FWIW I was one of the people who were involved in the discussions around
this for Firefox OS.  From what I remember, the argument for shipping
this API was that web developers have been asking for this for years,
and they are basically happy to know the distinction between cellular
data and other transports, and infer whether the connection "costs
money".  On Android at least native apps also use the same crude
measure.  I think there was also an argument around the lines of asking
this being so common that a subset of users who actually do have paid
cellular data plans are used to rely on this distinction.

The limitations of this API and how little meaning it is actually
conveying to the developers was generally well understood, but the
counter argument for that would be that it's pretty clear we're never
going to be able to give the app accurate information unless we know
about what servers they want to talk to, and perhaps other load
characteristics, and even then we'd probably need to measure the
bandwidth, which could cost money, defeating the whole purpose; and with
that in mind, it's better to expose something now rather than nothing.

I have to say I personally don't find the last argument reasonable for
downlinkMax, but I can understand it for type.

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

Re: Intent to ship: NetworkInformation

[Patrick McManus]

Hi All -

Generally speaking releasing more information about what's behind the
firewall is an anti-goal. I have the same reaction others in this thread
have - this api is much more information than what is really needed, and
the information it provides is of questionable usefulness anyhow.

The design choice on the server often seems to want to know "is this data
metered or not" - which clearly has utility. There are many algorithms in
necko I want to apply the same criteria to. I'm still kind of queasy about
leaking this but if dan, or richard, or ekr who are all sufficiently
cynical about such things thought it was ok I would feel better about that
much.

But the performance variance of what 3g vs 4g vs wifi vs wired actually
means in any instance is so broad and has so much overlap that its simply
not a useful performance input. And as long as you're using constant
numbers from a table, there really is little you can do with certainty
about that other than maybe segregating 2g/bt from everything else.. even
that conclusion might be bogus.

Further, end to end bandwidth prediction simply does not exist with any
specificity - if it did the work of congestion controllers would be
un-necessary. Folks in this thread have talked about bridges, vpns, etc,
and that's just part of the story. The spec side steps that by assuming the
last mile is the bottleneck link, that the last mile is otherwise unused,
and assuming weirdly that multipath is a normal thing. That's handy for the
spec, but doesn't bear much on reality while it leaks local information.
Indeed it ignores the fundamental organization of IP networks as packet
switched connections of networks of varying types. (give me a POTS line I
hear you crying - but even that is likely faked circuit switching on voip
now).

>From an implementation pov, the browser could over time give a reasonable
metric about latency and bandwidth 'to the internet' just through passive
observation.. maybe as a 3x3 l/m/h matrix. but this would be for the client
in general and not really for the path between the client and the origin -
the latter is really what the origin wants. Without adding per-origin
overhead of a new speed test I would think the ResourceTiming already
available to it would be as good of a guide as anything else. So even
though it would be a cool engineering task to look at this whole-browser,
its of questionable utility imo.. and doing so leaks performance
observations cross-origin.

I guess the other thing I would want to consider here is the competitive
aspect of this API, but I wouldn't feel obligated to ship it for checklist
reasons.

tl;dr; is the metered-data bit enough and if so, can we just implement this
by always returning 1 of 2 configs (cell vs wifi e.g.) with const bw?

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

Re: WoT Gateway Implementation

[Fabrice Desre]

On 12/15/2016 03:57 AM, Benjamin Francis wrote:



Reasons for using Node for WoT APIs:

   - NodeJS is now a very popular language for server side web development
   and has a huge existing community and collection of modules to draw from.
   Using NodeJS will help attract community contribution from web developers
   who can easily add their own modules when hacking on the project.


What kind of module are you talking about here? Are they different from 
the adapters written in Rust? In Foxbox, when you write an adapter, you 
don't need to write a singe line of code to get it exposed as a Rest 
API. It's all taken care of by the taxonomy router 
(https://github.com/fxbox/foxbox/blob/master/src/taxonomy_router.rs) 
based on what is exposed by the adapter. Adapters implement a well 
defined interface, and we derive the Rest part from that. This is 
limiting risks of heterogeneous APIs, and provides a clear separation of 
concerns. For instance, the rules engine also rely on the same internal 
interfaces, without needing to go through the Rest API.



   - By comparison Rust is still relatively immature as a language for web
   development as you can read about here .
   It's likely that our platform will need to interact with a large range of
   existing software and services, especially once third parties start to use
   it for their own projects. Rust may hold us back here while we wait for it
   to mature.


Not sure which kind of service interactions you're talking about here. 
Can you elaborate or provide examples?



   - SensorWeb already started implementing the SensorThings API in NodeJS.
   I'd suggest we will eventually want to share code between the cloud and
   gateway WoT API  implementations.


I would be quite surprised if we were to reuse this SensorThings 
implementation in a gateway. But happy to hear that you consider 
SensorThings to be WoT compliant ;)


Fabrice

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

Re: WoT Gateway Implementation

[jedireza]

On Thursday, December 15, 2016 at 3:57:50 AM UTC-8, Benjamin Francis wrote:
> However, using two separate languages comes at a cost (both cognitive and
> complexity-wise). I personally have zero experience of writing Rust and
> while I know it's possible
> 
> to call Rust components from NodeJS I've never actually done it. I'm
> interested to hear other peoples' views on this (without descending into
> needless bikeshedding or a holy war!), particularly if anyone has
> experience of using these two languages together. How feasible is this?
> 
> Ben

There is the Neon project[1]. Neon makes writing native Node.js modules (in 
Rust) possible. As noted on the website, it's a work in progress and there are 
some important things to finish[2] to fulfill the "hack without fear" promise, 
but the mechanics are there.

[1] https://www.neon-bindings.com/
[2] https://github.com/neon-bindings/neon/issues/144
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Jonathan Kew]

On 15/12/2016 17:20, Ben Kelly wrote:

On Thu, Dec 15, 2016 at 12:06 PM, Boris Zbarsky  wrote:


On 12/15/16 11:23 AM, Ben Kelly wrote:


if (navigator.connect.downlinkMax > 100) {
  // perform low-priority background downloads
}



Why is the downlinkMax the right thing to be checking here, though? Again,
outside of the "cellphone on a cell network" case, the last-hop bandwidth
tells you pretty much nothing because it's incredibly unlikely that the
last hop is the bottleneck.



Its more information than nothing.


But if it is seriously inaccurate or misleading information (e.g. it 
suggests a fast connection, when the "fast" last-hop is just my laptop 
being tethered to a cellphone that has a slow, expensive connection), 
then it may be worse than nothing.



 And saying its a limit on the maximum
is accurate.  And its a value that can become more accurate over time with
better OS and network integration.


Not necessarily, if it is explicitly spec'd to refer to the speed of the 
last hop. ("The spec is pretty clearly written to specify maximum 
possible downlink given the first hop interface.")



Code using the API gets that for free
without changing anything.  If it special cases on "cellular" or "wifi",
then it has to update its list if a new networking type is introduced in
the future.


If better network integration means that in future, we can reliably 
report the overall bandwidth of the connection to a given server (for 
example), or the cost per byte transferred (perhaps more interesting, in 
many cases), that would presumably be exposed via a new API, not by 
redefining what this API does. But that means code doesn't "get that for 
free", it will need to be updated.




I agree that for the "cellphone on a cell network" case the last-hop

bandwidth can be useful.



Bluetooth networking is also a thing.

I think being able to distinguish this stuff provides some value even if
its not perfect for all cases.  And I don't see how it causes any harm.


It causes harm if it (mis)leads a site/web-app into doing things -- such 
as large downloads over a metered connection, because the last hop 
happens to look fast -- that are not appropriate for the true nature of 
the user's connection.


Arguably, it might be better to not expose such potentially misleading 
information at all; then such a site or app would not be tempted to rely 
on it, and would have to find an alternative approach (perhaps simply 
asking the user "do you want to download X megabytes of stuff?").


JK

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

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 12:06 PM, Boris Zbarsky  wrote:

> On 12/15/16 11:23 AM, Ben Kelly wrote:
>
>> if (navigator.connect.downlinkMax > 100) {
>>   // perform low-priority background downloads
>> }
>>
>
> Why is the downlinkMax the right thing to be checking here, though? Again,
> outside of the "cellphone on a cell network" case, the last-hop bandwidth
> tells you pretty much nothing because it's incredibly unlikely that the
> last hop is the bottleneck.
>

Its more information than nothing.  And saying its a limit on the maximum
is accurate.  And its a value that can become more accurate over time with
better OS and network integration.  Code using the API gets that for free
without changing anything.  If it special cases on "cellular" or "wifi",
then it has to update its list if a new networking type is introduced in
the future.

I agree that for the "cellphone on a cell network" case the last-hop
> bandwidth can be useful.


Bluetooth networking is also a thing.

I think being able to distinguish this stuff provides some value even if
its not perfect for all cases.  And I don't see how it causes any harm.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Boris Zbarsky]

On 12/15/16 11:23 AM, Ben Kelly wrote:

if (navigator.connect.downlinkMax > 100) {
  // perform low-priority background downloads
}


Why is the downlinkMax the right thing to be checking here, though? 
Again, outside of the "cellphone on a cell network" case, the last-hop 
bandwidth tells you pretty much nothing because it's incredibly unlikely 
that the last hop is the bottleneck.


I agree that for the "cellphone on a cell network" case the last-hop 
bandwidth can be useful.


-Boris

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

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 11:14 AM, Boris Zbarsky  wrote:

> OK, so how would one use this API in practice?


if (navigator.connect.downlinkMax > 100) {
  // perform low-priority background downloads
}
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Boris Zbarsky]

On 12/15/16 11:00 AM, Ben Kelly wrote:

What is an IPR commitment?


IPR == "intellectual property rights".  In the context of specs, mostly 
patent issues.



It seems we can implement WPT tests.  I don't know what you consider "an
actual spec"


Well, something that gets a wider look than WICG things get, has 
multiple implementations, has tests, goes through the general spec 
stabilization process to make sure everyone is on the same page, etc.



We are shipping the connection type information on android already.  Since
FF32 as far as I can tell.


That's... not great.  Especially since there was no intent to ship at 
the time.



The downlink max bandwidth would be just a lookup table from the type info
in our implementation.


I should note that this is pretty useless as a metric for anything 
outside maybe cell phones that are actually on a cell network.  My 
connection type right this moment would presumably come back as "wifi" 
and and right this second I'm on an "n" network so we would claim 
600Mbit/s.  Except my actual wifi connection is at 217Mbit/s, and my 
actual connection to anything at all useful (i.e. not the router sitting 
on my bookshelf) is no more than 60Mbit/s.  Of what possible use is the 
"600Mbit/s" number to anyone?


Oh, and any moment now my WiFi connection can switch to the same-SSID 
"ac" network, and that "600" would change to "6933.3", except my "ac" 
network only goes to "1300"...



Also, I'm not sure how transient data like connection type really helps
with fingerprinting too much compared to the other info already available
to fingerprint.


I'm not talking about fingerprinting, but about general privacy leaks. 
Things like "oh, this user is on 10G ethernet, must be at a university" 
or "Oh, they're on a brand-new cell network type only one company offers 
for ; must be rich".



The spec is pretty clearly written to specify maximum possible downlink
given the first hop interface.


Yes, I know that's what it specifies.  I just don't think this is the 
right thing to specify.



It does not make any claims about actual
total throughput.  I personally don't agree APIs like this need to provide
perfect information to provide value.


OK, so how would one use this API in practice?

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

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 8:42 AM, Boris Zbarsky  wrote:

> On 12/15/16 3:28 AM, Andrea Marchesini wrote:
>
>> Spec: https://w3c.github.io/netinfo/
>>
>
> Is there any plan to have this turned into an actual spec, complete with
> IPR commitments, testcases, wider review, etc?
>

What is an IPR commitment?

It seems we can implement WPT tests.  I don't know what you consider "an
actual spec", but I imagine if we show interest in implementing it will
graduate from WICG to its own w3c repo.


> Have we done a privacy review of this spec?  Why should a webpage ever
> know whether I'm connected via "ethernet" vs "wifi" (insofar as we have any
> way to determine this at all; I could be connected via "ethernet" to a
> bridge that is connected via "wifi")?
>

We are shipping the connection type information on android already.  Since
FF32 as far as I can tell.

The downlink max bandwidth would be just a lookup table from the type info
in our implementation.  It could be improved in the future, of course.

Also, I'm not sure how transient data like connection type really helps
with fingerprinting too much compared to the other info already available
to fingerprint.


> Looking at the use cases document at  etinfo-usecases/>, it seems like people generally care more about things
> like "bandwidth costs money" and "how much bandwidth do we expect?" than
> about the actual physical transport, no?
>

The spec is pretty clearly written to specify maximum possible downlink
given the first hop interface.  It does not make any claims about actual
total throughput.  I personally don't agree APIs like this need to provide
perfect information to provide value.

So, while I think we should implement this, I do have one concern.  We have
been shipping a `typechange` event on this API while the spec and chrome
use a `change` event.  If we start firing `change` as well, do we need to
still fire `typechange` for back-compat?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 3:28 AM, Andrea Marchesini 
wrote:

> Our implementation of the NetworkInformation interface does not follow the
> latest version of the spec. I'm planning to work on it. Then, I would like
> to enable this interface by default - currently it's behind pref.
>

I think we do enable it by default on android, but not desktop.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: OpenType Variation Fonts

[Patrick Brosset]

Here's the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1323743

On Thu, Dec 15, 2016 at 4:02 PM, Patrick Brosset 
wrote:

> The inspector in DevTools has a Fonts panel already. For now, it only
> lists the fonts currently used by the selected element. It can also list
> all fonts used on the page.
> We would love to make this panel more useful and expose things like
> variations. As Xidorn said, if we could have an API that lists those for
> us, then we could pretty easily add a UI to the panel that lets people
> explore the fonts.
> It sounds like that could be very useful.
>
> Finally, this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280162
> is about exposing OpenType features like ligature for a given font in the
> Fonts panel.
>
> And, related to this, we also have this bug: https://bugzilla.mozilla.org/
> show_bug.cgi?id=1280163 where we would like to have the Fonts panel list
> all the glyphs that a font contains.
>
> I'll file a specific bug for the variations technology and will cc
> Jonathan.
>
> Thanks,
> Patrick
>
>
> On Tue, Dec 6, 2016 at 8:30 PM, Jonathan Kew  wrote:
>
>> On 06/12/2016 19:04, Xidorn Quan wrote:
>>
>>> On Tue, Dec 6, 2016, at 01:28 AM, Jonathan Kew wrote:
>>>
 DevTools bug: It's not yet clear to me whether specific DevTools work
 will be needed, beyond the support we'll automatically get for a new CSS
 property.

>>>
>>> I think DevTools may want to display a panel which lists all available
>>> variation axis supported by the font, and allow developers to adjust
>>> them.
>>>
>>
>> Yes, perhaps something like that would be useful. Though we don't do
>> anything along those lines for OpenType font features at present. If
>> DevTools is to start exposing details of "font capabilities", both features
>> and variations should be treated similarly.
>>
>> I think that makes it a broader topic, not directly linked to variations,
>> which would be just one among various details that could be exposed via a
>> DevTools "font inspector".
>>
>> JK
>>
>>
>> ___
>> 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: OpenType Variation Fonts

[Patrick Brosset]

The inspector in DevTools has a Fonts panel already. For now, it only lists
the fonts currently used by the selected element. It can also list all
fonts used on the page.
We would love to make this panel more useful and expose things like
variations. As Xidorn said, if we could have an API that lists those for
us, then we could pretty easily add a UI to the panel that lets people
explore the fonts.
It sounds like that could be very useful.

Finally, this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280162 is
about exposing OpenType features like ligature for a given font in the
Fonts panel.

And, related to this, we also have this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1280163 where we would like to
have the Fonts panel list all the glyphs that a font contains.

I'll file a specific bug for the variations technology and will cc Jonathan.

Thanks,
Patrick


On Tue, Dec 6, 2016 at 8:30 PM, Jonathan Kew  wrote:

> On 06/12/2016 19:04, Xidorn Quan wrote:
>
>> On Tue, Dec 6, 2016, at 01:28 AM, Jonathan Kew wrote:
>>
>>> DevTools bug: It's not yet clear to me whether specific DevTools work
>>> will be needed, beyond the support we'll automatically get for a new CSS
>>> property.
>>>
>>
>> I think DevTools may want to display a panel which lists all available
>> variation axis supported by the font, and allow developers to adjust
>> them.
>>
>
> Yes, perhaps something like that would be useful. Though we don't do
> anything along those lines for OpenType font features at present. If
> DevTools is to start exposing details of "font capabilities", both features
> and variations should be treated similarly.
>
> I think that makes it a broader topic, not directly linked to variations,
> which would be just one among various details that could be exposed via a
> DevTools "font inspector".
>
> JK
>
>
> ___
> 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 ship: NetworkInformation

[Daniel Stenberg]

On Thu, 15 Dec 2016, Boris Zbarsky wrote:

Looking at the use cases document at 
, it seems like people 
generally care more about things like "bandwidth costs money" and "how much 
bandwidth do we expect?" than about the actual physical transport, no?


Looking at that collection of existing user, basically all of them want the 
user to anser this question:


 "Use expensive traffic (y/n)"

so that they can avoid doing "unecessary" things while connected to a network 
that is "expensive". (Yes, it is a very binary answer but that is how it is 
used normally.)


They do phrase that question as asking for wifi, cellular or 2G/3G etc - even 
though it is not actually the type that makes the user click or unclick the 
checkboxes.


Also (add to the problems already mentioned), if you tether via wifi over your 
phone, are you on wifi or are you on cellular? In most of the use cases that's 
"expensive traffic" so you'd have to lie and say cellular even though this API 
will say wifi (I presume).


--

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

Re: Intent to ship: NetworkInformation

[Eric Rescorla]

On Thu, Dec 15, 2016 at 6:42 AM, Boris Zbarsky  wrote:

> On 12/15/16 3:28 AM, Andrea Marchesini wrote:
>
>> Spec: https://w3c.github.io/netinfo/
>>
>
> Is there any plan to have this turned into an actual spec, complete with
> IPR commitments, testcases, wider review, etc?
>
> Have we done a privacy review of this spec?  Why should a webpage ever
> know whether I'm connected via "ethernet" vs "wifi" (insofar as we have any
> way to determine this at all; I could be connected via "ethernet" to a
> bridge that is connected via "wifi")?
>

I'm also concerned that this spec does not seem to take into account
multipath or multihoming, both of which seem relevant here. Say that I have
a device with both a cellular and WiFi link and I attempt to use both of
them in some fashion (depending on the remote IP address), what should I be
reporting for Network Connection?

-Ekr




Looking at the use cases document at  etinfo-usecases/>, it seems like people generally care more about things
> like "bandwidth costs money" and "how much bandwidth do we expect?" than
> about the actual physical transport, no?
>
> -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: Intent to ship: NetworkInformation

[Boris Zbarsky]

On 12/15/16 3:28 AM, Andrea Marchesini wrote:

Spec: https://w3c.github.io/netinfo/


Is there any plan to have this turned into an actual spec, complete with 
IPR commitments, testcases, wider review, etc?


Have we done a privacy review of this spec?  Why should a webpage ever 
know whether I'm connected via "ethernet" vs "wifi" (insofar as we have 
any way to determine this at all; I could be connected via "ethernet" to 
a bridge that is connected via "wifi")?


Looking at the use cases document at 
, it seems like people 
generally care more about things like "bandwidth costs money" and "how 
much bandwidth do we expect?" than about the actual physical transport, no?


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

WoT Gateway Implementation

[Benjamin Francis]

Hi,

In the last platform meeting

we talked about kicking off the implementation of some of the key
components of the platform, one of which is the WoT gateway implementation.
As HomeWeb will initially be the main (only) consumer of this component, I
wanted to make a suggestion about its implementation.

We already have the fxbox  source code to use as
a starting point, but before we just go ahead and fork all those
repositories under http://github.com/moziot/ (the new home of the platform
source code?) I'd like to suggest that we use the right tools for the right
jobs:

   - Protocol adaptors - Rust
   - WoT API - NodeJS

Reasons for using Rust for Protocol Adaptors:

   - Protocol adaptors (or whatever we end up calling them) are essentially
   hardware drivers that talk to an underlying hardware component (e.g. a
   ZigBee/ZWave/Bluetooth radio over a UART connection). This is exactly the
   type of systems programming use cases that Rust was designed for.
   - This low level work is particularly performance and timing sensitive
   and these requirements justify the overhead of using/learning and
   cross-compiling a low level language.
   - Rust is a modern and safe programming language which happens to be
   maintained by Mozilla, which means we can add features that are missing and
   improve it where necessary (we already added support for a new ARM chipset
   on the HomeWeb project).

Reasons for using Node for WoT APIs:

   - NodeJS is now a very popular language for server side web development
   and has a huge existing community and collection of modules to draw from.
   Using NodeJS will help attract community contribution from web developers
   who can easily add their own modules when hacking on the project.
   - By comparison Rust is still relatively immature as a language for web
   development as you can read about here .
   It's likely that our platform will need to interact with a large range of
   existing software and services, especially once third parties start to use
   it for their own projects. Rust may hold us back here while we wait for it
   to mature.
   - SensorWeb already started implementing the SensorThings API in NodeJS.
   I'd suggest we will eventually want to share code between the cloud and
   gateway WoT API  implementations.

Using Rust for low level components and NodeJS for the WoT API seems to me
like a good compromise and has a parallel in Gecko where we use both
C++/Rust and JavaScript for different jobs.

However, using two separate languages comes at a cost (both cognitive and
complexity-wise). I personally have zero experience of writing Rust and
while I know it's possible

to call Rust components from NodeJS I've never actually done it. I'm
interested to hear other peoples' views on this (without descending into
needless bikeshedding or a holy war!), particularly if anyone has
experience of using these two languages together. How feasible is this?

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

Who loves multiple selection feature in editor?

[Masayuki Nakano]

At investigating selection API behavior, I realized that non-Gecko 
engines don't support multiple selection.


For example, document.getSelection().addRange(somethingNewRange) does 
nothing when the selection has a range.


You can see the behavior with following testcases:
1. in editable content: https://jsfiddle.net/d_toybox/9Lrs62po/3/
2. in static content: https://jsfiddle.net/d_toybox/9Lrs62po/2/

Personally, I like the multiple selection feature when I copy a lot of 
fragments of a document. However, who needs this feature in editor? 
Supporting multiple selection in editor makes our editor code 
complicated. For example, when web apps try to make the text content 
bold, editor needs to do it at every selection range. If selection is 
modified during handling something, loop for selection ranges may cause 
crash (I've seen a lot of similar crash bugs).


So, it might be better to stop supporting multiple selection only in 
editor if the feature is not so loved by users.


I filed a bug for discussing this issue here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1323681

Feel free to comment anything.

Thanks in advance.

--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: NetworkInformation

[Andrea Marchesini]

Our implementation of the NetworkInformation interface does not follow the
latest version of the spec. I'm planning to work on it. Then, I would like
to enable this interface by default - currently it's behind pref.

Related Bugs:
worker implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1323172
spec updates: https://bugzilla.mozilla.org/show_bug.cgi?id=1323658


Spec: https://w3c.github.io/netinfo/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Mask Image

[L. David Baron]

On Thursday 2016-12-15 15:05 +0800, Ku(顧思捷)CJ wrote:
> After bug 1251161 landed, we turned CSS mask image on by default on all
> platforms. It has been developed behind the MOZ_ENABLE_MASK_AS_SHORTHAND
> compile flag. Chrome  is already shipping this in version 29.
> 
> (Original plan is to turn it on by FF 50, delay it to FF 53 is because of
> some performance work, such as bug 1234485)
> 
> Related Bugs:
> META: https://bugzilla.mozilla.org/show_bug.cgi?id=1224422
> Blockers: https://bugzilla.mozilla.org/show_bug.cgi?id=1251161
> 
> Spec:
> https://drafts.fxtf.org/css-masking-1/
> 
> Target release:
> Firefox 53 (current Nightly).

What is being proposed to ship is only part of the spec, section 7
(Positioned Masks):
https://drafts.fxtf.org/css-masking-1/#positioned-masks
These are the masking properties that are analogous to the
background image properties.

We have no work ongoing on section 8 of the spec, which covers the
border-image style CSS masks (mask-border-*).  The priority of that
work isn't clear to me; I think it depends largely on how much
effort would be required given that we already have mask-image and
border-image.  I think (based on caniuse, which isn't incredibly
clear) that WebKit and Chromium implement both parts, and Edge
doesn't implement either part.


For other parts of the spec (less related to "mask images"), see the
spec's metabug:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=1312613=1_resolved=0


I'm in support of shipping this work, assuming that the performance
concerns that delayed it have been addressed.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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