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 have
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 irredeemable?
Probabl
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, that's
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 probably a lost cause,
bu
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 don'
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 or other interactive
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. So, any issues you migh
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 whe
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
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 with
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 poten
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 ma
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 leak
13 matches
Mail list logo
