Re: Rust required to build Gecko

2016-12-20 Thread Mike Hommey
On Wed, Dec 21, 2016 at 12:41:37AM -0600, J. Ryan Stinnett wrote: > On Wed, Dec 21, 2016 at 12:23 AM, Jim Blandy > wrote: > > I had a .mozconfig file that included the line: > > > > . "$topsrcdir/build/mozconfig.common" > > My understanding is that we're generally not

Re: Rust required to build Gecko

2016-12-20 Thread Jim Blandy
All the more reason for "mach" to be the exclusive place to put all these smarts. 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 On Tue, Dec 20, 2016 at 10:41 PM, J. Ryan Stinnett

Re: Rust required to build Gecko

2016-12-20 Thread Jim Blandy
I had a .mozconfig file that included the line: . "$topsrcdir/build/mozconfig.common" This turns out to cause problems: it loads build/mozconfig.rust, which says to look for rustc in $topsrcdir/rustc/bin, leading to errors like this: 0:05.53 checking for rustc... not found 0:05.53 DEBUG:

Re: Intent to ship: NetworkInformation

2016-12-20 Thread Steve Fink
On 12/19/2016 06:21 PM, Edmund Wong wrote: Eric Rescorla wrote: I'm also concerned that this spec does not seem to take into account multipath or multihoming, both of which seem relevant here. Say that I have a device with both a cellular and WiFi link and I attempt to use both of them in some

Re: Intent to deprecate: Insecure HTTP

2016-12-20 Thread Steve Fink
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 deprecation makes a clear statement to

Re: Intent to deprecate: Insecure HTTP

2016-12-20 Thread Edmund Wong
Richard Barnes wrote: > There's pretty broad agreement that HTTPS is the way forward for the web. > In recent months, there have been statements from IETF [1], IAB [2], W3C > [3], and even the US Government [4] calling for universal use of > encryption, which in the case of the web means HTTPS. >

Re: Intent to implement: HTML5 element

2016-12-20 Thread Xidorn Quan
On Wed, Dec 21, 2016, at 12:23 PM, Ben Kelly wrote: > On Tuesday, December 20, 2016, Xidorn Quan wrote: > > On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote: > >> Hi Tim, can you describe how the modality of dialog.showModal() > >> works? > >> Does a web page have the

Re: Intent to implement: HTML5 element

2016-12-20 Thread Xidorn Quan
On Wed, Dec 21, 2016, at 11:21 AM, Tantek Çelik wrote: > I'm also curious how interactions between dialog.showModal() and then > controls inside of that going Fullscreen work (and then perhaps a > dialog inside that fullscreen view, etc.) That's a... good question. Per spec, it should just

Re: Intent to implement: HTML5 element

2016-12-20 Thread Astley Chen
A simple example if you are interested in how it works on Chrome. http://codepen.io/astleychen/pen/Obqzrr —-- Best Regards, Astley Chen | Mozilla Taiwan On 21 Dec 2016, at 8:21 AM, Xidorn Quan wrote: On Wed, Dec 21, 2016, at 11:12

Re: Intent to implement: HTML5 element

2016-12-20 Thread Tantek Çelik
I'm also curious how interactions between dialog.showModal() and then controls inside of that going Fullscreen work (and then perhaps a dialog inside that fullscreen view, etc.) Does "escape" key escape out of one layer of dialog/fullscreen? multiple? all? Tantek On Tue, Dec 20, 2016 at 4:12 PM,

Re: Intent to implement: HTML5 element

2016-12-20 Thread Xidorn Quan
On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote: > Hi Tim, can you describe how the modality of dialog.showModal() works? > Does a web page have the power to block the user from interacting > with the entire browser (all windows)? Or is it just one window? > or just one tab? or something

Intent to implement and ship: CSS caret-color property

2016-12-20 Thread Xidorn Quan
Summary: As the name indicates, it allows developers to change the color or caret. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1063162 Link to standard: https://drafts.csswg.org/css-ui-3/#insertion-caret Platform coverage: All platforms Estimated or target release: Firefox 53 Preference

