Re: Introducing mozilla::Result for better error handling

The key point for me is that we're hiding the return. I'm fine with the more verbose explicitly-return-and-make-it-easier-for-the-reviewer-to-call-out-issues form. I understand this is going to have differing opinions -- I think there's merit to more concise code -- but for the things I look at I

Re: Introducing mozilla::Result for better error handling

On Wed, Dec 21, 2016 at 10:53:45PM -0800, Eric Rahm wrote: I like the idea of pulling in some Rusty concepts, but I'm concerned about adding yet another early return macro -- absolutely no arguments on the new type, just the |MOZ_TRY| macro. In practice these have lead to security issues (UAF, et

Re: Introducing mozilla::Result for better error handling

I like the idea of pulling in some Rusty concepts, but I'm concerned about adding yet another early return macro -- absolutely no arguments on the new type, just the |MOZ_TRY| macro. In practice these have lead to security issues (UAF, etc) and memory leaks in the C++ world (I'm looking at you NS_E

Re: Intent to implement and ship: CSS caret-color property

On Wed, Dec 21, 2016, at 11:42 PM, Manuel Rego Casasnovas wrote: > Hi, > > just a small clarification regarding tests: > > On 21/12/16 01:17, Xidorn Quan wrote: > > Tests - URLs / paths to tests (preferably web-platform-tests) > > CSSWG's test repo contains some semi-manual tests, which are not u

Re: Intent to implement: HTML5 element

On Thu, Dec 22, 2016, at 05:41 AM, Joe Hildebrand wrote: > > On Dec 20, 2016, at 6:25 PM, Xidorn Quan wrote: > > > >> So dialog.showModal() does not need to block script like other > >> modal APIs? > > > > > > Definitely not. I think this is designed to replace those blocking API. > > Why does

Re: Rust required to build Gecko

On 21/12/16 07:55, Jim Blandy wrote: > The only things I really want anyway are: > > mk_add_options MOZ_OBJDIR=obj-bug > ac_add_options --enable-debug='-g3 -O0 -fno-inline' > ac_add_options --disable-optimize As a side note, I tend to use "-Og -g" as that gives much faster code than -O0 whilst re

Re: Intent to implement and ship: CSS display:flow-root

On 12/21/2016 10:57 AM, mtana...@yandex.ru wrote: > Fwiw, there is also a feature request for Edge: > > https://wpdev.uservoice.com/forums/257854/suggestions/17420707 [...] > https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10152756/ > > For some reason cannot add any of those

Re: Intent to implement and ship: CSS display:flow-root

Fwiw, there is also a feature request for Edge: https://wpdev.uservoice.com/forums/257854/suggestions/17420707 originally posted as a bug (but closed on the ground that the bug tracker is for bugs while feature requests should go to UserVoice): https://developer.microsoft.com/en-us/microsoft-ed

Re: Intent to implement: HTML5 element

> On Dec 20, 2016, at 6:25 PM, Xidorn Quan wrote: > >> So dialog.showModal() does not need to block script like other >> modal APIs? > > > Definitely not. I think this is designed to replace those blocking API. Why doesn't showModal() return a Promise? -- Joe Hildebrand ___

Re: Intent to implement and ship: CSS display:flow-root

On Wednesday 2016-12-21 18:56 +0100, Mats Palmgren wrote: > Summary: > A display:flow-root element generates a block container box, and lays out > its contents using flow layout. It always establishes a new block > formatting context for its contents (per CSS2). > This is intended to make "clearfix

Intent to implement and ship: CSS display:flow-root

Summary: A display:flow-root element generates a block container box, and lays out its contents using flow layout. It always establishes a new block formatting context for its contents (per CSS2). This is intended to make "clearfix" hacks unnecessary. The implementation is fairly trivial: it adds

Re: Introducing mozilla::Result for better error handling

On Wed, Dec 21, 2016, at 12:30 PM, Jason Orendorff wrote: > The implicit conversion solves a real problem. Imagine these two > operations > have two different error types: > > MOZ_TRY(JS_DoFirstThing()); // JS::Error& > MOZ_TRY(mozilla::pkix::DoSecondThing()); // pkix::Error > > W

Re: Introducing mozilla::Result for better error handling

On Tue, Dec 20, 2016 at 10:31 AM, Ehsan Akhgari wrote: > > Result Baz() { MOZ_TRY(Bar()); ... } > > I have one question: what is Bar() expected to return here? Result where F is implicitly convertible to E. An E type, > or a type that's implicitly convertible to E > (

Re: Introducing mozilla::Result for better error handling

On Tue, Dec 20, 2016 at 5:31 PM, Ehsan Akhgari wrote: > Is there a > potential for mistakes like for example caused by the error types being > implicitly convertible to each other but the values changing their > meanings upon the conversion (for example a bool error type getting > converted to an

Re: Async scrollbar dragging enabled on Nightly

On Wed, Dec 21, 2016 at 6:19 AM, Gervase Markham wrote: > Why do we paint a checkerboard We don't actually paint a checkerboard pattern. > rather than the default single background > colour of the page? This is what we do. It's still *called* checkerboarding though. The behaviour has changed, t

Re: Intent to implement and ship: CSS caret-color property

Hi, just a small clarification regarding tests: On 21/12/16 01:17, Xidorn Quan wrote: > Tests - URLs / paths to tests (preferably web-platform-tests) > CSSWG's test repo contains some semi-manual tests, which are not usable > in our infra. I'm adding an internal reftest (not wpt or csswg test) >

Re: Async scrollbar dragging enabled on Nightly

On 19/12/16 19:16, Botond Ballo wrote: > The third one, bug 1251617, is that a quick drag on a long page > results in checkerboarding. Why do we paint a checkerboard rather than the default single background colour of the page? Checkerboarding makes it really clear Firefox can't keep up. The bac

Re: Who loves multiple selection feature in editor?

> On 20 Dec 2016, at 20:52, Mats Palmgren wrote: > > The current spec editor seems open to discussing multi-range Selection, > which is encouraging. > > Perhaps we could add something like this: > > selection.forEachRange(function (range) { > // do awesome stuff > }) > > Since web developers

Re: Intent to deprecate: Insecure HTTP

Steve Fink wrote: > On 12/20/2016 06:20 PM, Edmund Wong wrote: >> Richard Barnes wrote: >> >>> Broadly speaking, this plan would entail limiting new features to >>> secure >>> contexts, followed by gradually removing legacy features from insecure >>> contexts. Having an overall program for HTTP d