Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Boris Zbarsky]

On 7/18/17 11:56 PM, Tom Ritter wrote:

Sorry I got the pref name wrong; it's svg.disabled from
https://bugzilla.mozilla.org/show_bug.cgi?id=1216893


Ah.

So as you note, this pref, when set, makes it so you can't even create 
an SVGImageElement instance.  And then of course you can't pass one to 
drawImage, since you don't have it to start with.


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

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Tom Ritter]

On Tue, Jul 18, 2017 at 10:37 PM, Boris Zbarsky  wrote:
> On 7/18/17 11:21 PM, Tom Ritter wrote:
>>
>> This will respect the 'svg.in-content.enabled' pref, correct?
>
>
> Respect in what sense?
>
> What this will do is that _if_ you have an  and you drawImage it
> to a canvas, that will work, assuming the  was loaded.
>
> I don't think the pref you mention prevents such loading (or has any other
> effects that I can see), fwiw...

Sorry I got the pref name wrong; it's svg.disabled from
https://bugzilla.mozilla.org/show_bug.cgi?id=1216893

The way the pref was implemented:
 // If the svg.disabled pref. is true, convert all SVG nodes into
 // disabled SVG nodes by swapping the namespace.

I'm unsure if that would neuter the drawImage() call or not. The
ultimate goal of the pref is to disable all SVG-related code paths.

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

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Boris Zbarsky]

On 7/18/17 11:21 PM, Tom Ritter wrote:

This will respect the 'svg.in-content.enabled' pref, correct?


Respect in what sense?

What this will do is that _if_ you have an  and you drawImage 
it to a canvas, that will work, assuming the  was loaded.


I don't think the pref you mention prevents such loading (or has any 
other effects that I can see), fwiw...


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

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Tom Ritter]

This will respect the 'svg.in-content.enabled' pref, correct? Can I
request that be added as a test? =)

-tom

On Tue, Jul 18, 2017 at 6:00 PM, Boris Zbarsky  wrote:
> Summary: allow passing  to canvas createPattern and drawImage.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1382027
>
> Spec:
> https://html.spec.whatwg.org/multipage/canvas.html#htmlorsvgimageelement and
> https://html.spec.whatwg.org/multipage/canvas.html#canvasimagesource
>
> Platform coverage: all
>
> Target release: 56
>
> Preference: None.
>
> Support in other engines: Chrome is adding support; see
> .
> I don't know about Safari or Edge.
>
> Tests: Still figuring this out.  If there aren't any, I'll add some.
>
> -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

Nightly updates frozen to early 20170718 build

[nthomas]

Nightly updates are currently frozen at 
https://hg.mozilla.org/mozilla-central/rev/5e73b9798464c3f7106f0161dc9a49b234f42f9c
 due to reports of a startup crasher.

https://bugzilla.mozilla.org/show_bug.cgi?id=1382043.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: SVGImageElement as CanvasImageSource

[Boris Zbarsky]

Summary: allow passing  to canvas createPattern and drawImage.

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

Spec: 
https://html.spec.whatwg.org/multipage/canvas.html#htmlorsvgimageelement 
and https://html.spec.whatwg.org/multipage/canvas.html#canvasimagesource


Platform coverage: all

Target release: 56

Preference: None.

Support in other engines: Chrome is adding support; see 
. 
 I don't know about Safari or Edge.


Tests: Still figuring this out.  If there aren't any, I'll add some.

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

PSA: add_task().skip() and add_task().only() are now available to three test suites

[Michael de Boer]

Dear devs,

Assuming the landing of patches in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1380470 
 sticks, you all can 
enjoy the following from tomorrow onwards:

Paraphrased from the bug’s description:
You can now use `add_task(async function someTest() {}).skip()` and 
`add_task(async function someTest() {}).only()`, for Mochitest-chrome, 
Mochitest-browser and XPCShell tests, with the following semantics:

* `.skip()` makes sure that the task in question is not run as part of the 
suite. This will be made very clear in the log output as well.
* `.only()` makes sure that only the task in question is run, thus all the 
other tasks in that suite will be skipped. If `.only()` is called multiple 
times, it will run the last one on the stack, IOW: the last task on which 
`.only()` was called.

The motivation behind this feature is to promote Test Driven Development (TDD) 
and intermittent failure research work by allowing more granular control of 
what test gets run during your debugging process.
In large, growing test suites it's more likely that you'll be wishing to skip a 
certain test case because it takes a long time or has nothing to do with the 
failure case or rather to check if it pollutes the behavior of other tests.
In large, growing suites, it's also more likely that you'll be wishing for a 
convenient way to focus on a single test case, instead of the suite as whole. 
Example: extended feature development.

IMPORTANT: this change effectively deprecated XPCShell’s 
`add_test.skip(function test() {})`, `add_test.only(function test() {})`, 
`add_task.skip(async function test() {})` and `add_task.only(async function 
test() {})` in favor of the API mentioned above. This allowed for a 
substantially simpler implementation.

Thanks Standard8 (Mark Banner) for the idea and ahal (Andrew Halberstadt) for 
the reviews!

Enjoy and have fun,

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

Re: More Rust code

[Axel Hecht]

Am 17.07.17 um 21:43 schrieb Ted Mielczarek:

Nick,

Thanks for kicking off this discussion! I felt like a broken record
talking to people about this in SF. From my perspective Rust is our
single-biggest competitive advantage for shipping Firefox, and every
time we choose C++ over Rust we throw that away. We know the costs of
shipping complicated C++ code: countless hours of engineering time spent
chasing down hard-to-reproduce crashes, exploitable security holes, and
threading issues. Organizationally we need to get to a point where every
engineer has the tools and training they need to make Rust their first
choice for writing code that ships with Firefox.

On Mon, Jul 10, 2017, at 09:15 PM, Bobby Holley wrote:

I think this is pretty uncontroversial. The high-level strategic decision
to bet on Rust has already been made, and the cost of depending on the
language is already sunk. Now that we're past that point, I haven't heard
anyone arguing why we shouldn't opt for memory safety when writing new
standalone code. If there are people out there who disagree and think
they
have the arguments/clout/allies to make the case, please speak up.



From my anecdotal experiences, I've heard two similar refrains:

1) "I haven't learned Rust well enough to feel confident choosing it for
this code."
2) "I don't want to spend time learning Rust that I could be spending
just writing the code in C++."

I believe that every developer that writes C++ at Mozilla should be
given access to enough Rust training and work hours to spend learning it
beyond the training so that we can eliminate case #1. With the Rust
training sessions at prior All-Hands and self-motivated learning, I
think we've pretty well saturated the group of early adopters. These
people are actively writing new Rust code. We need to at least get the
people that want to learn Rust but don't feel like they've had time to
that same place.


I've been at (maybe half) a rust training at an allhands, and recently 
found myself looking at writing some code in rust. The experience was 
more about understanding other people's code, and re-using parts of it. 
Given that experience, I'd like to ask for a few more things:


Readable Rust. We spent half-n-hour on 3 lines of code, and that 
shouldn't be like that. I'm not sure if that was because the code was 
written badly, or because reading rust code requires dedicated training.


Copy-n-paste Rust code. That, to my experience, doesn't work like in any 
other language we frequently use. I'm used to copy, cut out the thing 
that it did originally, and the incrementally fill in my stuff. That 
works in most languages, but in Rust, it seems to break really really bad.


Documentation improvements. I've hit quite a few documentation pieces 
that stated the existence of the thing I was looking for. My place of 
failure was rc, which seems to have gotten quite a bunch of doc updates 
in the meantime, which is good.


I guess what I'm asking for is training on how to deal with rust code 
that other people wrote, maybe more so than writing rust code from 
scratch, starting with hello-world.


Axel



For case #2, there will always be people that don't want to learn new
languages, and I'm sympathetic to their perspective. Learning Rust well
does take a large investment of time. I don't know that I would go down
the road of making Rust training mandatory (yet), but we are quickly
going to hit a point where "I don't feel like learning Rust" is not
going to cut it anymore. I would hope that by that point we will have
trained everyone well enough that case #2 no longer exists, but if not
we will have to make harder choices.

  

The tradeoffs come when the code is less standalone, and we need to weigh
the integration costs. This gets into questions like whether/how Rust
code
should integrate into the cycle collector or into JS object reflection,
which is very much a technical decision that should be made by experts. I
have a decent sense of who some of those experts might be, and would like
to find the most lightweight mechanism for them to steer this ship.


We definitely need to figure out an ergonomic solution for writing core
DOM components in Rust, but I agree that this needs a fair bit of work
to be feasible. Most of the situations I've seen recently were not that
tightly integrated into Gecko.

-Ted



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

Webextensions - a layman's question

[Jörg Knobloch]

As the removal of XUL add-ons is imminent, I asked the author of the 
"Show Parent Folder" add-on, that shows a much needed "Parent Folder" 
column in the bookmarks window, whether his add-on would be ported to 
the new scheme and his answer was:


'NO' unfortunately. AFAIK, Webextensions do not allow the modification 
of UI elements and do not provide an API for the XUL tree.


So an add-on which really fixes a bug in Firefox "Can't tell where 
bookmark is stored" will stop working and expose this bug now. I wonder 
how much more functionality Firefox will lose.


Jörg (Thunderbird maintainer and Firefox user)


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

Re: More Rust code

[Frederik Braun]

On 18.07.2017 06:01, Jim Blandy wrote:
> BTW, speaking of training: Jason's and my book, "Programming Rust" will be
> available on paper from O'Reilly on August 29th! Steve Klabnik's book with
> No Starch Press is coming out soon as well, but I don't know the details
> there.
> 

Steve's book is the paper version of 
AFAIU.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform