Re: Intent to require `mach try` for submitting to Try

Does "mozilla/mach try" will work for try-comm-central? (Well, I know there has been a general talk of moving thunderbird to somewhere else, but it is not going to happen overnight.) TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

Hey Ehsan, > On Sep 15, 2017, at 9:28 PM, Ehsan Akhgari wrote: > I'm worries about the "FF57" part of this paragraph. There is almost no time > left to test this kind of change on Nightly so this will probably get tested > for the first few betas of 57. Even though

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc wrote: > On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla wrote: > >> What happens if you are using git? >> > > git-cinnabar is already supported. > Supported how? Do I have to have special remote names? Special

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla wrote: > What happens if you are using git? > git-cinnabar is already supported. Vanilla git is TBD. I see bug 1400470 was just filed for that. > > On Fri, Sep 15, 2017 at 3:30 PM, Gregory Szorc wrote: > >> The

Re: Intent to require `mach try` for submitting to Try

Yes, we'd like to make it the default eventually. I've been holding off for now, but expect it will be switched to the default at some point in Q4 or Q1. If you don't want to wait and are tired of typing 'fuzzy' each time, you can create a ~/.mozbuild/machrc file and add: [try] default = fuzzy On

Re: Intent to require `mach try` for submitting to Try

What happens if you are using git? -Ekr On Fri, Sep 15, 2017 at 3:30 PM, Gregory Szorc wrote: > The Try Service ("Try") is a mechanism that allows developers to schedule > tasks in automation. The main API for that service is "Try Syntax" (e.g. > "try: -b o -p linux -u

Re: Intent to require `mach try` for submitting to Try

On 9/15/17 10:08 PM, Steve Fink wrote: I've never used it, but it already has pretty much exactly this. Look at --save, --preset, and --list-presets under ./mach help try syntax Ah, I see. Alright, I'll give this a shot. -Boris ___ dev-platform

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 6:58 PM, Boris Zbarsky wrote: > On 9/15/17 6:30 PM, Gregory Szorc wrote: > >> we'd like to require the use of `mach try` for Try >> submissions. >> > > So just to be clear, instead of being able to "hg push -f try" will one > now need to do "./mach try

Re: Intent to require `mach try` for submitting to Try

On 9/15/17 6:58 PM, Boris Zbarsky wrote: On 9/15/17 6:30 PM, Gregory Szorc wrote: we'd like to require the use of `mach try` for Try submissions. So just to be clear, instead of being able to "hg push -f try" will one now need to do "./mach try syntax ." and put in the actual syntax

Re: Intent to require `mach try` for submitting to Try

On 9/15/17 6:30 PM, Gregory Szorc wrote: we'd like to require the use of `mach try` for Try submissions. So just to be clear, instead of being able to "hg push -f try" will one now need to do "./mach try syntax ." and put in the actual syntax string on every single try push? The reason

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 4:51 PM, Nicholas Nethercote wrote: > Are there docs on how to use `./mach try`? `./mach help try` doesn't give > much detail. > `mach try` has sub-commands. Run `mach help try syntax` and `mach help try fuzzy` for more useful docs. The former is

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 4:48 PM, Nick Fitzgerald wrote: > Does `mach try` still require `git cinnabar` when using a `git` checkout > of m-c, or does it work with `moz-git-tools` now too? > It currently requires git-cinnabar. TBH, I forgot about this. Supporting

Re: Intent to require `mach try` for submitting to Try

I should have been clearer: I'm not so worried about the syntax, so long as https://mozilla-releng.net/trychooser/ still exists. What's unclear to me is the revision management/selection side of things. Nick On Sat, Sep 16, 2017 at 9:57 AM, Kris Maglione wrote: > `mach

Re: Intent to require `mach try` for submitting to Try

`mach try` is basically just a wrapper around try syntax, with the added ability to specify paths to directories you want to add tests for. It suffers the same lack of documentation that try syntax in general does. Trychooser now generates `mach try` command lines in addition to commit

Re: Intent to require `mach try` for submitting to Try

FWIW, I've found |./mach try fuzzy| to be very intuitive and kind of the best of both worlds for command-line vs GUI. I don't know what the non-fuzzy version does, but perhaps fuzzy should be the default. On Fri, Sep 15, 2017 at 4:51 PM, Nicholas Nethercote wrote: > Are

Re: Intent to require `mach try` for submitting to Try

Are there docs on how to use `./mach try`? `./mach help try` doesn't give much detail. Also, will https://mozilla-releng.net/trychooser/ still work? I'm generally more of a command line person than a GUI person, but this is one case where I find the GUI approach far more usable. Nick On Sat,

Re: Intent to require `mach try` for submitting to Try

Does `mach try` still require `git cinnabar` when using a `git` checkout of m-c, or does it work with `moz-git-tools` now too? Thanks, Nick On Fri, Sep 15, 2017 at 3:30 PM, Gregory Szorc wrote: > The Try Service ("Try") is a mechanism that allows developers to schedule >

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 3:39 PM, Botond Ballo wrote: > Will submitting to try from MozReview (or Phabricator once that > replaces MozReview) still work? I think there is important value in > being able to submit to try without a local checkout. > Yes. And I agree there is

Re: Intent to require `mach try` for submitting to Try

Will submitting to try from MozReview (or Phabricator once that replaces MozReview) still work? I think there is important value in being able to submit to try without a local checkout. Cheers, Botond ___ dev-platform mailing list

Intent to require `mach try` for submitting to Try

The Try Service ("Try") is a mechanism that allows developers to schedule tasks in automation. The main API for that service is "Try Syntax" (e.g. "try: -b o -p linux -u xpcshell"). And the transport channel for making that API call is a Mercurial changeset's commit message plus a version control

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Tuesday, September 5, 2017 at 10:57:58 AM UTC-7, Jim Blandy wrote: > As an offer of help, from a group whose charter covers this work, that's > very welcome. I felt that I was being shepherded into something on behalf > of others for whom I cannot speak, which was uncomfortable! > > For my own

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

Hi Christoph, On 09/15/2017 01:08 PM, Christoph Kerschbaumer wrote: Hey Everyone, we plan to prevent web pages from navigating the top-level window to a data: URI. Historically data: URIs caused confusion for end users; mostly because end users are not aware that data: URIs can encode

Re: Incoming JS module (JSM) / component loader changes

On Thu, Aug 31, 2017 at 11:14 AM, Kris Maglione wrote: > A quick heads-up on some incoming changes to the JS component loader that > may affect some existing JSM or JS component code: > > 1) As of bug 1394556[1], all JS module and component scripts are > automatically

Re: Intent to unship: Visibility of window.content to untrusted code

On 09/14/2017 05:37 PM, Boris Zbarsky wrote: On 9/14/17 5:33 PM, Ehsan Akhgari wrote: I think either of these two ideas would be good, but I think unshipping in 57 is premature without having an understanding of how much the Web depends on this for UA sniffing. OK. Do you have any

Re: Reminder on Try usage and infrastructure resources

On 15/09/17 18:45, Dan Mosedale wrote: I wonder if this isn't (in large part) a design problem disguised as a behavior problem. The existing try syntax (even with try chooser) is so finicky and filled with abbreviations that even after years of working with it, I still regularly have to look up

Re: Reminder on Try usage and infrastructure resources

I wonder if this isn't (in large part) a design problem disguised as a behavior problem. The existing try syntax (even with try chooser) is so finicky and filled with abbreviations that even after years of working with it, I still regularly have to look up stuff and sometimes when I've been in a

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

On 9/15/17 10:08 AM, Christoph Kerschbaumer wrote: > To mitigate that risk we installed a pref > (“security.data_uri.block_toplevel_data_uri_navigations”) which blocks all > top-level navigations to a data: URI. We plan to flip that pref in Nightly > using “ifdef EARLY_BETA_OR_EARLIER”. In a

Re: Intent to unship: Top-level Navigations to a data: URI

Just to clear up the headline: we intend to unship "top level navigations to data:" (currently allowed) by blocking them. The body of the message was clear, just fixing the subject for people (and twitter bots) that don't get that far. -Dan Veditz ___

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

You read my mind -- thanks! Alex On Fri, Sep 15, 2017 at 1:16 PM, Christoph Kerschbaumer wrote: > > On Sep 15, 2017, at 7:14 PM, Alex Gaynor wrote: > > Hi Christoph, > > Great stuff! > > Are external applications able to trigger loads of data:, e.g. a

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

> On Sep 15, 2017, at 7:14 PM, Alex Gaynor wrote: > > Hi Christoph, > > Great stuff! > > Are external applications able to trigger loads of data:, e.g. a desktop mail > application, via the OS protocol handler facilities? Sorry I forgot to mention that explicitly. Since

Re: Intent to unship: Blocking Top-level Navigations to a data: URI

Hi Christoph, Great stuff! Are external applications able to trigger loads of data:, e.g. a desktop mail application, via the OS protocol handler facilities? Alex On Fri, Sep 15, 2017 at 1:08 PM, Christoph Kerschbaumer wrote: > Hey Everyone, > > we plan to prevent web

Intent to unship: Blocking Top-level Navigations to a data: URI

Hey Everyone, we plan to prevent web pages from navigating the top-level window to a data: URI. Historically data: URIs caused confusion for end users; mostly because end users are not aware that data: URIs can encode untrusted content into a URL. The fact that data: URIs can execute

Re: Reminder on Try usage and infrastructure resources

Masayuki, your try push had trouble because you requested "mochitest-2" instead of "mochitest-e10s-2". Non-e10s mochitests only run on Android and Windows now. You probably wanted something like: https://treeherder.mozilla.org/#/jobs?repo=try=d68382f17d63f0674c62acc7242a9e406793895f This is a

Re: Eiminating nsIDOM* interfaces and brand checks

On 9/15/17 9:58 AM, David Bruant wrote: Maybe @@toStringTag will end up not working well enough for your need anyway. Not least because its use is kinda ugly, no? But another solution could be to define a chromeonly symbol for the brand. obj[Symbol.brand] === 'HTMLEmbedElement'

Re: Re-visiting the DOM tree depth limit in layout

On 9/15/17 6:35 AM, Henri Sivonen wrote: I'm assuming that anonymous frames count towards the limit and a display: table-cell that doesn't belong to a table ends up creating 5 frames. Correct? Yes for both. It creates a table, table-row-group, table-row, table-cell, and a block inside the

Re: Re-visiting the DOM tree depth limit in layout

On Thu, Sep 14, 2017, at 02:23 AM, Henri Sivonen wrote: > Do I understand correctly that this is an address space issue only and > Windows doesn't actually physically map the pages belonging to the > stack until they are written to? That is, do I understand correctly > that there's no obstacle for

Re: Reminder on Try usage and infrastructure resources

Even when I got the chunk numbers, specifying chunk numbers of mochitests wouldn't work, see this log: https://treeherder.mozilla.org/#/jobs?repo=try=c09c7046ed0664e89f7224e1de5219c39c94c948 After that, I needed to rerun mochitests with |-u mochitests|. IIRC, I tried to kick the specific chunks

Re: Reminder on Try usage and infrastructure resources

I tried to say different point. See the treehearder log, mochitests didn't run except on Win7 Debug, Android 4.3 API16+ Opt/Debug. So, try syntax parser or something is really broken. I often meet this kind of bug. On 9/15/2017 10:07 AM, Kris Maglione wrote: Your best bet is probably to use

Re: Eiminating nsIDOM* interfaces and brand checks

Hi, Sorry, arriving a bit late to the party. I was about to propose something related to @@toStringTag, but reading the discussions about how it may/will work [1][2][3], i realize it may not be your preferred solution. Maybe @@toStringTag will end up not working well enough for your need

Re: Re-visiting the DOM tree depth limit in layout

Also, it seems that Android doesn't use the Linux stack defaults. Is the stack size under our control on Android? On Fri, Sep 15, 2017 at 1:35 PM, Henri Sivonen wrote: > On Fri, Sep 15, 2017 at 12:26 PM, Henri Sivonen wrote: >> From black-box

Re: Re-visiting the DOM tree depth limit in layout

On Fri, Sep 15, 2017 at 12:26 PM, Henri Sivonen wrote: > From black-box testing, it seems that some part of layout has gotten a > new << 200 depth limit for nested display:table-cell some time between > September 11 and September 14. > > To save myself the trouble of

Re: Reminder on Try usage and infrastructure resources

On 15/09/17 00:53, Dustin Mitchell wrote: 2017-09-14 18:32 GMT-04:00 Botond Ballo : I think "-p all" is still useful for "T pushes" (and it sounds like build jobs aren't the main concern resource-wise). Correct -- all builds are in AWS. I'd like to steer this away from

Re: Re-visiting the DOM tree depth limit in layout

>From black-box testing, it seems that some part of layout has gotten a new << 200 depth limit for nested display:table-cell some time between September 11 and September 14. To save myself the trouble of bisecting this, does anyone know which patch did this and why? -- Henri Sivonen