Re: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Jet Villegas]

The New checker features look really promising. Yes, more of this stuff in
C++ is very welcome.

On Wed, May 23, 2018 at 1:53 PM, Chris Peterson 
wrote:

> On 2018-05-23 1:35 PM, Botond Ballo wrote:
>
>> There is also work being done in this area outside the formal
>> standards process, in the form of the C++ Core Guidelines [2] (some of
>> which can be checked statically) and the accompanying Guideline
>> Support Library [3], and in the form of Microsoft's lifetime checker
>> [4], though that seems to be progressing very slowly, and even though
>> I ask for an update at every meeting, I haven't seen much of substance
>> there.
>>
>
> Facebook's Infer static analysis tool is adding more deeper checks for
> ownership lifetimes. They describe it as a "rough prototype of Rust-style
> borrow checker for C++."
>
> https://github.com/facebook/infer/releases/tag/v0.14.0
>
> ___
> 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: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Jet Villegas]

The continued work on the 2D GFx API as a C++ standard is concerning. Since
we're sending a GFx engineer to the committee, and AFAIK we're not going to
use such an API to build our GFx stack, the arguments against continued
development seem very compelling:

   -

   there are no clear users or demand for this feature from the community,
   -

   there is higher impact work that a 2D drawing library depends on,
   -

   there is higher impact work in general, and
   -

   the committee does not have infinite time,

I'd rather see the committee focus on things like object lifetime
management so we don't have to port everything to Rust just to get basic
memory safety guarantees. How much leverage do we have to push on that?

Thanks,

--Jet




On Tue, May 22, 2018 at 3:35 PM, Botond Ballo  wrote:

> Hi everyone!
>
> The next meeting of the C++ Standards Committee will be June 4-9 in
> Rapperswil, Switzerland.
>
> This is going to be a pivotal meeting, with go / no-go decisions
> expected for several highly-anticipated C++20 features, including a
> subset of Modules; Coroutines; Ranges; and "natural syntax" Concepts /
> abbreviated function templates. A discussion of whether or not to
> continue efforts to standardize 2D Graphics is also scheduled (see
> arguments for [1] and against [2]). In addition, work will continue on
> various Technical Specifications that are in flight (including,
> notably, Reflection), and processing the large influx of new language
> and library feature proposals.
>
> If you're curious about the state of C++ standardization, I encourage
> you to check out my blog posts where I summarize each meeting in
> detail (most recent one here [3]), and the list of proposals being
> considered by the committee (new ones since the last meeting can be
> found here [4] and here [5]).
>
> I will be attending this meeting, hanging out in the Evolution Working
> Group (where new language features are discussed at the design level)
> as usual. As always, if there's anything you'd like me to find out for
> you at the meeting, or any feedback you'd like me to communicate,
> please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0988r0.pdf
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html
> [3] https://botondballo.wordpress.com/2018/03/28/trip-report-c-
> standards-meeting-in-jacksonville-march-2018/
> [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#
> mailing2018-02
> [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#
> mailing2018-04
> ___
> 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: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Jet Villegas]

On Wed, May 23, 2018 at 1:35 PM, Botond Ballo <bba...@mozilla.com> wrote:

> On Wed, May 23, 2018 at 4:05 PM, Jet Villegas <jville...@mozilla.com>
> wrote:
> > I'd rather see the committee focus on things like object lifetime
> management
> > so we don't have to port everything to Rust just to get basic memory
> safety
> > guarantees. How much leverage do we have to push on that?
>
> I assume you mean "push for better object lifetime management" rather
> than "push against the 2D graphics proposal".
>

Yes, but please remind folks that Firefox already works with Cairo 2D and
we've made our implementation available for all :-)


> The only current proposal that I'm aware of in this area is P0936R0
> ("Bind Returned/Initialized Objects to the Lifetime of Parameters")
> [1]. This aims to extend C++'s lifetime extension rules to "see
> through" suitably annotated function / constructor calls, such that
> objects bound to parameters of such a function / constructor are kept
> alive for the lifetime of the return value / constructed object (so
> the annotation basically means "this function returns an object /
> constructs an object that refers to its parameters, and therefore that
> object should not outlive the parameters").
>
>
That actually sounds like a good thing to have. We'll continue to push on
Rust but still good to tighten up existing C++ code over time.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Jet Villegas]

I like that our link handling is getting shared but would really love a fix
for this bug in SVG  rendering:
https://bugzilla.mozilla.org/show_bug.cgi?id=1366494

Robert: do you have time to fix that one while you're in there?

Thanks!

--Jet


On Tue, Apr 10, 2018 at 1:09 AM, Gijs Kruitbosch 
wrote:

> On 10/04/2018 09:03, Gijs Kruitbosch wrote:
>
>> On 09/04/2018 22:11, longs...@gmail.com wrote:
>>
>>> Summary: HTML anchor elements have ping, rel, referrerPolicy, relList,
>>> hreflang, type and text properties. SVG anchor elements should support
>>> these properties too according to the SVG 2 specification and
>>> https://github.com/w3c/svgwg/issues/315.
>>>
>>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1451823
>>>
>>
>> I looked at the patch briefly, and I'm a bit confused about the state of
>>  . Specifically, my understanding is that we don't currently ship
>> it - it's behind a pref and it's off by default (
>> https://searchfox.org/mozilla-central/source/modules/libpref
>> /init/all.js#303 ). However, we have support in the codebase. But it
>> looks to me like the patch on the bug doesn't really check this pref
>> (unsure if we expose .ping for HTML if the pref is off) and doesn't
>> alter the implementation. At a minimum, it looks to me like this check:
>>
>> https://searchfox.org/mozilla-central/source/docshell/base/n
>> sPingListener.cpp#255-259
>>
>> would need updating to actually support .ping "properly" for SVG.
>>
>
> Sorry for the repetitive post, but I neglected to actually make the point
> I was trying to make. I can't really tell what the intent is from the
> patch, but I would be hesitant to say that this "implements and ships"
> 'ping' without any qualifications (in, say, release notes), because in
> effect the pref will still be off and presumably this means pings won't get
> sent (neither for HTML nor SVG links).
>
>
> ~ Gijs
> ___
> 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 enable as default paragraph separator of contenteditable/designMode editor by default

[Jet Villegas]

SGTM. Please follow up to make sure this workaround makes it on to MDN:

> document.execCommand("defaultParagraphSeparator", false, "br");

Thx!


On Tue, Feb 13, 2018 at 8:14 PM, Masayuki Nakano 
wrote:

> Starting from Firefox 60, I'd like to enable  as default paragraph
> separator of contenteditable/designMode editor by default even in release
> channel.
>
> When user typing Enter key in editing host (or body in designMode),
> Firefox 59 and earlier insert  element.  However, the other browsers
> insert  element (and wraps current line with  too). This is
> declared by execCommand spec (Unofficial draft):
> https://w3c.github.io/editing/execCommand.html#the-insertparagraph-command
>
> We've already enabled this behavior on Nightly and Early Beta since
> Firefox 55:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1297414
>
> And now, we don't have confirmed regression reports which we haven't
> worked on.  Additionally, once we use same behavior with the other browsers
> in this major difference, new web services could becomes not supporting our
> current behavior.  That means ESR users may become not to be able to use
> such web services.  Therefore, I'd like to enable this before shipping ESR
> 60.
>
> The bug is:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1430551
>
> Note that even if some web services have trouble with new our behavior,
> they can take the old behavior with inserting this line:
>
> document.execCommand("defaultParagraphSeparator", false, "br");
>
> --
> Masayuki Nakano 
> Software Engineer, Mozilla
> ___
> 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 DEPRECATE (taskcluster l10n routing)

[Jet Villegas]

On Sun, Dec 3, 2017 at 05:15 Axel Hecht  wrote:

> Am 01.12.17 um 16:45 schrieb Justin Wood:
> > Hey Everyone,
> >
> > tl;dr if you don't download nightly l10n repacks via taskcluster index
> > routes, this does not affect you.
> >
> > Up until recently you could only find nightly l10n repacks with the
> > following routes:
> >
> > *
> >
> .gecko.v2.{project}.revision.{head_rev}.{build_product}-l10n.{build_name}-{build_type}.{locale}
> > *
> >
> .gecko.v2.{project}.pushdate.{year}.{month}.{day}.{pushdate}.{build_product}-l10n.{build_name}-{build_type}.{locale}
> > *
> >
> {index}.gecko.v2.{project}.latest.{build_product}-l10n.{build_name}-{build_type}.{locale}
> >
> > Recently I have updated the routing to match that of regular Nightlies,
> > specifically one such route is:
> >
> >
> gecko.v2.mozilla-central.nightly.revision.a21f4e2ce5186e2dc9ee411b07e9348866b4ef30.firefox-l10n.linux64-opt
>
> That's followed by locale code, right? I found
>
>
> gecko.v2.mozilla-central.nightly.revision.de1f7a92e8726bdd365d4bbc5e65eaa369fbc20a.firefox-l10n.macosx64-opt.de
>
> > This deprecation is in preparation of actually building l10n repacks on
> > (nearly) every code checkin, rather than just on nightlies.
>
> Does that mean that you're deprecating all but that route, or are there
> more?
>
> > Let me know if there are any questions or concerns.
>
> No concerns, just curiousity. We're not running any tests on localized
> builds at this point, right?
>

I hope we can change that (testing on localized builds) with this proposed
change. We’ve gotten reports that localized builds (and related usage;
e.g., input method editors) cause A11y API activation, which triggers other
bugs for us.



> Axel
> ___
> 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

[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: mozilla-central now compiles with C++14

[Jet Villegas]

Nice! Binary literals sound cool for bit masks. I’d hate to have to
read/write them for anything else :-)

On Wed, Nov 15, 2017 at 20:44 Nathan Froyd  wrote:

> C++14 constructs are now usable in mozilla-central and related trees.
> According to:
>
> https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
>
> this opens up the following features for use:
>
> * binary literals (0b001)
> * return type deduction
> * generic lambdas
> * initialized lambda captures
> * digit separators in numeric constants
> * [[deprecated]] attribute
>
> My personal feeling is that all of these features minus return type
> deduction seem pretty reasonable to use immediately, but I would
> welcome comments to the contrary.
>
> Please note that our minimum GCC version remains at 4.9: I have seen
> reports that GCC 4.9 might not always be as adept at compiling C++14
> constructs as one might like, so you may want to be a little cautious
> and use try to make sure GCC 4.9 does the right thing.
>
> Starting the race to lobby for C++17 support in three...two...one... =D
>
> Happy hacking,
> -Nathan
> ___
> 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: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

[Jet Villegas]

SGTM. BTW, bug 143038 was filed 16 years ago. Is that a bugzilla record for
oldest fixed bug?

That is, do I owe you another steak? :-)


On Wed, Oct 18, 2017 at 2:52 PM, Masayuki Nakano 
wrote:

> From some users who use legacy mice which supports only vertical wheel, we
> have a request to support horizontal scroll with vertical wheel operation
> with a modifier.
> https://bugzilla.mozilla.org/show_bug.cgi?id=143038
>
> Now, legacy add-ons have gone since 57 and it may be difficult to override
> default action of wheel events with WebExtensions, it is the time to
> support horizontal scroll with vertical wheel operation with Shift key.
>
> This will be enabled in default settings except on macOS.  The reason why
> we don't need to use this feature on macOS is, macOS generates horizontal
> wheel event if user uses legacy mouse and pressing Shift key.
>
> And default action of wheel with Alt key is changed to history navigation
> which is default action of wheel with Shift key in current release build.
>
> So, now, we have consistent behavior between Firefox for macOS and the
> others.
>
> Note that this feature won't be exposed to attributes of "wheel" events.
> This is just a default action change and same behavior as Chrome.
>
> --
> Masayuki Nakano 
> Software Engineer, Mozilla
> ___
> 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: Changes to tab min-width

[Jet Villegas]

+1

On Tue, Oct 3, 2017 at 15:00 Chris Peterson  wrote:

> On 2017-10-03 2:18 PM, Boris Zbarsky wrote:
> > Right now, at 60px, I can see 7-10 chars in a tab title.  This is
> > sometimes (but not always) enough for me to make sense of what I'm
> > looking at when the favicon is not helpful.  For example, for bugzilla
> > bugs I can see the whole bug number.
> >
> > In the new setup is sounds like I will see 1-2 chars.  At that point,
> > it's not immediately clear to me that there's any value to not just
> > setting the min-width to "40px" and allowing all the title text to
> > disappear altogether.  There is definite value in not going below the
> > "keep the favicon entirely visible" value, of course.
>
> I think tab bar usability would be much improved if the tab bar's
> drop-down list of full tab titles was always available. This is the "V"
> button that appears to the right of the "+" tab button.
>
> On my machine, the drop-down list button only appears after 15 tabs are
> open, but (as Boris points out) the tabs stopped being identifiable
> before 15 tabs were open.
> ___
> 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: Implementing a Chrome DevTools Protocol server in Firefox

[Jet Villegas]

Can you summarize the desired outcomes?
e.g.,
1. people using devtools in Chrome can also debug Firefox
2. devtools for Chrome can be ported to Firefox
3. devtools for Firefox can be used with Chrome
4. ...

This is potentially a very large API surface to support, and I'm skeptical
about our ability to emulate Chromium's behavior when attached to devtools.
For example, we've been exposing new API's for Layout geometry to the
front-end and devtools, and would like to do more of that sort of tight
integration with our Layout engine. I'm not sure we could guarantee bug
compatibility when a Chrome devtool requires similar-but-not-quite
functionality. In other words, it sounds like your proposed protocol
emulation is feasible, but I'm less certain we can live up to the expected
semantics of things going over that wire.

--Jet





On Wed, Aug 30, 2017 at 2:55 PM, Michael Smith  wrote:

> Hi everyone,
>
> Mozilla DevTools is exploring implementing parts of the Chrome DevTools
> Protocol ("CDP") [0] in Firefox. This is an HTTP, WebSockets, and JSON
> based protocol for automating and inspecting running browser pages.
>
> Originally built for the Chrome DevTools, it has seen wider adoption with
> outside developers. In addition to Chrome/Chromium, the CDP is supported by
> WebKit, Safari, Node.js, and soon Edge, and an ecosystem of libraries and
> tools already exists which plug into it, for debugging, extracting
> performance data, providing live-preview functionality like the Brackets
> editor, and so on. We believe it would be beneficial if these could be
> leveraged with Firefox as well.
>
> The initial implementation we have in mind is an alternate target for
> third-party integrations to connect to, in addition to the existing Firefox
> DevTools Server. The Servo project has also expressed interest in adding
> CDP support to improve its own devtools story, and a PR is in flight to
> land a CDP server implementation there [1].
>
> I've been working on this project with guidance from Jim Blandy. We've
> come up with the following approach:
>
> - A complete, typed Rust implementation of the CDP protocol messages and
> (de)serialization lives in the "cdp" crate [2], automatically generated
> from the protocol's JSON specification [3] using a build script (this
> happens transparently as part of the normal Cargo compilation process).
> This comes with Rustdoc API documentation of all messages/types in the
> protocol [4] including textual descriptions bundled with the specification
> JSON. The cdp crate will likely track the Chrome stable release for which
> version of the protocol is supported. A maintainers' script exists which
> can find and fetch the appropriate JSON [5].
>
> - The "tokio-cdp" crate [6] builds on the types and (de)serialization
> implementation in the cdp crate to provide a server implementation built on
> the Tokio asynchronous I/O system. The server side provides traits for
> consuming incoming CDP RPC commands, executing them concurrently and
> sending back responses, and simultaneously pushing events to the client.
> They are generic over the underlying transport, so the same backend
> implementation could provide support for "remote" clients plugging in over
> HTTP/WebSockets/JSON or, for example, a browser-local client communicating
> over IPDL.
>
> - In Servo, a new component plugs into the cdp and tokio-cdp crates and
> acts on behalf of connected CDP clients in response to their commands,
> communicating with the rest of the Servo constellation. This server is
> disabled by default and can be started by passing a "--cdp" flag to the
> Servo binary, binding a TCP listener to the loopback interface at the
> standard CDP port 9222 (a different port can be specified as an option to
> the flag).
>
> - The implementation we envision in Firefox/Gecko would act similarly: a
> new Rust component, disabled by default and switched on via a command line
> flag, which binds to a local port and mediates between Gecko internals and
> clients connected via tokio-cdp.
>
> We chose to build this on Rust and the Tokio event loop, along with the
> hyper HTTP library and rust-websocket which plug into Tokio.
>
> Rust and Cargo provide excellent facilities for compile-time code
> generation which integrate transparently into the normal build process,
> avoiding the need to invoke scripts by hand to keep generated artifacts in
> sync. The Rust ecosystem provides libraries such as quote [7] and serde [8]
> which allow us to auto-generate an efficient, typed, and self-contained
> interface for the entire protocol. This moves the complexity of ingesting,
> validating, and extracting information from client messages out of the
> Servo- and Gecko-specific backend implementations, helps to ensure they
> conform correctly to the protocol specification, and provides a structured
> way of upgrading to new protocol versions.
>
> As for Tokio, the event loop and Futures-based model of concurrency it