Re: Firefox Behaving Improperly to Standard

2016-12-20 Thread Boris Zbarsky
On 12/20/16 3:37 PM, Mark Legate wrote: I wasn't satisfied with the clarity of my response so I detailed out the issue further: http://pastebin.com/pvLNXXip The heart of the misunderstanding here is this bit: 4 - The element from which the value is propagated must have a used value for

Intent to implement: HTML5 element

2016-12-20 Thread Tim Nguyen
*Summary*: The *HTML element* represents a dialog box or other interactive component, such as an inspector or window. It will initially be implemented behind a pref. *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640 *Link to standard*:

Re: Firefox Behaving Improperly to Standard

2016-12-20 Thread Mark Legate
I wasn't satisfied with the clarity of my response so I detailed out the issue further: http://pastebin.com/pvLNXXip On Tue, 12/20/16, L. David Baron wrote: Subject: Re: Firefox Behaving Improperly to Standard To: "Mark Legate"

Re: Windows CPU power settings

2016-12-20 Thread Jim Blandy
On Fedora, that'd be the kernel-tools package, and the "cpupower frequency-info" command, I think? On Sat, Dec 17, 2016 at 11:04 PM, Bobby Holley wrote: > It looks like there are similar (though not as bad) shenanigans on Linux. > > In a fresh Ubuntu install, there are

Re: Introducing mozilla::Result for better error handling

2016-12-20 Thread Ehsan Akhgari
On 2016-12-20 8:46 AM, Jan de Mooij wrote: > Hi all, > > A few weeks ago we added mozilla::Result to MFBT [0][1]. Amazing! > I was asked > to inform dev-platform about this, so here's a quick overview. > mozilla::Result is based on Rust's Result type [2]. It contains > either a

Re: Intent to ship: RC4 disabled by default in Firefox 44

2016-12-20 Thread zombie . dk89
On Tuesday, September 1, 2015 at 11:56:28 AM UTC-5, Richard Barnes wrote: > For a while now, we have been progressively disabling the known-insecure > RC4 cipher [0]. The security team has been discussing with other the > browser vendors when to turn off RC4 entirely, and there seems to be >

Re: Intent to ship: RC4 disabled by default in Firefox 44

2016-12-20 Thread zombie . dk89
On Tuesday, September 1, 2015 at 11:56:28 AM UTC-5, Richard Barnes wrote: > For a while now, we have been progressively disabling the known-insecure > RC4 cipher [0]. The security team has been discussing with other the > browser vendors when to turn off RC4 entirely, and there seems to be >

Re: Who loves multiple selection feature in editor?

2016-12-20 Thread Mats Palmgren
On 12/20/2016 03:25 AM, Masayuki Nakano wrote: I'm talking about only nsISelectionController::SELECTION_NORMAL. Other selections need multiple selection. I suspect that treating SELECTION_NORMAL differently from other kinds of Selections will actually make the code more complicated, not less.

Re: Intent to deprecate: Insecure HTTP

2016-12-20 Thread Eric Rescorla
On Tue, Dec 20, 2016 at 10:28 AM, Cody Wohlers wrote: > Absolutely! Let's Encrypt sounds awesome, super-easy, and the price is > right. > > But I'm thinking of cases like Lavabit where a judge forced the site > operator to release the private key. Or the opposite -

Re: Intent to deprecate: Insecure HTTP

2016-12-20 Thread Cody Wohlers
Absolutely! Let's Encrypt sounds awesome, super-easy, and the price is right. But I'm thinking of cases like Lavabit where a judge forced the site operator to release the private key. Or the opposite - could a government restrict access to a site by forcing the CA to revoke certificates? I

Re: Expanding regular regression triage to include crashes?

2016-12-20 Thread Daniel Veditz
On Mon, Dec 19, 2016 at 10:00 PM, Kan-Ru Chen wrote: > I think the most important is to identify whether the crash bugs are > regressions so they can be tracked accordingly. I would guess that crash bugs filed by project Uptime are going to be (or at least look like)

Re: Firefox Behaving Improperly to Standard

2016-12-20 Thread L. David Baron
On Tuesday 2016-12-20 02:24 +, Mark Legate wrote: > https://www.w3.org/TR/CSS2/visufx.html#overflow > https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#viewport > https://www.w3.org/TR/CSS2/visufx.html#overflow-clipping And https://bugzilla.mozilla.org/show_bug.cgi?id=1322952 > The

Re: Intent to deprecate: Insecure HTTP

2016-12-20 Thread Jim Blandy
Can't people use Let's Encrypt to obtain a certificate for free without the usual CA run-around? https://letsencrypt.org/getting-started/ "Let’s Encrypt is a free, automated, and open certificate authority brought to you by the non-profit Internet Security Research Group (ISRG)." On Tue, Dec

Re: Introducing mozilla::Result for better error handling

2016-12-20 Thread Nick Fitzgerald
Thanks for getting this landed! Hooray for better error handling! \o/ On Tue, Dec 20, 2016 at 5:46 AM, Jan de Mooij wrote: > Hi all, > > A few weeks ago we added mozilla::Result to MFBT [0][1]. I was asked > to inform dev-platform about this, so here's a quick

Re: Firefox Behaving Improperly to Standard

2016-12-20 Thread Gijs Kruitbosch
On 20/12/2016 16:12, Gijs Kruitbosch wrote: On 20/12/2016 02:24, Mark Legate wrote: I was directed here from a firefox bug. For context, can you provide a link to the bug? Mark replied: https://bugzilla.mozilla.org/show_bug.cgi?id=1322952 ~ Gijs

Re: Firefox Behaving Improperly to Standard

2016-12-20 Thread Gijs Kruitbosch
On 20/12/2016 02:24, Mark Legate wrote: I was directed here from a firefox bug. For context, can you provide a link to the bug? ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Firefox Behaving Improperly to Standard

2016-12-20 Thread Mark Legate
Hi All, I was directed here from a firefox bug. I'll try to present the problem as clearly as I can. The issue: I recently had an issue where the scrollbar UI element was not rendering due to overflow:hidden being applied to the body. The document was larger than the viewport but an

Re: Intent to deprecate: Insecure HTTP

2016-12-20 Thread cody . wohlers
This is a good idea but a terrible implementation. I already need someone else's approval (registrar) to run a website (unless I want visitors to remember my IP addresses). NOW I will need ANOTHER someone to approve it as well (the CA authority), (unless I want visitors to click around a

Re: Intent to ship: NetworkInformation

2016-12-20 Thread Eric Rescorla
On Mon, Dec 19, 2016 at 10:58 PM, wrote: > On Friday, December 16, 2016 at 8:33:48 AM UTC+11, Tantek Çelik wrote: > > On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky <> wrote: > > > On 12/15/16 12:20 PM, Ben Kelly wrote: > > >> > > >> Its more information than nothing. > >

Introducing mozilla::Result for better error handling

2016-12-20 Thread Jan de Mooij
Hi all, A few weeks ago we added mozilla::Result to MFBT [0][1]. I was asked to inform dev-platform about this, so here's a quick overview. mozilla::Result is based on Rust's Result type [2]. It contains either a success value of type V or an error value of type E. For example, a

Intent to implement and ship: Selection::setBaseAndExtent()

2016-12-20 Thread Ms2ger
Summary: Addition to the Selection API that is used by Google Docs (and will hopefully help us improve our performance to match Chrome's) Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1321623 Link to standard: https://w3c.github.io/selection-api/#dom-selection-setbaseandextent Platform

[PSA] [Important] Mac and Windows users of git-cinnabar, please read

2016-12-20 Thread Mike Hommey
Hi, If you are using git-cinnabar on Mac or Windows, *and* have used `git cinnabar download` *and* are using a version of the git-cinnabar release branch that is less than 4 days old as of writing, please upgrade to version 0.4.0rc2 and read the release notes: