Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

2017-07-06 Thread Xidorn Quan
On Fri, Jul 7, 2017, at 02:24 PM, Jet Villegas wrote: > It looks like there may be a lot more of these: > https://stackoverflow.com/a/25397485 > > How about we just stub out the Stylo impls instead of unshipping the pseudo > in content? I'm not unshipping this for Stylo... I just don't feel

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

2017-07-06 Thread Jet Villegas
It looks like there may be a lot more of these: https://stackoverflow.com/a/25397485 How about we just stub out the Stylo impls instead of unshipping the pseudo in content? On Thu, Jul 6, 2017 at 9:03 PM, Xidorn Quan wrote: > On Fri, Jul 7, 2017, at 01:42 PM, Jet Villegas

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

2017-07-06 Thread Xidorn Quan
On Fri, Jul 7, 2017, at 01:42 PM, Jet Villegas wrote: > Thanks for cleaning this up. > > On Thu, Jul 6, 2017 at 8:29 PM, Xidorn Quan wrote: > > > Although they don't currently match anything on web content, there is > > still some risk for unshipping them. Specifically, some

Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

2017-07-06 Thread Jet Villegas
What do we expect to break? Who's out there using these APIs now? Thanks, --Jet On Thu, Jul 6, 2017 at 8:21 PM, Tim Huang wrote: > I intent to unship the support of moz*Frames of HTMLVideoElement including > * HTMLVideoElement.mozParsedFrames > *

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

2017-07-06 Thread Jet Villegas
Thanks for cleaning this up. On Thu, Jul 6, 2017 at 8:29 PM, Xidorn Quan wrote: > Although they don't currently match anything on web content, there is > still some risk for unshipping them. Specifically, some websites seem to > use them for browser-sniffing. Do you have some

Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

2017-07-06 Thread Xidorn Quan
I intent to unship tree pseudo-element selectors from web content in bug 1379031 [1]. This includes the following pseudo-elements: ::-moz-tree-column ::-moz-tree-row ::-moz-tree-separator ::-moz-tree-cell ::-moz-tree-indentation ::-moz-tree-line ::-moz-tree-twisty ::-moz-tree-image

Intent to unship: moz*Frames attributes of HTMLVideoElement

2017-07-06 Thread Tim Huang
I intent to unship the support of moz*Frames of HTMLVideoElement including * HTMLVideoElement.mozParsedFrames * HTMLVideoElement.mozDecodedFrames * HTMLVideoElement.mozPresentedFrames * HTMLVideoElement.mozPaintedFrames * HTMLVideoElement.mozFrameDelay in Bug 1379050 [1]. The

CodeCoverage Monthly Update

2017-07-06 Thread Kyle Lahnakoski
## Summary of Past Quarter Coverage is enabled for nearly all tests, and scheduled every push [1]!! * All c/c++ test suites have coverage enabled * talos coverage is enabled * jsvm[7] coverage is enabled, and running * codecov.io [2] shows the results, broken down by directory ##

Re: Embedding Firefox or Gecko in 2017

2017-07-06 Thread Ralph Giles
You're right that this isn't currently easy to do. A more recent project, now also abandoned, was https://github.com/mozilla/positron You might see if that's a place to start. -r On Thu, Jul 6, 2017 at 12:47 PM, cnico7 wrote: > Hi, > > I would like to embed gecko

Re: Linting for common causes of oranges in mochitests (need ideas)

2017-07-06 Thread Andrew Halberstadt
Great idea, I'll add that to the list! Times actually are on that page too, I just didn't know about performance.now() as an alternative. Also, it was pointed out to me that in order to answer question 1) it would help to know how to disable these rules. Eslint rules can be disabled at the line

Embedding Firefox or Gecko in 2017

2017-07-06 Thread cnico7
Hi, I would like to embed gecko or firefox in a native windows application. The need is to be able to use gecko's rendering and javascript engines in order to display web pages that are not correctly displayed with other browsers (mainly for legacy reasons of the intranet web site). Those pages

Re: Linting for common causes of oranges in mochitests (need ideas)

2017-07-06 Thread Chris Peterson
On 7/6/17 11:47 AM, Andrew Halberstadt wrote: # Are there additional things not listed on that page that we could lint for? Do we want to discourage tests from using Date (`new Date` or `Date.now()`) for measuring time? Dates are affected by time zones, DST, and clock skew issues jumping

Linting for common causes of oranges in mochitests (need ideas)

2017-07-06 Thread Andrew Halberstadt
I'm looking into creating custom eslint rules that aim to avoid common causes of oranges in tests. We have an MDN page containing some of these already. Some of those patterns might be pretty hard to catch with a

Re: Enabling filesystem read-restrictions for content process sandbox

2017-07-06 Thread Frederik Braun
Hooray, this is great news! On 06.07.2017 16:07, Alex Gaynor wrote: > Hi dev-platform, > > On behalf of the Runtime Content Isolation (aka sandboxing) team, I'm > delighted > to announce that starting later this week, our macOS and Windows nightly > builds > will prohibit read access to most of

Enabling filesystem read-restrictions for content process sandbox

2017-07-06 Thread Alex Gaynor
Hi dev-platform, On behalf of the Runtime Content Isolation (aka sandboxing) team, I'm delighted to announce that starting later this week, our macOS and Windows nightly builds will prohibit read access to most of the filesystem in the content process! What does this mean for you? First and

Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

2017-07-06 Thread Marcos Caceres
On July 6, 2017 at 1:40:13 PM, L. David Baron (dba...@dbaron.org) wrote: > I've taken what you (Tantek) wrote and made minor changes to yield > the following Formal Objection to the Web Platform WG charter. I support the updated formal objection. Thanks Tantek for drafting it. I've raised these

Re: `mach cargo check` now available

2017-07-06 Thread Nathan Froyd
On Thu, Jul 6, 2017 at 2:28 AM, Simon Sapin wrote: > Would it make sense to allow arbitrary Cargo sub-commands? In Servo I end up > using `mach cargo update` for manipulating Cargo.lock, `mach cargo rustc` > for passing debugging options to the compiler, etc. Maybe! I'm

Re: `mach cargo check` now available

2017-07-06 Thread Simon Sapin
On 06/07/2017 03:18, Nathan Froyd wrote: Cargo recently added a subcommand, `cargo check`, to perform type checking of Rust crates without the additional step of code generation. As code generation tends to dominate Rust compilation times, `cargo check` speeds up the edit-borrow