Re: Intent to ship: NetworkInformation

2016-12-22 Thread Boris Zbarsky
On 12/22/16 10:31 PM, mcace...@mozilla.com wrote: (e.g., Boris' somewhat esoteric network setup) Just to check, are you talking about my typical setup for accessing the internet (which is totally non-esoteric laptop talks to wifi talks to ISP) or the "privacy leak" cases? > Most people

Re: Intent to implement: HTML5 element

2016-12-22 Thread Boris Zbarsky
On 12/22/16 10:03 PM, Martin Thomson wrote: On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky wrote: Note that I expect that this spec was written before Promise was a thing. The setup where we return a value in an attribute of the element (!) is pretty bizarre... Is this

Re: Intent to ship: NetworkInformation

2016-12-22 Thread mcaceres
On Wednesday, December 21, 2016 at 12:51:10 AM UTC+11, Eric Rescorla wrote: > I'm not really following this argument. Usually when a document has been > floating > around a long time but clearly has basic design issues and can't get > consensus, > even when a major vendor has implemented it,

Re: Intent to implement: HTML5 element

2016-12-22 Thread Martin Thomson
On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky wrote: > Note that I expect that this spec was written before Promise was a thing. > The setup where we return a value in an attribute of the element (!) is > pretty bizarre... Is this irredeemable? I mean, the attribute is

Re: Intent to implement: HTML5 element

2016-12-22 Thread Tim Nguyen
Non-modal dialogs should just work fine in a chrome window (the dialog would just be like a centered absolute positioned div). As for modal dialogs (eg. dialogs that makes everything else inert), it would depend on whether the current top-layer implementation works within a chrome window and I

Re: Intent to implement: HTML5 element

2016-12-22 Thread Justin Dolske
What's the expected experience if chrome code uses this feature? (In a chrome window, interaction with a content window isn't the thing I'm wondering about.) Justin On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen wrote: > *Summary*: > The *HTML element* represents a dialog box

Re: Async scrollbar dragging enabled on Nightly

2016-12-22 Thread Botond Ballo
On Mon, Dec 19, 2016 at 2:16 PM, Botond Ballo wrote: > Async scrolling (APZ) has been enabled for a new input method, > scrollbar dragging, on the Nightly branch. Sorry, I should have mentioned this sooner, but this was backed out due to a test failure before reaching m-c.

Re: Intent to implement: HTML5 element

2016-12-22 Thread Boris Zbarsky
On 12/21/16 4:13 PM, Xidorn Quan wrote: This is a question for the spec. I guess it theoretically can return a Promise, though I suspect that there might be some weird corner cases which is hard to handle. Note that I expect that this spec was written before Promise was a thing. The setup

Re: Introducing mozilla::Result for better error handling

2016-12-22 Thread Nick Fitzgerald
FWIW, you can also avoid the check-for-error-and-early-return-or-else-unwrap dance that is being "hidden" within MOZ_TRY by using `mozilla::Result::andThen` (and `mozilla::Result::map`) which are on inbound and will be on m-c soon. The patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1324829

Re: Introducing mozilla::Result for better error handling

2016-12-22 Thread Kris Maglione
On Wed, Dec 21, 2016 at 11:22:24PM -0800, Eric Rahm wrote: 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've never been convinced by that argument. Reviewers accept code

Re: Introducing mozilla::Result for better error handling

2016-12-22 Thread Bobby Holley
We've had this debate several times already, culminating in the attempt to ban NS_ENSURE_* macros. It didn't work. Subjectively, I think the reasons for the failure were: (a) We want logging/warnings on exceptional return paths, especially the ones we don't expect. (b) We want to check every

Removing GTK2 widget support?

2016-12-22 Thread lsalzman
This proposal is in reference to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1278282 As it stands currently our builds and testing are done with GTK3, so GTK2 support is effectively tier 3, with no tracking of regressions other than people filing bug reports. GTK2 thus adds to the

Re: Introducing mozilla::Result for better error handling

2016-12-22 Thread Nicolas B. Pierron
On 12/22/2016 06:53 AM, 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, etc) and memory