Re: Extensions and Gecko specific APIs

[Jet Villegas]

Based on product plans I've heard, this sounds like the right approach. We
should try to limit the scope of such browser-specific APIs but it's likely
necessary in some cases (e.g., in the devtools.)


On Tue, Jul 25, 2017 at 2:44 AM, Gabor Krizsanits 
wrote:

> In my mind at least the concept is to share the API across all browsers
> where we can, but WebExtensions should not be limited to APIs that are
> accepted and implemented by all browser vendors.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: WebVR Working Group

[Jet Villegas]

There's a lot of maneuvering going on with all the WebVR browser vendors
about which VR hardware vendors will get "Tier 1" support. The support
matrix can get quite complex as more vendors come in, and many of these new
vendors will not be W3C members. It would be good to encourage a more
inclusive spec process that doesn't unfairly burden new entrants with
unnecessary bureaucracy.

That said, I'm concerned about the ambiguity around specs like WebVR 1.1
(which we're shipping in FF55). From the spec draft
:

*Deprecated API*


*The version of the WebVR API represented in this document is does not
represent the final shape of the API. While the API is being finalized
support for this version may temporarily be available in some browsers but
is expected to be replaced eventually.*

The statement above is weird to me. While I do expect that APIs evolve over
time, just as most Web APIs do, it seems rather heavy-handed for the spec
editor to state ship/support policy for all the browser vendors. Vendors
may decide to support for this API long-term, or not support a 2.0 API, or
decide to work on 2.0 for a while but still allow for users to build WebVR
apps today. In any case, vendors are shipping to their release channels,
and we should have more rigor around what that  means for "experimental"
features.

--Jet




On Wed, Jul 12, 2017 at 12:20 PM, L. David Baron  wrote:

> On Wednesday 2017-07-12 06:48 -0500, Lars Bergstrom wrote:
> > There is some contention in the WebVR community group around the
> submission
> > of this charter proposal, as there is currently no public support from
> any
> > of the implementers in making this transition away from a community
> group:
> > https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0056.html
>
> That's a little confusing to me given that there has been a good bit
> of movement towards shipping WebVR in release versions of browsers.
>
> Shipping things to the release channel (as opposed to just users on
> nightly/beta channels or users who turn on experimental features)
> means that Web content could start depending on the features at any
> time, which means we might be stuck with them in their current form.
>
> That suggests (if my understanding of the state of shipping to
> release users is correct) that it's likely time for the
> standardization process to also admit that it's no longer just
> experimenting, but actually shipping real stuff.
>
> -David
>
> > I would certainly not support at this time and, depending on the
> > conversations in that group and timing of the below deadline, may suggest
> > that we oppose.
> > - Lars
> >
> >
> > On Tue, Jul 11, 2017 at 12:23 PM, L. David Baron 
> wrote:
> >
> > > The W3C is proposing a new charter for:
> > >
> > >   WebVR Working Group
> > >   https://www.w3.org/2017/07/vr-wg-charter.html
> > >   https://lists.w3.org/Archives/Public/public-new-work/
> 2017Jul/0002.html
> > >
> > > Mozilla has the opportunity to send support, comments, or objections
> > > through Friday, August 18.  If this is work that we want to see
> > > happen at W3C, we should explicitly support it; if there are things
> > > we think should be different about the charter, this is the time to
> > > say so.
> > >
> > > Please reply to this thread if you think there's something we should
> > > say as part of this charter review, or if you think we should
> > > support or oppose it.
>
> --
> 턞   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)
>
> ___
> 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 unship: moz*Frames attributes of HTMLVideoElement

[Jet Villegas]

Please take a closer look at some of these:
https://github.com/search?utf8=%E2%9C%93=mozParsedFrames+extension%3Ajs=Code=advsearch==

<https://github.com/search?utf8=%E2%9C%93=mozParsedFrames+extension%3Ajs=Code=advsearch==>
Depending on what you find, we may have to keep this API around :-/

Thanks,

--Jet



On Thu, Jul 6, 2017 at 11:05 PM, Tim Huang <tihu...@mozilla.com> wrote:

>
>
> On Fri, Jul 7, 2017 at 11:54 AM, Jet Villegas <jville...@mozilla.com>
> wrote:
>
>> What do we expect to break?
>
>
> I can see that video quality auto adjusment which is based on these APIs
> will become malfunction. But, I don't know is this a real use case that a
> website implement video quality adjusment based on these APIs.
>
>
>> Who's out there using these APIs now?
>>
>
> There are some addons using these APIs to report media statistics. For our
> internal use, there are only some test code using them. And I think the
> VideoPlaybackQuality can be used to replace them since it provides a
> similar feature.
>
>
>> Thanks,
>>
>> --Jet
>>
>>
>> On Thu, Jul 6, 2017 at 8:21 PM, Tim Huang <tihu...@mozilla.com> wrote:
>> > I intent to unship the support of moz*Frames of HTMLVideoElement
>> including
>> > * HTMLVideoElement.mozParsedFrames
>> > * HTMLVideoElement.mozDecodedFrames
>> > * HTMLVideoElement.mozPresentedFrames
>> > * HTMLVideoElement.mozPaintedFrames
>> > * HTMLVideoElement.mozFrameDelay
>> > in Bug 1379050 [1].
>> >
>> > The reason of this is threefold.
>> > 1. They are non-standard API and Gecko is the only one implements
>> them.
>> > 2. The VideoPlaybackQuality[2] provides a similar feature.
>> > 3. There is a potential risk of browser fingerprinting[3] for these
>> > APIs.
>> >
>> > For these reasons, we should remove them.
>> >
>> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1379050
>> > [2] https://developer.mozilla.org/en-US/docs/Web/API/VideoPlayba
>> ckQuality
>> > [3] https://trac.torproject.org/projects/tor/ticket/15757
>> >
>> > --
>> > Tim Huang
>> > Mozilla Taiwan
>> > email:tihu...@mozilla.com
>> > phone:+886-2-8786-1100#402
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
> Tim Huang
> Mozilla Taiwan
> email:tihu...@mozilla.com
> phone:+886-2-8786-1100#402 <+886%202%208786%201100>
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

[Jet Villegas]

It looks like there may be a lot more of these:
https://stackoverflow.com/a/25397485

How about we just stub out the Stylo impls instead of unshipping the pseudo
in content?

On Thu, Jul 6, 2017 at 9:03 PM, Xidorn Quan <m...@upsuper.org> wrote:

> On Fri, Jul 7, 2017, at 01:42 PM, Jet Villegas wrote:
> > Thanks for cleaning this up.
> >
> > On Thu, Jul 6, 2017 at 8:29 PM, Xidorn Quan <m...@upsuper.org> wrote:
> >
> > > Although they don't currently match anything on web content, there is
> > > still some risk for unshipping them. Specifically, some websites seem
> to
> > > use them for browser-sniffing.
> >
> > Do you have some example sites that do this?
>
> Yes, bug 1378846 is an example that a site doesn't render correctly in
> Stylo due to lack of support of that.
>
> - Xidorn
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

[Jet Villegas]

What do we expect to break? Who's out there using these APIs now?

Thanks,

--Jet


On Thu, Jul 6, 2017 at 8:21 PM, Tim Huang  wrote:
> I intent to unship the support of moz*Frames of HTMLVideoElement including
> * HTMLVideoElement.mozParsedFrames
> * HTMLVideoElement.mozDecodedFrames
> * HTMLVideoElement.mozPresentedFrames
> * HTMLVideoElement.mozPaintedFrames
> * HTMLVideoElement.mozFrameDelay
> in Bug 1379050 [1].
>
> The reason of this is threefold.
> 1. They are non-standard API and Gecko is the only one implements them.
> 2. The VideoPlaybackQuality[2] provides a similar feature.
> 3. There is a potential risk of browser fingerprinting[3] for these
> APIs.
>
> For these reasons, we should remove them.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1379050
> [2] https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality
> [3] https://trac.torproject.org/projects/tor/ticket/15757
>
> --
> Tim Huang
> Mozilla Taiwan
> email:tihu...@mozilla.com
> phone:+886-2-8786-1100#402
> ___
> 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 unship: tree pseudo-element selectors from web content (::-moz-tree-*)

[Jet Villegas]

Thanks for cleaning this up.

On Thu, Jul 6, 2017 at 8:29 PM, Xidorn Quan  wrote:

> Although they don't currently match anything on web content, there is
> still some risk for unshipping them. Specifically, some websites seem to
> use them for browser-sniffing.

Do you have some example sites that do this?

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

Re: [stylo-team] Stylo bits coming to a Nightly near you

[Jet Villegas]

+cc: dev-servo, dev-tech-layout

Also, \o/ !!!

On Wed, Jun 21, 2017 at 3:24 PM, Gregory Szorc  wrote:
> We're starting to enable the *building* (not enabling) of Stylo in various
> platforms in automation. This means that Nightly will start shipping Stylo
> bits soon - possibly the next Nightly if things stick.
>
> The roll-out is being done as platforms are ready. Linux 64-bit and Windows
> 64-bit are the primary targets, with other platforms to follow.
> https://bugzilla.mozilla.org/show_bug.cgi?id=stylo-nightly-build tracks.
>
> There are still some toolchain ergonomics issues that we want to address
> before building Stylo is enabled by default in local builds. These are
> actively being worked on and local builds should re-converge with automation
> soon.
>
> If you want to tweak your local build, here are the relevant mozconfig
> snippets:
>
>   # build Stylo but don't enable it (what automation is now doing)
>   ac_add_options --enable-stylo=build
>
>   # build and enable Stylo
>   ac_add_options --enable-stylo
>
> But unless you interact with Stylo, my guess is you'll want to stick with
> the defaults because enabling the building of a feature that isn't enabled
> by default may only increase your build times while providing little to no
> benefits.
>
> As part of this, building Stylo in Firefox is now being promoted from Tier 2
> to 1. This involves some wonky version control machinery that knows how to
> "synchronize" backouts on autoland to the canonical Stylo repo on GitHub,
> all while ensuring file content and diffs line up between the 2 repos. This
> machinery may be a bit fragile initially. So there's a chance we'll have to
> back out building Stylo if there are problems. Hopefully we'll fall forward
> and fix bugs as they arise without too much disruption though.
>
> --
> You received this message because you are subscribed to the Google Groups
> "stylo-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to stylo-team+unsubscr...@mozilla.com.
> To post to this group, send email to stylo-t...@mozilla.com.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.com/d/msgid/stylo-team/CAJTgH0%3DsC%3DGV667d2yJ%2B6gww8pfehpCwqTj6HoOnKh5z7Bw9Mg%40mail.gmail.com.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Consensus check: Asking the Unicode Technical Committee to revert their decision to change the preferred UTF-8 error handling

[Jet Villegas]

SGTM, Thanks for pushing on this one.

One comment: although this is a proposed change to non-normative spec
text, it appears that several implementations already implement the
original (also non-normative) recommendation. Would it be worthwhile
to propose the reversal and also mark the section as normative?

--Jet

On Wed, Jun 7, 2017 at 2:11 AM, Henri Sivonen  wrote:
> (If you don't care about the details of UTF-8 error handling, it's
> safe to stop reading.)
>
> In reference to https://hsivonen.fi/broken-utf-8/ , I think it would
> be appropriate to submit that post to the Unicode Consortium with a
> cover note asking the Unicode Technical Committee to revert their
> decision to change the preferred UTF-8 error handling for Unicode 11
> and to retract the action item to draft corresponding new text for
> Unicode 11 for reasons given in the post.
>
> I think it would be preferable to do this via Mozilla's liaison
> membership of the Unicode Consortium rather than me doing it as a
> random member of the public, because submission via Mozilla's liaison
> membership allows for visibility into the process and opportunity for
> follow-up whereas if I do it on my own, it's basically a matter of
> dropping a note into a one-way black box. (It seems that this kind of
> thing is exactly what Mozilla's liaison membership is for.)
>
> However, submitting via Mozilla's liaison membership raises the
> question of whether the submission would properly represent a Mozilla
> consensus. I estimate this to be noncontroversial, because deliberate
> effort has been expended to make the Mozilla-affiliated
> implementations that I am aware of (uconv, encoding_rs and the Rust
> standard library) behave according to the pre-Unicode 11 version of
> the guidance either directly by looking at the Unicode Standard or by
> the way of implementing the WHATWG Encoding Standard, which elevates
> the pre-Unicode 11 preferred approach into a requirement.
>
> If I have mis-guessed that the above-contemplated submission should be
> non-controversial from the Mozilla perspective and you believe that
> the above-contemplated submission should not be made via Mozilla's
> liaison membership, please let me know.
>
> (My understanding is that a reversal of the decision is quite
> possible, but actually making the above-contemplated submission is a
> process prerequisite for a reversal to take place.)
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: xml:base attribute

[Jet Villegas]

xml:base (bug 1349024) has been removed in Nightly 55 for 2 months
now, and we haven't sen any reports of ill effects. Let's have this
testing expand to Beta 55, and on to Release if all goes well. Bug
1350521 tracks this change riding the trains.

--Jet

On Thu, Feb 16, 2017 at 2:51 PM, Xidorn Quan  wrote:
> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372
>
> Summary:
> * It has been removed from the spec years ago.
> * No other browser supports it.
> * We pay performance penalty for it.
> * It makes things trickier for stylo to handle URL values.
>
> The tricky thing is that nsParserUtils::ParseFragment currently relies
> on xml:base. That is going to be fixed in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1313278
>
> Are there any objections?
>
> - Xidorn
> ___
> 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: Is it OK to make allocations that intentionally aren't freed? (was: Re: Is Big5 form submission fast enough?)

[Jet Villegas]

Might be good to serialize to/from disk after the first run, so only
the first process pays the compute cost?

On Thu, May 18, 2017 at 10:44 PM, Henri Sivonen  wrote:
> On Tue, May 16, 2017 at 7:03 AM, Tim Guan-tin Chien
>  wrote:
>> According to Alexa top 100 Taiwan sites and quick spot checks, I can only
>> see the following two sites encoded in Big5:
>>
>> http://www.ruten.com.tw/
>> https://www.momoshop.com.tw/
>>
>> Both are shopping sites (eBay-like and Amazon-like) so you get the idea how
>> forms are used there.
>
> Thank you. It seems to me that encoder performance doesn't really
> matter for sites like these, since the number of characters one would
> enter in the search field at a time is very small.
>
>> Mike reminded me to check the Tax filing website: http://www.tax.nat.gov.tw/
>> .Yes, it's unfortunately also in Big5.
>
> I guess I'm not going to try filing taxes there for testing. :-)
>
> - -
>
> One option I've been thinking about is computing an encode
> acceleration table for JIS X 0208 on the first attempt to encode a CJK
> Unified Ideograph in any of Shift_JIS, EUC-JP or ISO-2022-JP, for GBK
> on the first attempt to encode a CJK Unified Ideograph in either GBK
> or gb18030, and for Big5 on the first attempt to encode a CJK Unified
> Ideograph in Big5.
>
> Each of the three tables would then remain allocated through to the
> termination of the process.
>
> This would have the advantage of not bloating our binary footprint
> with data that can be computed from other data in the binary while
> still making legacy Chinese and Japanese encode fast without a setup
> cost for each encoder instance.
>
> The downsides would be that the memory for the tables wouldn't be
> reclaimed if the tables aren't needed anymore (the browser can't
> predict the future) and executions where any of the tables has been
> created wouldn't be valgrind-clean. Also, in the multi-process world,
> the tables would be recomputed per-process. OTOH, if we shut down
> rendered processes from time to time, it would work as a coarse
> mechanism to reclaim the memory is case Japanese or Chinese legacy
> encode is a relatively isolated event in the user's browsing pattern.
>
> Creating a mechanism for the encoding library to become aware of
> application shutdown just in order to be valgrind-clean would be
> messy, though. (Currently, we have shutdown bugs where uconv gets used
> after we've told it can shut down. I'd really want to avoid
> re-introducing that class of bugs with encoding_rs.)
>
> Is it OK to create allocations that are intentionally never freed
> (i.e. process termination is what "frees" them)? Is valgrind's message
> suppression mechanism granular enough to suppress three allocations
> from a particular Rust crate statically linked into libxul?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: IntersectionObserver API

[Jet Villegas]

Thanks, Tobias. If all goes well, please request uplift to FF 54 for
this after a few days in Nightly 55 to unblock bugs like:
https://bugzilla.mozilla.org/show_bug.cgi?id=1131937#c28

--Jet

On Wed, Apr 5, 2017 at 2:21 PM, Tobias Schneider  wrote:
> Out final experiment on 100% of our Nightly user population just finished.
> We enabled the API for 110605 users. Out of that we only had 2 reported
> crashes related to the Intersection Observer API. Both were causes by
> Add-ons using the API in XUL documents. We  already addressed this issue in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1353529. I think its safe to
> go ahead and finally enabling this feature by default.
>
> On Fri, Mar 24, 2017 at 7:32 AM, Tobias Schneider 
> wrote:
>
>> We just successfully run another experiment, enabling the
>> IntersectionObserver API for 50% of our Nightly user population. No related
>> stability issues reported. Also, find a Gecko profile using an Intersection
>> Observer per element (109192 total) on the single page version of the HTML5
>> spec here: https://www.dropbox.com/s/cm55ixrvk7bqaxu/
>> SinglePageHTML5SpecIntersectionObserver.sps.json.zip?dl=0.
>>
>> On Thu, Mar 16, 2017 at 1:52 AM, Patrick Brosset 
>> wrote:
>>
>>> >
>>> > 1)  Is there devtools support for this (e.g. to be able to see what
>>> > intersection observers are registered where)?  If not, are there at
>>> least
>>> > bugs tracking it?
>>>
>>>
>>> I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1347849 for this.
>>> MutationObserver would be a good one to add support for too!
>>>
>>> On Thu, Mar 16, 2017 at 8:39 AM, Anne van Kesteren 
>>> wrote:
>>>
>>> > On Wed, Mar 15, 2017 at 7:38 PM, Boris Zbarsky 
>>> wrote:
>>> > > On 3/15/17 1:32 PM, Tobias Schneider wrote:
>>> > >> 2.3) Platform tests are in the process of being upstreamed by Google
>>> (
>>> > >> https://github.com/w3c/web-platform-tests/pull/4384).
>>> > >
>>> > > That seems to be in limbo for well over a month now.  jgraham just
>>> poked
>>> > it
>>> > > in hopes of at least getting automated testing going so we find out
>>> > whether
>>> > > Firefox passes the tests... but that will test release, afaik. Have
>>> you
>>> > > checked whether we pass these tests?
>>> >
>>> > They would be run against Nightly.
>>> >
>>> >
>>> > --
>>> > https://annevankesteren.nl/
>>> > ___
>>> > dev-platform mailing list
>>> > dev-platform@lists.mozilla.org
>>> > https://lists.mozilla.org/listinfo/dev-platform
>>> >
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
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`

[Jet Villegas]

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
> 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 and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Jet Villegas]

On Thu, Feb 16, 2017 at 7:23 AM, Mats Palmgren  wrote:

> On 02/11/2017 04:59 AM, Boris Zbarsky wrote:
>
>> The biggest worry for me is that inline style is never a "chrome sheet"
>> in this sense.
>>
>
> That's a valid concern, but I think ignoring -moz-appearance has fairly
> benign effects in most cases.  And as Jet pointed out to me, just landing
> it and see what breaks is standard procedure for unprefixing properties:
> https://bugzilla.mozilla.org/show_bug.cgi?id=775235
>
>
That's not exactly what I said:
https://bugzilla.mozilla.org/show_bug.cgi?id=1340014#c2

Our procedure for these legacy properties has been to land the unprefixed
property, and file separate bugs for removing the prefixed version at a
later date. Bug 775235 
is really a collection of those legacy prefix removals, which tend to never
get removed at the later date unless we track them.

We have plenty of evidence that the planet requires -webkit-appearance so
we should ship that ASAP:
https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/

If we need more time to evaluate the -moz-appearance removal, let's give it
the time it needs. The Microsoft Edge team has already done the work to
justify landing the unprefixed and -webkit variants.

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

Re: Intent to Implement: adding vector effects non-scaling-size, non-rotation and fixed-position to SVG

[Jet Villegas]

We had a good conversation with Ramin last week in Tokyo. The topic of
interoperability was discussed at length, and we also talked about where
Mozilla's 2017 priorities align with KDDI's.

To summarize, Mozilla is prioritizing the Web-compatibility and Performance
of the interoperable subset of the SVG feature set. That is, we will work
on features that:

A. other browsers support, and
B. authors actually use, or
C. the Firefox browser user interface requires.

Thanks,

--Jet


On Tue, Jan 31, 2017 at 12:11 AM,  wrote:

> Has there been any feedback from Google, Apple or Microsoft?
>
> We've landed stuff preffed off before and had to remove it in the end as
> it's just so much dead weight without any chance of being preffed on.
> Unless there's an intent to implement this soon from other vendors we
> really shouldn't put in any more effort here and we certainly shouldn't
> land any patches.
>
> Robert
> ___
> 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 remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

[Jet Villegas]

* Including a special-case check for the name Raanana when enumerating
> the system fonts
>


My preference as well, though I'm not convinced it's worth doing.

The Wikipedia page for the city of Ra'anana [0] marks up the city's Hebrew
name as:

רַעֲנָנָה‎

The Hebrew version [1] doesn't specify Hebrew fonts at all.

I often use Wikipedia as my unusual font reference site, though it's
certainly not exhaustive. Then again, if there's one place to use the
רַעֲנָנָה font, it would be in רַעֲנָנָה :-)

[0] https://en.wikipedia.org/wiki/Ra'anana
[1] https://he.wikipedia.org/wiki/%D7%A8%D7%A2%D7%A0%D7%A0%D7%94
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Experiment: CSS Houdini Paint API Level 1

[Jet Villegas]

Spec: https://drafts.css-houdini.org/css-paint-api/

Summary: The CSS Paint API is the first of several Web Rendering proposals
from the CSS Houdini Task Force. The CSS Paint API allows Web authors to
define and register a custom Paint method to be executed by the Layout
engine as other elements are rendered.

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

Link to standard: https://drafts.css-houdini.org/css-paint-api/

Platform coverage: Android, Desktop

Estimated or target release: TBD

Preference behind which this will be implemented: TBD

DevTools bug: TBD

Tests - TBD

Implementation Details:

CSS Paint API depends on the implementation of the following features:
CSS Houdini Properties & Values - https://bugzilla.mozilla.org/
show_bug.cgi?id=1273706
Houdini "Worklets" - https://bugzilla.mozilla.org/show_bug.cgi?id=1290021

The planned implementation in Gecko builds upon the HTML5 Canvas2D API to
provide the rendering surface for CSS Paint.

Risks:

The experimental implementation has progressed enough to warrant this
public Intent to Implement. However, significant risks will need to be
mitigated by careful design and execution if these features are to pass the
experimental stage and ship in Firefox, including:

1. Use Cases. It's not clear that the use cases proposed in the
specification warrant the additional Rendering System complexity. Apart
from conical gradients, we haven't seen many author requests for the other
use cases. If the existing Canvas2D feature set is lacking, what are the
compelling use cases and maximally useful API for such use cases? It's not
clear that the proposed Canvas2D-based API is desirable over a different
API design (eg., WebGL) if most use cases need to directly manipulate
pixels.

2. Rendering Performance. The planned Canvas2D backing store approach may
be too slow for real-world usage of the API. In the future, we may replace
the Canvas2D approach to have the custom paint methods create Layout
(displayList) nodes for direct rendering by the Layout engine, bypassing
the need for a Canvas2D backing store. It's worth noting that the Paint API
isn't directly compatible with existing displayList nodes (e.g., support
for raw paths, funny shapes, & pixel manipulation.)

There may also be other performance issues that arise with the API's usage
in combination with existing CSS features (e.g., CSS Masking, Filters,
etc.) The displayList vs. canvas bitmap implementation would probably look
a good bit different in WebRender. It's also worth noting that multiple
implementations shipping a bitmap-based version can create dependencies
that prevent us from switching to a faster alternative version in the
future.

3. Integration with Gecko Architecture. The Quantum Project <
https://wiki.mozilla.org/Quantum> is a major overhaul of the Firefox
Rendering Engine. Implementing the CSS Paint API while that effort is in
progress may add significant impedance. However, a counter-argument is that
we should design Quantum to allow for such extensibility in the future.
Duplication of work ( writing code that would need to be rewritten for
Quantum ) is not desirable and should be avoided.

For WebRender/Quantum, we could initially push this through the same path
that SVG will go through (which will be rasterized on the CPU and then
cached in a GPU texture atlas). It does seem like Houdini Paint could
reduce the amount of acceleration we can do on the GPU (at least in the
short term), but we won't be any worse off than other browsers in that
regard.

4. Dependency on incomplete implementations/specifications. The dependency
creates a chicken/egg scenario where we can't sufficiently evaluate the
dependent specifications (e.g, Worklets, and Properties & Values) without
also implementing an initial key use case (e.g., CSS Paint or Worklets for
Web Audio.) This is somewhat mitigated by getting the implementation far
enough along to formulate informed opinions on all the specifications.

The Houdini Task Force is meeting next week in Seattle to discuss this and
other specifications.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Expanding regular regression triage to include crashes?

[Jet Villegas]

+1 on expanding the search. That should help get earlier diagnosis. We
should also add 'regression' to those bugs as part of triage, as
appropriate.

--Jet

On Wed, Dec 14, 2016 at 6:11 PM, Nicholas Nethercote  wrote:

> Hi,
>
> Currently there are two platform regression triage meetings per week during
> which bugs marked with the "regression" keyword are triaged. See
> https://wiki.mozilla.org/Platform/ for details.
>
> Last week Jim Mathies and I discussed the possibility of expanding the
> triage to include bugs marked with the "crash" keyword as well. The reason
> being that all bugs filed through crash-stats.m.o get the "crash" keyword
> automatically added, but not the "regression" keyword.
>
> Right now, the four Fx53 "regression" searches in the table at
> https://wiki.mozilla.org/Platform/#Bug_Lists return 19 + 13 + 41 + 34 =
> 107
> results. If I change them to match "regression" or "crash", I get 44 + 20 +
> 59 + 37 = 160 results.
>
> The "Crash Bug Triage" section on the wiki page suggests that crashes are
> intended to be included by this regression triage. But I'm not sure if the
> top crash lists are consulted independently during the meetings, and thus
> whether expanding the searches would be helpful.
>
> Thoughts?
>
> Nick
> ___
> 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: CSS Grid

[Jet Villegas]

+cc: abillings re: fuzzing CSS Grid.

On Monday, December 5, 2016, Benjamin Smedberg 
wrote:

> Have the various grid properties be added to our fuzzers and we've been
> fuzzing the implementation fairly comprehensively?
>
> --BDS
>
> On Tue, Nov 15, 2016 at 7:40 PM, Mats Palmgren  > wrote:
>
> > As of Gecko 52, I intend to let CSS Grid ride the trains on all
> platforms.
> > https://drafts.csswg.org/css-grid/
> > This also includes all parts of the CSS Box Alignment spec that are
> > relevant to Grid layout:
> > https://drafts.csswg.org/css-align-3/
> >
> > It has been developed behind the "layout.css.grid.enabled" preference,
> > and has been enabled by default in Nightly and Aurora for some time now.
> >
> > Other UAs shipping this or intending to ship it are:
> > Chrome - intends to ship:
> > https://groups.google.com/a/chromium.org/forum/#!topic/blink
> > -dev/hBx1ffTS9CQ
> > Safari - is implementing it (independently):
> > https://bugs.webkit.org/show_bug.cgi?id=60731
> > Edge - status unknown to me
> >
> > Note about the 'subgrid' feature:
> > We will *not* support the subgrid feature of CSS Grid in this first
> > release.  This feature is marked as "at-risk" in the spec and thus
> > not needed for spec compliance.  (Chrome is likewise not going to
> > support subgrid in their first release.)
> >
> > This feature was previously discussed in this "intent to implement"
> thread:
> > https://groups.google.com/forum/#!msg/mozilla.dev.platform/
> > jSmfRivZOrU/ZMPcwySUEW4J
> >
> > Bug to turn on by default:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1217086
> >
> > CSS Grid meta bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=css-grid
> >
> > The Devtools team is implementing specific tools for Grid:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1181227
> > (some of which will ship in 52 I'm told)
> >
> >
> > /Mats
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org 
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org 
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Grid

[Jet Villegas]

Unlike other parts of the Grid spec, we don't have sufficient implementor
feedback (from ourselves or others) to evaluate the subgrid feature's
suitability for implementation. That will take time to get, and we do plan
to get it, but we want Grid available to people while we do so. That's not
the same as "nobody's implementing, so we won't either."

--Jet

On Wed, Nov 16, 2016 at 9:22 AM, Simon Sapin  wrote:

> On 16/11/16 01:40, Mats Palmgren wrote:
>
>> Note about the 'subgrid' feature:
>> We will *not* support the subgrid feature of CSS Grid in this first
>> release.  This feature is marked as "at-risk" in the spec and thus
>> not needed for spec compliance.  (Chrome is likewise not going to
>> support subgrid in their first release.)
>>
>
> I don’t have a strong opinion on subgrid specifically, and other arguments
> can be made, but I’d like to note:
>
> It is marked at-risk in the spec *because* several vendors had said they
> might not support it at first. So using this to justify not supporting it
> is a circular argument.
>
> --
> Simon Sapin
>
> ___
> 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: Rationalising Linux audio backend support

[Jet Villegas]

I generally support reducing the support matrix for Linux PCM audio.

A quick search for "ALSA vs. PulseAudio" comes up with mixed reviews for
either, which probably explains why we have both. It also seems like we can
count on ALSA being available on every distro, but perhaps not PulseAudio.
Can we add some telemetry to measure that?

Alternatively, you can wire this up so that we only fall back to ALSA
(stereo) when we can't get PCM audio to route through Pulse.

--Jet

On Wed, Jul 13, 2016 at 7:31 PM,  wrote:

> Supporting two separate audio backends in Linux is duplicated effort.
>
> I took over the platform media playback team at Mozilla a little over 3
> years ago. At that point we only supported WebM/VP8/Vorbis,
> Ogg/Theora/Vorbis and Wave as well as MP3 on Windows and some additional
> codecs including MP4/H.264/AAC on a small number of Android phones. At that
> time most media in the browser ran in Flash.
>
> Since then we’ve added words like MP3, MP4, H.264, VP9, Opus, AAC, HE-AAC,
> MSE and EME to our vocabulary. DASH and HLS are handled by site Javascript
> using MSE. A massive amount of effort has gone into making everything
> parallel so we can get as many pixels to the screen as possible. We’re
> working on platform specific performance improvements on Windows, Linux and
> Mac. We’re also doing some work to protect ourselves against driver crashes
> on Windows and Android.
>
> We are seeing an explosion of interest in HTML5 video and the accompanying
> audio is going through libcubeb, our audio backend. We’ve added low latency
> support to libcubeb for WebAudio and full duplex support so we can use it
> directly for microphone input for WebRTC.
>
> Our official Firefox builds on Linux support both PulseAudio and ALSA.
> There are a number of additional contributed backends that can be turned on
> at compile time, although contribution towards long-term maintenance and
> matching feature parity with the actively developed backends has been low.
> On Linux, we actively maintain the PulseAudio backend but we also approach
> the PulseAudio developers when we see issues in PulseAudio. The PulseAudio
> developers are generally good to work with.
>
> The most problematic backend across all platforms is ALSA. It is also
> missing full duplex support. We are intending to add multichannel (5.1)
> support across all platforms and the ones that don’t make the cut will be
> the ALSA backend and the WinMM backend used on Windows XP.
>
> Our ALSA backend has fallen behind in features, it is buggy and difficult
> to fix. PulseAudio is contrastingly low maintenance. I propose
> discontinuing support for ALSA in our official builds and moving it to
> off-by-default in our official builds.
>
> Leaving all the ALSA code in tree gives people the opportunity to continue
> maintaining the ALSA backend. Re-enabling it would require bringing it up
> to the same standard as other backends, not only in terms of current state
> but also in terms of consistency of contribution.
>
> As a long time Linux user, I want to get the most value out of our efforts
> on Linux. I can do that by focusing our efforts on the things that will
> have the greatest impact. Sometimes that requires taking a step back and
> deciding to do one thing well instead of two things poorly.
>
> Just to be clear, I’m proposing we stop spending time on ALSA so we can
> spend that time on adding 5.1 audio support to our PulseAudio backend.
> ___
> 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: [dev-servo] 25% Improvement in page load time!

[Jet Villegas]

I see that Servo was replacing an iterating strcmp with hashing, so that
explains the speed wins they're seeing. Maybe they should look into bsearch
for the memory wins too, if speed is comparable.

Shing Lyu: will you note that in the Servo github issue?

Thanks,

--Jet


On Mon, Jun 27, 2016 at 11:15 AM, Nathan Froyd <nfr...@mozilla.com> wrote:

> On Mon, Jun 27, 2016 at 2:01 PM, Jet Villegas <jville...@mozilla.com>
> wrote:
> > Shing Lyu from our Taipei Layout team reports a 25% page load improvement
> > in Servo from moving to a hashtable lookup from an iterator search of the
> > public suffix list ( https://publicsuffix.org/ )
> >
> > Should Gecko do the same thing and replace our binary search method?
> >
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSiteSecurityService.cpp#917
>
> Gecko's public suffix code lives over in netwerk/dns/:
>
>
> https://hg.mozilla.org/mozilla-central/file/tip/netwerk/dns/nsEffectiveTLDService.cpp#l51
>
> Bug 1247835 [1] changed its hashtable usage to a binary search earlier
> this year and we have not noticed any negative fallout.  Performance
> measurements in the bug suggest the binary search might actually be
> slightly faster, and the current structure enables us to easily share
> the lookup structures between processes, as well as being smaller than
> the previous hashtable scheme.  (If we switched to downloading public
> suffix lists--bug 1083971 [2]--the sharing would presumably go away,
> but we'd still get the size wins.)
>
> -Nathan
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1247835
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1083971
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Removing the Pointerlock permission UI

[Jet Villegas]

Yay! Thank you :-)

--Jet

On Thursday, June 23, 2016, Dale Harvey  wrote:

> In https://bugzilla.mozilla.org/show_bug.cgi?id=1273351 I am working on
> removing the pointerlock permissions UI, now instead of a doorhanger
> permission that the user needs to respond to before entering pointerlock,
> the pointer lock will be granted with a warning given to the user
> explaining how to exit, similiar to fullscreen and in alignment with
> chromes implementation.
>
> Thanks
> Dale
> ___
> 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: 32-bit developer edition?

[Jet Villegas]

We should offer both.

--Jet

On Thursday, June 2, 2016, Ben Kelly  wrote:

> Hi all,
>
> I noticed recently that all of the available download links for dev edition
> point to the 32-bit installer.  Is there a reason for this?
>
> Given we are talking about how to upgrade existing users to 64-bit it would
> seem good to update the download links for new installs.
>
> Thanks.
>
> Ben
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org 
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

[Jet Villegas]

On Thu, May 26, 2016 at 7:49 PM, Tzu-Hao Kuo  wrote:


> *Link to standard*: No standard. This API was first discussed at Mozlando
> and has been discussed online here(
> https://github.com/w3c/mediacapture-worker/issues/33). The discussion has
> been led to a stream-based design which will probably take a long time so
> we would like to implement the proposed HTMLMediaElement::seekToNextFrame()
> first for testing.
>

 What's the plan for resolving Streams/MediaStream integration raised on
the github issue? I read "probably take a long time" to mean we're working
on it, but is that actually the case? This is a feature we definitely want
interop on.

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

Re: Intent to ship: Canvas CSS/SVG filters

[Jet Villegas]

I'm surprised to see Skia (which I assume is also Chrome 53's canvas
backend) lagging behind CoreGraphics and even Cairo here. Do we have a bug
to track that down? This is the same code that powers our CSS filters, so a
speedup there should help both canvas and content.

--Jet

On Wed, Jun 1, 2016 at 12:08 PM, Tobias Schneider 
wrote:

> I got the following numbers running
> https://dl.dropboxusercontent.com/u/55355076/benchmark.html?filters=true
> on
> my MacBook Pro (Mid 2014):
>
> Firefox Developer Edition: Skia-GL: 10fps
>   Skia: 3fps
>   CG: 10fps
>   Cairo:8fps
>
> Chrome Canary 53: 3fps
>
>
> On Tue, May 31, 2016 at 11:53 AM, Jeff Muizelaar 
> wrote:
>
> > How does performance compare to Chrome?
> >
> > -Jeff
> >
> > On Thu, May 26, 2016 at 12:40 PM, Tobias Schneider <
> tschnei...@mozilla.com
> > > wrote:
> >
> >> I intend to turn Canvas CSS/SVG filters on by default on all platforms.
> It
> >> has been developed behind the canvas.filters.enabled preference.
> Google's
> >> Chrome is already shipping this in version 52.
> >>
> >> Related bugs:
> >>
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=927892
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1173545
> >>
> >> Specification:
> >>
> >>
> >>
> https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-filter
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Jet Villegas]

If I'm reading the dependency list correctly, we still plan to uplift to 48
if we can get bug 1264905 fixed in time. Is that correct?

--Jet

On Fri, May 13, 2016 at 10:15 AM, Daniel Holbert 
wrote:

> On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> > Estimated or target release:
> >   Firefox 46 (current Nightly), or 47 if we need to hold it back a
> > release to fix things.
> >
> > Preference behind which this will be implemented:
> >   layout.css.prefixes.webkit
>
> Following up on this -- this feature will be default-enabled in Firefox
> 49, as of the pref-unguarding-patch that I just landed on this bug:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1259345
>
> (This feature has been enabled & getting very useful testing & having
> bugs filed in Nightly/Aurora ever since Firefox 46. At this point, we've
> fixed all known regressions that are triggered by this feature, so we're
> calling it safe to ship in Firefox 49, and we'll be watching for any
> more bugs that are reported.)
>
> Thanks,
> ~Daniel
> ___
> 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 and ship: #rgba and #rrggbbaa color syntax in CSS

[Jet Villegas]

On Sun, May 8, 2016 at 10:35 PM, L. David Baron  wrote:

> I just landed a patch to implement the #rgba and #rrggbbaa syntax
> for colors in CSS,
>

Nice!


> It affects only colors specified in CSS, and not those specified in
> HTML attributes.
>
> Is this a follow-up, or are we prevented from parsing extended HTML color
attributes by some other invariant?

Thanks,

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

Re: Clarifications needed to 'Intent to ship' process

[Jet Villegas]

The "Intent to Implement" should help some of the concerns and allow for
comments. "Intent to Ship" usually means (at least for Platform Rendering)
that we'll be removing the #ifndef RELEASE flags and enabling preferences.
That is, by the time the "Intent to Ship" e-mail is sent, fundamental
issues should have already been resolved with module owners and other
parties.

--Jet

On Mon, Apr 25, 2016 at 2:19 PM, smaug  wrote:

> Hi all,
>
>
> based on couple of conversations we need some clarifications to 'intent to
> ship'.
>
> First, we aren't yet consistent enough to send 'intent to ship' emails. I
> think that takes
> just some time for patch authors and reviewers to get used to the process,
> that whenever there is some
> larger than minor web phasing API addition/removal being done, 'intent to
> ship' email to this list should be sent.
>
> Second, it isn't clear how we're supposed to react to the 'intent to ship'
> emails.
> I propose we require two OKs from the owners/peers of the relevant module
> (of which one could be given while reviewing the patch), and
> definitely no opposing comments from the owners/peers. But in case other
> people object... I guess we'll always have special cases and process can be
> improved when needed.
>
> Then there is also the case when relevant module doesn't really have
> peers, or not enough peers. I guess in that case OK from an owner/peer of a
> related module is fine too, or from a DE, or even from an active
> superreviewer (I know we aren't really using sr that much anymore).
>
> Note, this all is a separate thing from .webidl reviews, since the webidl
> may be written way before shipping, and reviewers for the .webidl are
> possibly different than those giving OKs to the overall API and its
> implementation.
>
>
> https://wiki.mozilla.org/WebAPI/ExposureGuidelines should be update once
> there is some agreement on what kind of process we want.
>
>
> comments?
>
>
> -Olli
> ___
> 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: Telemetry experiments need to be easier (on Nightly)

[Jet Villegas]

+1 for streamlining Telemetry deployment

I think we'd still want to:
1. broadcast when experiments are shipping, with a specific start/end/goal,
and what data is collected
2. define scope: Nightly/Aurora/Beta (with a higher approval bar for each,)
+ Desktop/Mobile/Other
3. track bugs that distinguish the experiment and control group

--Jet


On Wed, Apr 20, 2016 at 4:43 AM, Kartikaya Gupta  wrote:

> (Cross-posted to dev-platform and release-management)
>
> Hi all,
>
> Not too long ago I ran a telemetry experiment [1] to figure out how to
> tune some of our code to get the best in-the-wild behaviour. While I
> got the data I wanted, I found the process of getting the experiment
> going to be very heavyweight as it involved getting all sorts of
> approvals and reviews. Going through that process was more
> time-consuming than I would like, and it has put me off from doing
> further experiments of a similar nature. However, this means that the
> decisions I make are going to be less data driven and more guesswork,
> which is not good for obvious reasons.
>
> What I would like to see is a simplified process for telemetry
> experiments on Nightly, making it easier to flip a pref on 50% of the
> population for a week or two and get some useful data out of it. It
> seems to me that many of the approvals (QA, RelMan, Legal, Product)
> should not really be needed for this kind of simple temporary
> pref-flip, assuming the necessary data collection mechanisms are
> already in the code. Does anybody have any objections to this, or have
> other suggestions on how to streamline this process a bit more?
>
> To be clear, I'm not suggesting we do away with these approvals
> entirely, I just want to see more nuance in the process to determine
> when they are *really* required, so that they don't slow us down
> otherwise.
>
> Cheers,
> kats
>
> [1] https://wiki.mozilla.org/Telemetry/Experiments
> ___
> 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: -webkit-background-clip:text

[Jet Villegas]

I'm thinking we need two prefs so we cover the prefixed and unprefixed API
as per:
https://lists.w3.org/Archives/Public/www-style/2016Mar/0283.html

It's a bit odd to have the -webkit parser pref also control the rendering
pref in this case.

--Jet




On Wed, Mar 23, 2016 at 5:11 AM, Daniel Holbert <dholb...@mozilla.com>
wrote:

> On 03/21/2016 10:38 PM, Jet Villegas wrote:
> > I'd like to see this guarded by its own pref &&
> layout.css.prefixes.webkit
>
> Pushing back on this slightly:
>  - At this point, I don't think it's conceivable that we'd want to ship
> our webkit compatibility work until we're ready to also ship support for
> "-webkit-background-clip:text".  (If we're missing that feature, -webkit
> gradient support ends up causing too many visual regressions to be
> shippable, as noted at
> https://lists.w3.org/Archives/Public/www-style/2016Mar/0290.html )
>
>  - Therefore, I'm not sure we get any real-world benefit from guarding
> this feature with an additional dedicated pref.  And there'd be a
> complexity cost from making sure we test all combinations of pref
> enabled/disabled states, & do the right thing when one or the other pref
> is disabled.
>
> So, I'm not sure the cost/benefit calculus of adding a new, dedicated
> pref adds up here.
>
> However, if we do add another pref here, I think we'd want to just have
> it directly control this "text" value, independent of webkit prefixing
> support. Specifically, I imagine we'd have these prefs:
>
>  (1) layout.css.background-clip-text.enabled (new) to control whether
> "background-clip: text" is supported
>
>  (2) layout.css.prefixes.webkit (existing) to control whether
> "-webkit-background-clip" is an alias for "background-clip".  (This part
> is already done.)
>
> (This way, "-webkit-background-clip:text" would *effectively* be
> disabled unless both prefs are on -- but we wouldn't need to do any
> multi-pref checks anywhere in the code.  There'd be no need for "own
> pref && layout.css.prefixes.webkit" guarding.)
>
> This configuration makes sense to me - though I'm still not sure it adds
> value over just reusing the same pref, since as noted above we can't
> really ship one without the other.
>
> ~Daniel
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: -webkit-background-clip:text

[Jet Villegas]

I'd like to see this guarded by its own pref && layout.css.prefixes.webkit

Thanks for working on this, CJ!

--Jet

On Tue, Mar 22, 2016 at 1:59 PM, Ku(顧思捷)CJ  wrote:

> Summary:
> -webkit-background-clip:text has been available for years in webkit based
> browsers and has seen widespread usage on the web. This css property is
> currently available in Chrome, Safari and Edge.
>
> Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=759568
>
> Link to standard:
> https://compat.spec.whatwg.org/#the-webkit-background-clip-property
>
> Platform coverage:
> All platforms.
>
> Estimated or target release:
> Firefox 48
>
> Preference behind which this will be implemented:
> layout.css.prefixes.webkit
>
> Note:
> The way we support this property value is a little bit different with
> webkit.
> After turning on layout.css.prefixes.webkit,
> 1. -webkit-background-clip property is supported.
> 2. In gecko, "text" is a valid value for *both* background-clip and
> -webkit-backkground-clip.
> 3. In webkit, "text" is a valid value for only -webkit-backkground-clip.
>
> If you set "text" into -webkit-background-clip and serialize
> background-clip prop by style.getPropertyValue, you will still get "text",
> which is problematic. dholbert gave more detail explanation on bugzilla:
> https://bugzilla.mozilla.org/show_bug.cgi?id=759568#c40
> ___
> 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: HTML and tags

[Jet Villegas]

On Thu, Nov 19, 2015 at 5:33 PM, Karl Dubost  wrote:

> Jonas,
>
> Le 20 nov. 2015 à 04:22, Jonas Sicking  a écrit :
> > I don't think authors will use this very much unless they can style it.
>
> DetailsElement - 0.0856%
> https://www.chromestatus.com/metrics/feature/timeline/popularity/480
>
> (features are at risk of removal for Chrome when below 0.03%)
>
> hope it helps.
>

input=date seems clearly in that at-risk category--perhaps for the lack of
styling that Jonas noted:
https://www.chromestatus.com/metrics/feature/timeline/popularity/28

I expect we'll see more  usage once all the browsers have
it:
http://caniuse.com/#feat=details

BTW, please ensure that we avoid the known issues noted on that caniuse
link.

Nice job, Ting-Yu!

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

Re: Intent to implement: CSS Mask Image properties

[Jet Villegas]

> *Platform coverage*:
> everywhere
>
>
I'm so happy to see more Core Layout Engine features coming out of the
Taipei office. Nice work, CJ!

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

Re: Intent to ship: WebVR

[Jet Villegas]

Let the record state that Firefox is first to deliver Web Virtual Reality
to Planet Earth. On to other (virtual) worlds...

Congratulations, VR Team! \o/

--Jet

On Tue, Oct 27, 2015 at 4:19 AM, Kearwood "Kip" Gilbert <
kgilb...@mozilla.com> wrote:

> As of Oct 29, 2015 I intend to turn WebVR on by default for all platforms.
> It has been developed behind the dom.vr.enabled preference.  A compatible
> API has been implemented (but not yet shipped) in Chromium and Blink.
>
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1218482
>
> Link to standard: https://mozvr.github.io/webvr-spec/webvr.html
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: DocumentType.internalSubset

[Jet Villegas]

SGTM. It seems that the internal subset string was for non-HTML parsers to
use for whatever SGML/XML processing, so it should be OK to yank it from
the DOM. I can't find any docs on why it was added to the DOM in the first
place, so I can't comment on use cases we have to cover with an alternative
API.

--Jet

On Mon, Oct 12, 2015 at 8:13 AM, Aryeh Gregor  wrote:

> The current DOM standard says DocumentType.internalSubset should be
> removed:
>
> https://dom.spec.whatwg.org/#dom-documenttype-internalsubset
>
> It looks like Chrome has already removed it:
>
> https://code.google.com/p/chromium/issues/detail?id=272096
> http://codereview.chromium.org/282823004
>
> It seems the change stuck, because my Chrome 45 doesn't support it.
> This suggests it's safe to remove.
> ___
> 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

MemShrink Meeting - Today, 29 Sep 2015 at 4:00PM PDT

[Jet Villegas]

The next MemShrink meeting is brought to you by the new sampling based
memory profiler:
https://bugzilla.mozilla.org/show_bug.cgi?id=1123237

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 29 Sep 2015, 4:00 PM PDT
*
http://arewemeetingyet.com/Los%20Angeles/2015-29-09/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
* Triage Etherpad: https://etherpad.mozilla.org/memshrinktriage
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Directory picking and directory drag-and-drop

[Jet Villegas]

It looks like most of the Security discussion is happening in this bug now:
https://bugzilla.mozilla.org/show_bug.cgi?id=907707

--Jet

On Mon, Sep 21, 2015 at 9:18 PM, Eric Rescorla  wrote:

> On Mon, Sep 21, 2015 at 8:48 PM, Eric Shepherd 
> wrote:
>
> > Eric Rescorla wrote:
> >
> > I think there are some fairly obvious issues here, including:
> >
> > - There are obvious sensitive files you shouldn't upload under
> >   basically any conditions.
> > - It's hard for the client to know what the implications of any directory
> > upload are
> >   because they may not know what's in a given directory.
> >
> > I'm not a big fan of "the user is stupid and we have to protect him" as
> an
> > argument. :)
> >
>
> Conveniently, that's not what I said. There's lots of stuff that's in
> people's directories
> that they're not readily aware of, including dotfiles, missaves, etc.
>
>
>
> > There are a lot of genuinely valid use cases for this feature; yes,
> > security concerns should definitely be considered, but it's important to
> be
> > clear that if you want to address security concerns, or kill off the
> > feature entirely.
> >
>
> What's needed here is a real security assessment. That might lead to some
> sort of security mediations, and might also lead to the conclusion that it
> needs
> to be killed. But the first thing to do is an assessment. So far I haven't
> seen
> one.
>
> -Ekr
> ___
> 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

MemShrink Meeting - Tuesday, 1 Sep 2015 at 4:00PM PDT

[Jet Villegas]

The next MemShrink meeting is brought to you by better string processing in
the HTML5 parser:
https://bugzilla.mozilla.org/show_bug.cgi?id=1029671

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 1 Sep 2015, 4:00 PM PDT
*
http://arewemeetingyet.com/Los%20Angeles/2015-01-09/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
* Triage Etherpad: https://etherpad.mozilla.org/memshrinktriage
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Today, 18 Aug 2015 at 4:00PM PDT

[Jet Villegas]

Today's MemShrink meeting is brought to you by cycle-free media buffers:
https://bugzilla.mozilla.org/show_bug.cgi?id=1190019

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 18 Aug 2015, 4:00 PM PDT
*
http://arewemeetingyet.com/Los%20Angeles/2015-18-04/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
* Triage Etherpad: https://etherpad.mozilla.org/memshrinktriage
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Today, 4 Aug 2015 at 4:00PM PDT

[Jet Villegas]

Today's MemShrink meeting is brought to you by proper reference counting in
HTML5 media source extensions:
https://bugzilla.mozilla.org/show_bug.cgi?id=1190019

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 4 Aug 2015, 4:00 PM PDT
*
http://arewemeetingyet.com/Los%20Angeles/2015-08-04/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
* Triage Etherpad: https://etherpad.mozilla.org/memshrinktriage
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unprefixed CSS and DOM properties (across browser vendors)

[Jet Villegas]

This is the bug I filed to capture the unprefix list:
https://bugzilla.mozilla.org/show_bug.cgi?id=775235

Having our dev-tools alert for deprecated syntax would be very helpful. +cc
dev-developer-tools for feedback.

--Jet

On Wed, Jul 15, 2015 at 10:05 PM, Karl Dubost kdub...@mozilla.com wrote:

 Hello,
 (mostly for people of DOM and CSS)

 tl;dr: A list of unprefixed properties where the prefixed version has been
 dropped.

 Context:

 A feature has 4 states (or at least my impression):

 1. No support
 2. prefixed only support (MozFoo and -moz-bar)
 3. prefixed and unprefixed support (MozFoo, Foo, -moz-bar and bar)
 4. unprefixed only support (Foo and bar)

 For Web Compatibility, dropping the unprefixed version may create issues
 (See the recent issue with -moz-gradient).

 I would love to know if we have an always up to date list features state
 for Firefox/Gecko. Both caniuse and MDN are giving the information on when
 the prefixless version has been introduced but never when/if the prefix has
 been dropped.


 Why is it interesting?

 Given the current state of the Chinese and Japanese Web, some prefixes
 seem impossible to drop both for Mozilla, but also other browser vendors.
 Having the list of the current state could help us to send the right
 message to Web developers on
1. adding prefixless versions to their code
2. sometimes to remove the prefixed version of their code (more
 difficult because of old mobile devices).



 PS: I want to know that for WebKit, Blink and Edge too. I will ask around.

 --
 Karl Dubost, Mozilla
 http://www.la-grange.net/karl/moz

 ___
 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Jet Villegas]

On Mon, Jul 6, 2015 at 8:12 PM, Jeff Gilbert jgilb...@mozilla.com wrote:


 I propose we strike the `aFoo` recommendation from the Mozilla style guide.



Just so the proposal doesn't get lost in the bike shed, Jeff is only
proposing a change to the style guide, not a tree-wide find/replace
project. I take that to mean that When in Rome still applies to existing
C++ code.

Do we have consensus on that part?

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

Re: Linked Data must die. (was: Linked Data and a new Browser API event)

[Jet Villegas]

This. I don't want to lose Jonas' point in this long thread, but I also
haven't read anything here that warrants new native parser(s) yet. Let's
iterate in Gaia for now. I don't see how a C++ metadata parser is
advantageous at this point, and the RDF history lessons certainly don't
encourage that path.

--Jet

On Wed, Jul 1, 2015 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote:

 I'd definitely like to keep the implementation of whatever formats we
 use in Gaia given that this is still an experimental feature and the
 use cases are likely to evolve as we get user feedback.reiterate the

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

Runtime Hardware Testing for Firefox Desktop

[Jet Villegas]

Bug 1156135 https://bugzilla.mozilla.org/show_bug.cgi?id=1156135 will
enable Runtime Hardware Testing for Firefox Desktop. Once enabled, we'll
test the rendering capabilities of the current user's hardware prior to
enabling features that depend on that hardware.

A more detailed overview is posted here:
https://wiki.mozilla.org/Performance/Runtime_Hardware_Testing

This is just one step toward the goal to reduce the need for chemspills due
to untested GPU/driver combinations that are incompatible with hardware-enabled
rendering features. Multiple teams at Mozilla are collaborating on this
program, and we need your help for this to succeed.

As this feature rides the trains on Nightly, we'll monitor the telemetry
reporting the hardware/driver combinations that fail to render. We'll use
this information to improve our error correction, and optimize the user
experience. Once we land, you may see a very brief Rendering Test after a
Firefox update. We compare the results of that test with a known good
rendering to determine if your system is capable of using GPU-enabled
features. We're now testing with known-bad configurations, but we need to
ensure that we avoid false positives with the Nightly population.

We'll post detailed instructions on how to report problems before we enable
this feature. Please report any problems you encounter or other feedback to
runtime-hardware-test...@mozilla.com

Thanks,

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

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Jet Villegas]

!!! \o/ !!!

We'll also post the proposed spec on this wiki page:
https://wiki.mozilla.org/CanvasFilters

--Jet


On Mon, Jun 15, 2015 at 10:15 AM, Markus Stange msta...@themasta.com
wrote:

 Summary: The filter property on CanvasRenderingContext2D allows authors
 to specify a filter that will get applied during canvas drawing. It accepts
 the same values as the CSS filter property, so CSS filter shorthand
 functions, references to SVG filters, and chained combinations of the two.

 Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=927892 and
 https://bugzilla.mozilla.org/show_bug.cgi?id=1173545

 Link to standard: This would be added to the canvas spec. There has been
 some discussion [1] of this feature on the WhatWG mailing list, but no
 actual spec has been written yet.

 Platform coverage: All

 Estimated or target release: Firefox 41 or 42

 Preference behind which this will be implemented:
 This feature has been implemented behind the preference
 canvas.filters.enabled . We are planning to flip this preference to true by
 default in the very near future. The pref flip is being tracked in bug
 1173545.

 [1]
 https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0110.html
 ___
 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 and ship: CSS and SVG filters for canvas 2D

[Jet Villegas]

Markus, Tobias, and Tantek will update the wiki page with our proposed
normative text.

Our key use case here is Shumway, where graphics filter implementations in
JS code have not (yet) been able to offer acceptable performance
characteristics in Canvas2D. We've proven that it's polyfillable in other
browsers, though with the performance characteristics already mentioned.
Because of the Shumway dependency, we'll ship it even if we have to call it
mozCanvasFilters or hide it behind a Shumway pref--do you have a preference
on this?

I'd rather not hide the feature as I believe it's useful for the Web at
large, especially for applications currently using the Flash Player for
filter effects.

--Jet

On Mon, Jun 15, 2015 at 4:05 PM, Xidorn Quan quanxunz...@gmail.com wrote:

 On Tue, Jun 16, 2015 at 3:15 AM, Markus Stange msta...@themasta.com
 wrote:

  Summary: The filter property on CanvasRenderingContext2D allows authors
  to specify a filter that will get applied during canvas drawing. It
 accepts
  the same values as the CSS filter property, so CSS filter shorthand
  functions, references to SVG filters, and chained combinations of the
 two.
 

 Is there any signal from other browser vendors? It seems to me that only
 Adobe and us took part in this discussion.

 I tend to vote against shipping this feature at present, as far as no spec
 is written, and no other browser vendors agree with it yet. I think it
 violates our guidelines. [1]

 [1]

 https://wiki.mozilla.org/WebAPI/ExposureGuidelines#When_is_an_API_ready_to_be_shipped_by_Gecko.3F

 - Xidorn
 ___
 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

MemShrink Meeting - Today, 9 June 2015 at 4:00PM PDT

[Jet Villegas]

Today's MemShrink meeting is brought to you by memory reporting for layout
style structs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1168299

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 9 Jun 2015, 4:00 PM PDT
*
http://arewemeetingyet.com/Los%20Angeles/2015-06-09/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
* Triage Etherpad: https://etherpad.mozilla.org/memshrinktriage
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MemShrink Meeting - Today, 9 June 2015 at 4:00PM PDT

[Jet Villegas]

We don't record the meeting proceedings, but we do document the triage
discussion on an etherpad:
https://etherpad.mozilla.org/memshrinktriage

You're welcome to see the bugs in review, vote them up, suggest fixes, etc.
even if you can't attend.

--Jet



On Tue, Jun 9, 2015 at 11:47 AM, Avik Pal avikpal...@gmail.com wrote:

 Hey Jet,

 Is there any recording of the meeting that you can share on air mozilla?

 Thanks and regards,

 Avik Pal
 @avikpalme





 On 9 June 2015 at 23:03, Jet Villegas jville...@mozilla.com wrote:

 Today's MemShrink meeting is brought to you by memory reporting for layout
 style structs:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1168299

 The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink

 Agenda:
 * Prioritize unprioritized MemShrink bugs.
 * Discuss how we measure progress.
 * Discuss approaches to getting more data.

 Meeting details:

 * Tue, 9 Jun 2015, 4:00 PM PDT
 *

 http://arewemeetingyet.com/Los%20Angeles/2015-06-09/16:00/MemShrink%20Meeting
 * Vidyo: Memshrink
 * Dial-in Info:
- In office or soft phone: extension 92
- US/INTL: 650-903-0800 or 650-215-1282 then extension 92
- Toll-free: 800-707-2533 then password 369
- Conference num 98802
 * Triage Etherpad: https://etherpad.mozilla.org/memshrinktriage
 ___
 dev-developer-tools mailing list
 dev-developer-to...@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-developer-tools



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

MemShrink Meeting - Today, 26 May 2015 at 4:00PM PDT

[Jet Villegas]

Today's MemShrink meeting is brought to you by memory.report_concurrency:
https://bugzilla.mozilla.org/show_bug.cgi?id=1154053

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 26 May 2015, 4:00 PM PDT
*
http://arewemeetingyet.com/Los%20Angeles/2015-05-26/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Xcode+gecko for newbies instructional video

[Jet Villegas]

Awesome! What's the plan for getting the patches you mention in the video
into the tree?

Do we have instructions for Visual Studio anywhere?

--Jet

On Fri, May 22, 2015 at 10:31 AM, garvankee...@gmail.com wrote:

 A video demo of how to get working quickly with Xcode:
 https://www.youtube.com/watch?v=D0qu8zNDH-M

 Feedback welcome.
 ___
 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 and ship: document.execCommand(cut/copy)

[Jet Villegas]

\o/ Great to see this come through. Shumway was already using this but
needed chrome privilege to do so. It's nice to open it up.

--Jet

On Tue, May 5, 2015 at 2:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:

 Summary: We currently disallow programmatic copying and cutting from JS for
 Web content, which has relied on web sites to rely on Flash in order to
 copy content to the clipboard.  We are planning to relax this restriction
 to allow this when execCommand is called in response to a user event.  This
 restriction mimics what we do for other APIs, such as FullScreen.

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

 Link to standard: This is unfortunately not specified very precisely.
 There is a rough spec here: 

 https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#miscellaneous-commands
 
 and the handling of clipboard events is specified here: 
 https://w3c.github.io/clipboard-apis/.  Sadly, the editing spec is not
 actively edited.  We will strive for cross browser interoperability, of
 course.

 Platform coverage: All platforms.

 Target release: Firefox 40.

 Preference behind which this will be implemented: This won't be hidden
 behind a preference, as the code changes required are not big, and can be
 easily reverted.

 DevTools bug: N/A

 Do other browser engines implement this: IE 10 and Chrome 43 both implement
 this.  Opera has adopted this from Blink as of version 29.

 Security  Privacy Concerns: We have discussed this rather extensively
 before: http://bit.ly/1zynBg7, and have decided that restricting these
 functions to only work in response to user events is enough to prevent
 abuse here.  Note that we are not going to enable the paste command which
 would give applications access to the contents of the clipboard.

 Web designer / developer use-cases: This feature has been rather popular
 among web sites.  Sites such as Github currently use Flash in order to
 allow people to copy text to the clipboard by clicking a button in their
 UI.

 Cheers,
 --
 Ehsan
 ___
 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 deprecate: Insecure HTTP

[Jet Villegas]

We're adding UX to clearly indicate http:// or https:// in fullscreen while
still meeting the user desire for secure one-click-to-fullscreen. The
latest and greatest proposal posted here:

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

--Jet

On Mon, May 4, 2015 at 2:04 PM, Eric Rescorla e...@rtfm.com wrote:

 On Mon, May 4, 2015 at 1:57 PM, Xidorn Quan quanxunz...@gmail.com wrote:

  On Tue, May 5, 2015 at 6:04 AM, Martin Thomson m...@mozilla.com wrote:
 
   On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert dholb...@mozilla.com
   wrote:
(I think there's a strong case for disabling *persistent* fullscreen
permission, for the reasons described in ekr's response to you
 here.  I
haven't seen any proposal for going beyond that, but I might've
 missed
   it.)
  
   A little birdy told me that that is planned.
  
 
  I'm currently working on fullscreen. I believe our current plan is
 neither
  disabling fullscreen on HTTP, nor disabling persistent permission of
 that.
 
  Instead, we're going to remove permission bit on fullscreen, which means
  website can always enter fullscreen as far as that is initiated from a
 user
  input. We plan to use some transition animation to make entering
 fullscreen
  obvious for users, so that they are free from the burden deciding
 whether a
  website is trustworthy.


 This is not what I gathered from the notes Richard Barnes forwarded me.
 Rather, I had the impression that we were going to make the animation more
 aggressive *and* require a permissions prompt every time for HTTP.

 Richard?

 -Ekr
 ___
 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: Using rust in Gecko. rust-url compatibility

[Jet Villegas]

I think the plan was to improve security and dogfood rust. If we're also
signing up to increase spec compliance as part of the rewrite, that should
be called out as an explicit goal--with a plan for dealing with
non-compliant sites.

--Jet

On Fri, May 1, 2015 at 2:33 AM, James Graham ja...@hoppipolla.co.uk wrote:

 On 30/04/15 23:42, Jet Villegas wrote:

 I wonder why we'd allow *any* parsing differences here? Couldn't you just
 assert and fail hard while you're testing against our tests and in
 Nightly?
 I imagine the differences you don't catch this way will be so subtle that
 crowd-sourcing is unlikely to catch them either.


 I imagine the issue is that the current Gecko URL parser isn't 100%
 spec-compliant (see [1]), so the cases that differ aren't necessarily bugs
 that have to be fixed in rust-url.

 [1]
 https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/meta/url/a-element.html.ini


 ___
 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: Using rust in Gecko. rust-url compatibility

[Jet Villegas]

I wonder why we'd allow *any* parsing differences here? Couldn't you just
assert and fail hard while you're testing against our tests and in Nightly?
I imagine the differences you don't catch this way will be so subtle that
crowd-sourcing is unlikely to catch them either.

--Jet

On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu valentin.g...@gmail.com
wrote:

 As some of you may know, Rust is approaching its 1.0 release in a couple of
 weeks. One of the major goals for Rust is using a rust library in Gecko.
 The specific one I'm working at the moment is adding rust-url as a safer
 alternative to nsStandardURL.

 This project is still in its infancy, but we're making good progress. A WIP
 patch is posted in bug 1151899, while infrastructure support for the rust
 compiler is tracked in bug 1135640.

 One of the main problems in this endeavor is compatibility. It would be
 best if this change wouldn't introduce any changes in the way we parse and
 encode/decode URLs, however rust-url does differ a bit from Gecko's own
 parser. While we can account for the differences we know of, there may be a
 lot of other cases we are not aware of. I propose using our volunteer base
 in trying to find more of these differences by reporting them on Nightly.

 My patch currently uses printf to note when a parsing difference occurs, or
 when any of the getters (GetHost, GetPath, etc) returns a string that's
 different from our native implementation. Printf might not be the best way
 of logging these differences though. NSPR logging might work, or even
 writing to a log file in the current directory.

 These differences are quite privacy sensitive, so an automatic reporting
 tool probably wouldn't work. Has anyone done something like this before?
 Would fuzzing be a good way of finding more cases?

 I'm waiting for any comments and suggestions you may have.
 Thanks!
 ___
 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

MemShrink Meeting - Today, 28 Apr 2015 at 1:00pm PDT

[Jet Villegas]

The next MemShrink meeting is brought to you by debuggerMallocSizeOf:
https://bugzilla.mozilla.org/show_bug.cgi?id=1158257
https://bugzilla.mozilla.org/show_bug.cgi?id=1142183

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 28 Apr 2015, 1:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2015-04-28/13:00/MemShrink%20Meeting
http://arewemeetingyet.com/Los%20Angeles/2015-04-14/13:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement: DEAA (Antialiasing) for CSS Transformed Layer Edges

[Jet Villegas]

Thanks, Kip!

On Mon, Apr 6, 2015 at 11:47 AM, Kearwood Kip Gilbert 
kgilb...@mozilla.com wrote:


 Mobile platforms can benefit greatly from DEAA; however, we will need to
 be selective on which hardware to enable this on to avoid performance
 regressions.


The demos of this feature look wonderful, but this sort of beauty doesn't
come free :)  Product Owners of our mobile products should review the
feature and implementation to determine if and how to deploy this feature
on mobile devices. We'll file separate bugs for enabling this feature on
desktop, Fennec, and B2G.

Thanks,

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

Re: enabling off-main-thread animations on nightly/aurora

[Jet Villegas]

\o/ Hooray! This one took a lot of effort from many people across the
Rendering teams. Super-Happy to see it land.

--Jet

On Tuesday, March 31, 2015, L. David Baron dba...@dbaron.org wrote:

 I just landed (on mozilla-inbound) a patch for
 https://bugzilla.mozilla.org/show_bug.cgi?id=980770 that enables
 off-main-thread (OMT) animations on nightly and aurora.  This
 feature has previously been enabled on Firefox OS since Firefox OS
 1.0, but until now it has been disabled elsewhere.

 Off-main-thread animations means that we run animations of some CSS
 properties (currently only opacity and transform) on the compositor
 thread, and stop doing style updates on the main thread.  Running
 the updates on the compositor thread makes the animations run more
 smoothly (since their smoothness is no longer dependent on other
 things not hogging the main thread), and not doing the style updates
 on the main thread reduces the amount of work that we do (rather
 than increasing it).

 Depending on merge timing, and presuming that the change isn't
 backed out, this might hit nightly either tomorrow (April 1) or
 Thursday (April 2).

 Regressions from enabling it should be made to block bug 980770.

 If you want to test if something is a regression from it, toggle the
 pref layers.offmainthreadcomposition.async-animations.  (Reloading
 the page is probably needed for it to take effect fully, although it
 shouldn't require a restart, unless it's a bug in the Firefox UI.)

 Since this is the beginning of the six-week release cycle, I'm
 hoping that we'll be able to flip the pref unconditionally by the
 end of this cycle and let it ride the trains to release.  However,
 it's currently enabled only for nightly and aurora.

 -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)

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

MemShrink Meeting - Today, 31 Mar 2015 at 1:00pm PDT

[Jet Villegas]

The next Memshrink meeting begins in 1 hour and is brought to you by a
slimmer JS BaseShape:
https://bugzilla.mozilla.org/show_bug.cgi?id=1143256

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 31 Mar 2015, 1:00 PM PDT
*
http://arewemeetingyet.com/Los%20Angeles/2015-03-31/13:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: DevTools and Intent to Implement process

[Jet Villegas]

Excellent thread! Yes to more Dev Tools!!! Feel free to add a dev tooling
section to the e-mail templates we use for Intent to Implement and
Intent to Ship linked here:

https://wiki.mozilla.org/Intent_to_implement

We've started implementing the Web Animations API [1] with very early
collaboration with the Dev Tools team and have seen very promising results.
Is that a model we can continue to follow or modify to suit?

--Jet

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=998245


On Tue, Mar 31, 2015 at 1:07 PM, J. Ryan Stinnett jry...@gmail.com wrote:

 DevTools would like to get involved earlier in the implementation
 process for new platform features.

 In particular, we'd like to head towards a world where:

 1. Platform features are architected in such a way from the start that
 adding debugging / instrumentation is (relatively) easy
 2. DevTools for a feature are discussed early on in a bug that
 interested parties can follow while the platform feature is being
 implemented

 By working with the platform team as features are developed (instead
 of afterwards), we can discuss any debugging and instrumentation APIs
 our tools may need, give feedback as we start to build tools, etc.
 We're hoping this will help us to release tools closer to the time
 frame that the platform features are available.  Tools for new
 features should increase adoption of those features, as they make it
 easier for web developers to explore and understand them.

 The DevTools team has recently discussed[1] this, and we thought
 becoming more integrated in the platform Intent to Implement process
 would be a good thing to do.  Specifically, we'd like to have a
 DevTools line in the intent to implement template[2] which would
 link to a bug on building tools for the feature for further
 discussion.

 Thoughts? (Replies to dev-platform.)

 [1]:
 https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/fZOxb3t0Npk/discussion
 [2]:
 https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement

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

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

Re: From nsIntSize to gfx::IntSize

[Jet Villegas]

Probably safe for the integer types, but can we add strong assertions when
converting from Thebes and Moz2D floats? Bugs like this one are tough to
debug:

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

Thanks!

--Jet


On Fri, Mar 27, 2015 at 9:44 AM, Nicolas Silva nsi...@mozilla.com wrote:

 As many of you know, the introduction of Moz2D a while ago added new size,
 point and rect classes which are equivalent* to the ones that already
 existed in tree (nsIntSize, etc.).

 Juggling back and forth between the Moz2D classes and their thebes
 equivalent is pretty annoying and until now we have been progressively
 replacing uses of thebes classes by Moz2D ones (a slow process bearing the
 exquisite name Moz2Dification). Moz2Dification of size classes hasn't
 been very efficient, so I decided to just remove the integer thebes
 size/rect/point classes and make then typedefs of the moz2D ones.

 I will soon (probably over the weekend) land a patch set that does this for
 nsIntSize/gfx::IntSize.

 What this means if you are writing code outside of the gfx/ directory: Not
 much. Apologies if my patch queue causes some merge conflicts.
 It's up to module owners to decide if they still want refer to integer
 sizes as nsIntSize (the typedef) or as gfx::IntSize (the real thing!). You
 won't need to use the conversion helpers ToIntSize and ThebesIntSize
 anymore, since nsIntSize and gfx::IntSize will be one and the same, and by
 the way those conversion helpers are being removed which is most likely the
 reason if you run into merge conflicts.

 If you write code under the gfx/ directory, please use gfx::IntSize. After
 this lands there won't be any reason to refer to it as nsIntSize, so let's
 make things consistent.

 nsIntRect and nsIntPoint will soon share the same fate.

 Cheers,

 Nical

 * This only true for integer classes (IntSize, ect.) because the
 non-integer ones use double precision floats in thebes and regular floats
 in Moz2D, so we can't just make the switch in one go as easily.
 ___
 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

MemShrink Meeting - Tuesday, 3 Mar 2015 at 2:00pm PST

[Jet Villegas]

The next Memshrink meeting is is brought to you by the Shumway project:
http://www.areweflashyet.com/shumway/

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Review Shumway memory reports/usage
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.
* Schedule next meeting time (DST coming up!)

Meeting details:

* Tue, 3 Mar 2015, 2:00 PM PST
*
http://arewemeetingyet.com/Los%20Angeles/2015-03-03/14:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: [dev-servo] CSS Houdini meeting report

[Jet Villegas]

Cross-posting to dev-platform. Much of Simon's summary below applies to
Gecko.

--Jet

-- Forwarded message --
From: Simon Sapin simon.sa...@exyr.org
Date: Thu, Feb 19, 2015 at 9:28 AM
Subject: [dev-servo] CSS Houdini meeting report
To: dev-se...@lists.mozilla.org dev-se...@lists.mozilla.org


Last week I was in Sydney for the first face to face meeting of “CSS
Houdini”, a new joint task force of W3C’s CSS Working Group and Technical
Architecture Group.

The goal is to “explain the magic” of CSS, make it extensible by providing
low-level primitives that can be built upon to add new higher-level
features to the platform without baking them into browsers.

Participants were from Microsoft, Google, Mozilla, HP, W3C, Disruptive
Innovations, Apple, Vivliostyle, Adobe, and jQuery Foundation.

I have heard concerns that Google or Apple would just expose whatever
Blink/WebKit’s internals currently are, and the rest of us implementers
would be stuck with that. Since this work is happening at W3C and
participants include people working on competing engines, I am confident
this won’t happen. I will also be watching for design decisions that could
be incompatible with Servo’s goals (e.g. parallel layout, layout concurrent
with script, etc.)


About the task force:

Mailing list: https://lists.w3.org/Archives/Public/public-houdini/
IRC: #houdini @ irc.w3.org
Wiki: https://wiki.css-houdini.org/
Draft specifications: http://dev.w3.org/houdini/
Source repository: https://hg.css-houdini.org/drafts
Read/write mirror repository (pull requests work):
https://github.com/w3c/css-houdini-drafts


Formatted minutes of these discussions should be published soon. In the
meantime, the raw IRC logs are at:

http://log.csswg.org/irc.w3.org/houdini/2015-02-06/
http://log.csswg.org/irc.w3.org/houdini/2015-02-07/


The group agreed on its own scope, and on starting new 8 specifications. I
described them below based on my the minutes and my own recollection of the
discussions. If you want to discussed the proposals themselves (as opposed
to their implications for Servo), please do so on the public-houd...@w3.org
mailing list. (Subscription info is at the URL above.)


* Fragment Tree

Expose read-only information to script about the fragment tree, which is
roughly what implementations call the render tree, frame tree, or flow
tree. This includes anonymous fragments, that are not generated directly
by any DOM element. This was previously discussed as a Box Tree, but was
renamed since boxes (as defined in CSS specs) don’t have geometry, only
fragments (again per spec, after fragmentation across lines, columns,
regions or pages) do.


* CSS Parser API

Expose various pieces of the CSS parser: selectors, rules, complete
stylesheets, colors, gradients, unknown properties, etc. Web authors are
often doing this ad-hoc with regular expressions, which is painful and hard
to get right. The shape and API of returned objects (representing tokens or
an AST or higher-level values) is yet to be determined.


* CSS Properties and Values Extensions

Currently, CSS implementations throw away (per spec) rules or declarations
they don’t understand. The error recovery and fallback allow for some
forward-compatibility, but this is somewhat limited. We now also have CSS
Custom Properties, but they’re namespaced with the -- prefix. This proposes
adding APIs enabling script to register new at-rules and properties with a
details about their behavior and callbacks for parsing, as well as new
values for existing types (e.g color, length, image, …), thus enabling
polyfills.


* Font Metrics Extensions

Some desired features like drop caps a.k.a. initial letters require various
measurements from fonts such as position of the baseline, height of
ascenders and descenders, etc. This proposes APIs to determine which font
is actually used for a given piece of text in the document (since the
`font-family` property accepts a list of family names) and query such
measurements.


* Custom Paint

This proposes adding callbacks into script during painting, to enable
various graphical effects. One example given was an animated procedural
background image of ripples, as if on a fluid surface, that propagate from
a disturbance point and bounce against the borders of the element.


* CSS Custom Layout

This propose adding the ability to define new layout modes (like Flexbox is
a layout mode) in script, with callbacks for the various phases of layout.
These modes would probably be opted into through new values of the
'display' property.


* CSS Scroll Extensions

This proposes adding hooks to control scrolling (e.g. for snap points), and
what scrolling should block on (e.g. slow scroll event handlers).


* CSS Async Style

As far as I understand, this proposes adding control on what phases of
rendering of what parts of the document can be deferred or (de)prioritized.


-- 
Simon Sapin
___
dev-servo mailing list

MemShrink Meeting - Today, 17 Feb 2015 at 2:00pm PST

[Jet Villegas]

Today's Memshrink meeting is is brought to you by delayed initialization of
D3D11 texture objects:
https://bugzilla.mozilla.org/show_bug.cgi?id=1127925

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 17 Feb 2015, 2:00 PM PST
*
http://arewemeetingyet.com/Los%20Angeles/2015-02-17/14:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images

[Jet Villegas]

We should pick this up too.

--Jet

-- Forwarded message --
From: Jet Villegas W3C w...@junglecode.net
Date: Sat, Feb 7, 2015 at 1:36 AM
Subject: Fwd: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images
To: j...@mozilla.com



-- Forwarded message --
From: tommy...@chromium.org
Date: Fri, Feb 6, 2015 at 4:35 PM
Subject: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images
To: blink-...@chromium.org
Cc: Antoine Labour pi...@google.com, Rachel Blum gr...@google.com


Sending this because piman@ thought it was a good idea.


*Contact Emails:*
gr...@chromium.org, tommy...@chromium.org

*Spec:*
A specific portion of this design doc:

https://docs.google.com/document/d/1GQ-B3gWyWYX1cXf_B8mTK2ELSVwHqT-5bAERZqPliCo/edit#heading=h.bea8i8zdwtn7

*Summary:*
Plugin Power Saver pauses plugins deemed to be peripheral (small,
cross-origin). This feature is to allow web authors to specify a poster
image to be used in the paused state.

Usage:
  object data=http://b.tommycli.com/flash.swf;
type=application/x-shockwave-flash width=400 height=100
param name=poster value=snapshot1.png /
  /object

*Motivation:*
Without a poster image, Chrome tries to automatically extract an
interesting keyframe during a short preroll.

   - Plugin start can be deferred if there's a pre-provided poster image.
   Better performance for users.
   - If Chrome tries to extract a keyframe by analyzing frames, it could
   choose mediocre frame to use.
   - Keyframe extraction process itself takes up CPU time.

*Link to Intent to Implement:*
I implemented this before I was aware of this process. I sorry. It's behind
a content setting though, so no users will experience it unless they
explicitly opt in.

*Demo link:*
Use Chrome Canary. See http://a.tommycli.com/small_only_poster.html

See here for a video:
https://drive.google.com/open?id=0B-Use9bxumRNZE5Ub2VGYTk0c1E

*Compatibility Risk:*
I think it's minimal. The param tag is already supported. The 'poster'
parameter continues to be passed to the plugin, it's just re-used for a
different purpose. We could call it webkit-poster or something if you guys
are worried, but I'd prefer not to. If we take the feature away, the
browser will just ignore that parameter, and it shouldn't break anything.

*Ongoing technical constraints:*
None that I'm aware of.

*Will this feature be on all platforms?*
Windows, Mac, Linux, ChromeOS. Only the platforms with plugins.

*OWP Tracking bug*
None. Happy to make one if you guys want.

Link to entry on the feature dashboard http://www.chromestatus.com/
Also none, but happy to create also if you guys want.

To unsubscribe from this group and stop receiving emails from it, send an
email to blink-dev+unsubscr...@chromium.org.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Today, 3 Feb 2015 at 2:00pm PST

[Jet Villegas]

Today's Memshrink meeting is is brought to you by areweslimyet.com:
https://bugzilla.mozilla.org/show_bug.cgi?id=1100253

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 3 Feb 2015, 2:00 PM PST
*
http://arewemeetingyet.com/Los%20Angeles/2015-02-03/14:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS display:contents

[Jet Villegas]

CSSWG determined that display:contents covers use cases that CSS Grid
subgrid would otherwise cover [1]. We may punt on subgrid now that we've
got display:contents in Gecko. Other UAs have voiced support for the same
at the May 2014 F2F.

--Jet

[1] https://lists.w3.org/Archives/Public/www-style/2014Apr/0329.html

On Mon, Feb 2, 2015 at 8:11 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 2/1/15 4:36 PM, Mats Palmgren wrote:

 CSS display:contents has been enabled by default in v37 and my intent
 is to ship this feature in v37 on all platforms.


 Do we have any indication on whether any other UAs are planning to ship
 this?

 -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

MemShrink Meeting - Today, 20 Jan 2015 at 2:00pm PST

[Jet Villegas]

The next Memshrink meeting is is brought to you by proper shutdown when IPC
messages are dropped:
https://bugzilla.mozilla.org/show_bug.cgi?id=1091766

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 20 Jan 2015, 2:00 PM PST
*
http://arewemeetingyet.com/Los%20Angeles/2015-01-20/14:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: longdesc

[Jet Villegas]

The current Firefox implementation via a context-menu item (presumably
available to screen readers) seems innocuous to me. While I agree with many
of the points objecting to the spec, I don't see much upside for us (and
plenty of downside) to deprecating the feature without a counter-proposal.

--Jet

On Tue, Jan 6, 2015 at 3:27 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:

 On 2015-01-06 6:13 PM, L. David Baron wrote:

 (I'm not happy about this spec; for a good description of why, see
 http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html .
 I'm also under the impression that they're using Mozilla's
 implementation of it as support for the spec, which is rather
 galling considering that a big piece of what led to that
 implementation was an online harrassment campaign against a Mozilla
 UX designer to get the feature accepted.  I'm not sure how much it's
 worth fighting it at this point, although probably a first step in
 that fight would be to remove our implementation.)


 Is there any reason to not remove our implementation?

 ___
 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: W3C Proposed Recommendation: longdesc

[Jet Villegas]

The main downside I see is a potential Mozilla removes features used by
disabled people... PR fiasco. I think we can avoid that with a better
proposal that we do support.

On Tue, Jan 6, 2015 at 6:26 PM, Gavin Sharp ga...@gavinsharp.com wrote:

 What downsides do you see?

 Gavin

 On Tue, Jan 6, 2015 at 5:43 PM, Jet Villegas jville...@mozilla.com
 wrote:
  The current Firefox implementation via a context-menu item (presumably
  available to screen readers) seems innocuous to me. While I agree with
 many
  of the points objecting to the spec, I don't see much upside for us (and
  plenty of downside) to deprecating the feature without a
 counter-proposal.
 
  --Jet
 
  On Tue, Jan 6, 2015 at 3:27 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
  wrote:
 
  On 2015-01-06 6:13 PM, L. David Baron wrote:
 
  (I'm not happy about this spec; for a good description of why, see
 
 http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html .
  I'm also under the impression that they're using Mozilla's
  implementation of it as support for the spec, which is rather
  galling considering that a big piece of what led to that
  implementation was an online harrassment campaign against a Mozilla
  UX designer to get the feature accepted.  I'm not sure how much it's
  worth fighting it at this point, although probably a first step in
  that fight would be to remove our implementation.)
 
 
  Is there any reason to not remove our implementation?
 
  ___
  dev-platform mailing list
  dev-platform@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-platform
 
  ___
  dev-platform mailing list
  dev-platform@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-platform

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

MemShrink Meeting - Tuesday, 6 Jan 2015 at 2:00pm PST

[Jet Villegas]

The next Memshrink meeting is is brought to you by cumulative heap
profiling:
https://bugzilla.mozilla.org/show_bug.cgi?id=1094552

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 6 Jan 2015, 2:00 PM PST
*
http://arewemeetingyet.com/Los%20Angeles/2015-01-06/14:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Tuesday, 9 Dec 2014 at 2:00pm PST

[Jet Villegas]

The next Memshrink meeting is is brought to you by the ImageLib SurfaceCache:
https://bugzilla.mozilla.org/show_bug.cgi?id=923302

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 9 December, 2:00 PM PST
* http://arewemeetingyet.com/Los%20Angeles/2014-12-09/14:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

#ifdef RELEASE_BUILD in all.js

[Jet Villegas]

Hi dev-platform:

I'm seeing a lot of #ifdef RELEASE_BUILD lines in this file:
http://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js

A few features are currently enabled on all channels except Release. Do we have 
any features (that we think have shipped) slipping through the cracks?

Please scrub this file if you have prefs that are true except for Release. 
Ideally, we've got a bug on file (eg. bug 1105369) that turns the feature on by 
a specific Firefox release. 

Thanks,

--Jet



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

MemShrink Meeting - Tuesday, 25 Nov 2014 at 2:00pm PST

[Jet Villegas]

Note: new meeting time!

The next Memshrink meeting is is brought to you by better accounting for GFx 
surface cache entries:
https://bugzilla.mozilla.org/show_bug.cgi?id=1096913

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 25 November, 2:00 PM PST
* http://arewemeetingyet.com/Los%20Angeles/2014-11-25/14:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Tuesday, 11 Nov 2014 at 2:00pm PST

[Jet Villegas]

Note: new meeting time!

The next Memshrink meeting is is brought to you by the replace_malloc tool to 
capture and reproduce Firefox's memory allocations:
https://bugzilla.mozilla.org/show_bug.cgi?id=1083686

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 11 November, 2:00 PM PST
* http://arewemeetingyet.com/Los%20Angeles/2014-11-11/14:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Urgent request — info about new platform features in FxOS 2.0

[Jet Villegas]

CSS position:sticky:
https://bugzilla.mozilla.org/show_bug.cgi?id=886646

--Jet


- Original Message -
From: Chris Mills cmi...@mozilla.com
To: dev-...@lists.mozilla.org, dev-platform dev-platform@lists.mozilla.org
Sent: Thursday, November 6, 2014 10:50:26 AM
Subject: Urgent request — info about new platform features in FxOS 2.0

Hi all,

I have been working alongside Bhavana to put together a complete set of release 
notes for Firefox OS 2.0, in time for the release next week. I have a fairly 
complete set of new B2G platform features assembled, see:

https://developer.mozilla.org/en-US/Firefox_OS/Releases/2.0#Platform_additions_in_detail

And I just need to find bug numbers for these additions, along with a few other 
details that aren’t filled in.

What I’d love you to do is have a quick look over and see if you can suggest 
any that I’ve missed, 

many thanks!

Chris Mills
   Senior tech writer || Mozilla
developer.mozilla.org || MDN
   cmi...@mozilla.com || @chrisdavidmills



___
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: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View DOM Extensions for Smooth Scrolling

[Jet Villegas]

\o/

Cross-posting to b2g-internal as these are the features the Gaia team will use 
for the scrolling effects requested for Firefox OS.

--Jet

- Original Message -
From: Kip Gilbert kgilb...@mozilla.com
To: dev-platform@lists.mozilla.org
Sent: Monday, October 27, 2014 1:31:43 PM
Subject: Intent to ship: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View 
DOM Extensions for Smooth Scrolling

As of October 28, 2014 I intend to turn on by default CSSOM-View
Scroll-Behavior CSS Property and CSSOM-View DOM Extensions related to
smooth scrolling.  They have been developed behind the
layout.css.scroll-behavior.enabled and
layout.css.scroll-behavior.property-enabled preferences.  Firefox is
the first UA to ship this feature.  Chrome has an implementation,
disabled by default.

Platform coverage: This will be enabled on all platforms except for
Fennec.  (Fennec will be enabled once the C++ based APZC
implementation ships for Fennec)

This feature was previously discussed in this intent to implement
thread:
https://groups.google.com/d/msg/mozilla.dev.platform/mrsNyaLj3Ig/jooFD8rePzAJ

Further discussions occurred on www-style:

http://lists.w3.org/Archives/Public/www-style/2014May/0255.html
http://lists.w3.org/Archives/Public/www-style/2013May/0361.html
http://lists.w3.org/Archives/Public/www-style/2014Oct/0014.html

Bugs to turn on by default:

Bug 1087562 - Enable CSSOM-View scroll behavior CSS property by
default (Except for Fennec)

Bug 1087559 - Enable CSSOM-View scroll behavior DOM method extensions
by default (Except for Fennec)

Since the original intent to implement email, the specification has
evolved.  The CSSOM-View DOM Extensions have been changed to accept
dictionaries for options and the 'instant' value for scroll-behavior
has been changed to 'auto'.

Bug: 964097 - [meta] Implement CSSOM-View smooth scrolling spec

Link to standard:

http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-window-interface
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-element-interface

___
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

MemShrink Meeting - Tuesday, 28 Oct 2014 at 4:00pm PDT

[Jet Villegas]

The next Memshrink meeting is is brought to you by e10s now reporting 
performance timing in the content process:
https://bugzilla.mozilla.org/show_bug.cgi?id=1079705

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 28 October, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-10-28/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Screen Capture

[Jet Villegas]

Roc wrote up a proposal last year for a web-facing screen capture API:
https://wiki.mozilla.org/User:Roc/ScreenCaptureAPI

Even if not web-facing, we could use the implementation code to cover chrome 
use cases like this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=933389

At a recent GFx/Layout work week, we discussed using the Compositor to extract 
the screen-grab in an efficient, cross-platform manner. It seems we've got 
enough infrastructure in place to implement this quickly.

I'd like options on the API to allow for obscuring text layers so that we could 
use the images for UI tiles, and other privacy-sensitive use cases.

Kicking off this thread to get a discussion on:

1. Web-facing or not?
2. Security/Privacy concerns
3. Implementation concerns
4. Feature requests (eg. blurred or lorem-ipsum text)

Other ideas?

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

Re: Intent to ship: CSS Filters

[Jet Villegas]

I see the r+ on https://bugzilla.mozilla.org/show_bug.cgi?id=1057180

Are we missing anything else to checkin+ and turn this on?

--Jet

- Original Message -
From: Max Vujovic mvujo...@adobe.com
To: Dirk Schulze dschu...@adobe.com
Cc: Jacob Goldstein jac...@adobe.com, L. David Baron dba...@dbaron.org, 
Rik Cabanier caban...@adobe.com, Rik Cabanier caban...@gmail.com, 
dev-platform@lists.mozilla.org
Sent: Thursday, September 18, 2014 11:27:19 AM
Subject: Re: Intent to ship: CSS Filters

On Sep 16, 2014, at 9:52 PM, Dirk Schulze dschu...@adobe.com wrote:

 
 
 On Sep 17, 2014, at 2:44 AM, L. David Baron dba...@dbaron.org wrote:
 
 On Tuesday 2014-09-16 16:31 -0700, Rik Cabanier wrote:
 On Tue, Sep 16, 2014 at 2:44 PM, L. David Baron dba...@dbaron.org wrote:
 
 On Tuesday 2014-09-16 21:29 +, Max Vujovic wrote:
 == Interop ==
 Safari, Chrome, and Opera currently ship an interoperable implementation
 of CSS Filters behind a -webkit prefix.
 
 Do they have plans to ship without the prefix?  It's not really
 interoperable if it requires different syntax.
 
 Are you suggesting that we should add a '-webkit-filter' property so
 Firefox is interoperable?
 
 No.  I'm suggesting that we should try to ensure that Blink and
 WebKit unprefix sooner rather than later.
 
 Shorthand filters are just supported on HTML content in WebKit and Blink. SVG 
 content exclusively works with the unprefixed filter property which currently 
 just supports a reference to SVG filter elements. Once that is fixed, both 
 platforms will support the shorthand functions on unprefixed filter as well. 
 However, it is unlikely that the prefixed property will be removed soon. 
 Shipping CSS filters in Firefox is a strong signal to web developers. The 
 specification is getting finalized and changes to the existing functions must 
 be compatible to the current implementation in WebKit, Blink and Gecko and 
 will not be accepted for level 1 of the spec.

Thanks for the info, Dirk. I just asked the question on webkit-dev [1] and 
blink-dev [2], which might surface other blockers in those projects. At the 
least, I hope it draws some attention to shipping an unprefixed version.

[1]: https://lists.webkit.org/pipermail/webkit-dev/2014-September/026871.html
[2]: 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/R2gCfHjNgKs

- Max

 
 Greetings
 Dirk
 
 
 
 -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)

___
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

MemShrink Meeting - Tuesday, 30 Sept 2014 at 4:00pm PDT

[Jet Villegas]

The next MemShrink meeting is brought to you by DestroyWindow()
https://bugzilla.mozilla.org/show_bug.cgi?id=1060526

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 30 September, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-09-30/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: image-rendering: pixelated CSS property-value

[Jet Villegas]

Would it be wise to allow for image-rendering: pixelated that applies to any 
scale operation, and give us an option to add other operations (eg. 
image-rendering: smooth or image-rendering: bilinear) later?

--Jet

- Original Message -
From: Daniel Holbert dholb...@mozilla.com
To: Ehsan Akhgari ehsan.akhg...@gmail.com, L. David Baron 
dba...@dbaron.org, dev-platform@lists.mozilla.org
Sent: Thursday, September 25, 2014 12:27:12 AM
Subject: Re: Intent to implement: image-rendering: pixelated CSS  
property-value

On 09/24/2014 09:23 PM, Daniel Holbert wrote:
 So, it's not required to behave exactly the same everywhere; it simply
 codifies an author's intent.  (OK, I suppose it *is* required to behave
 exactly the same everywhere in the case of pixelated  upscaling,
 since that requires a particular algorithm, to achieve a particular
 effect. But other than that, it's purely a hint.)

(And actually, even in the case of pixelated  upscaling, the spec just
requires nearest-neighbor _or similar_.  So, [as it goes on to say],
the spec does not dictate any particular scaling algorithm to be used.)
___
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

MemShrink Meeting - Tuesday, 16 Sept 2014 at 4:00pm PDT

[Jet Villegas]

The next MemShrink meeting will be brought to you by app-theme-changed 
observers not getting double-added:
https://bugzilla.mozilla.org/show_bug.cgi?id=1061202

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 16 September, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-09-16/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Today, 2 Sept 2014 at 4:00pm PDT

[Jet Villegas]

The next MemShrink meeting will be brought to you by the Gfx layer tile tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1047945

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 2 September, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-09-02/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Tuesday, 19 August 2014 at 4:00pm PDT

[Jet Villegas]

The next MemShrink meeting will be brought to you by the Asynchronous Pan/Zoom 
Controller (APZC) not leaking testing data when disabled:
https://bugzilla.mozilla.org/show_bug.cgi?id=1041751

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 19 August, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-08-19/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802

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

MemShrink Meeting - Tuesday, 5 August 2014 at 4:00pm PDT

[Jet Villegas]

The next MemShrink meeting will be brought to you by the gray color #2d2d2d and 
not by gradient bitmaps:
https://bugzilla.mozilla.org/show_bug.cgi?id=1039631

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 5 August, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-08-05/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Tuesday, 22 July 2014 at 4:00pm PDT

[Jet Villegas]

The next MemShrink meeting is brought to you by the slimmer Firefox OS 2.0 
Homescreen:
https://bugzilla.mozilla.org/show_bug.cgi?id=1029902

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 22 July, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-07-22/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deploy: plugin timeout A/B test experiment, bug 1018200

[Jet Villegas]

 after a user isn't using it any more

How good are we at determining any more? Flash is used in all sorts of crazy 
ways, and guessing wrong can be more harmful than unloading too soon/late.

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

MemShrink Meeting - Tuesday, 8 July 2014 at 4:00pm PDT

[Jet Villegas]

Today's MemShrink meeting is brought to you by consolidated JS code:
https://bugzilla.mozilla.org/show_bug.cgi?id=1020012

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 8 July, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-07-08/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Tuesday, 24 June 2014 at 4:00pm PDT

[Jet Villegas]

The next MemShrink meeting will be brought to you by LeakSanitizer now running 
on TBPL Mochitests:
https://bugzilla.mozilla.org/show_bug.cgi?id=988041

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 24 June, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-06-24/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform