Overriding JS to allow for opening in a new tab?

2017-10-25 Thread Andrew Overholt
Is there precedent for doing what a user intended which would be contrary to what the site is attempting? In the case that prompted my question, the user was attempting to middle-click open photos from a Facebook photo album in tabs but the middle-click was handled by the page's JS:

Visual Studio 2017 coming soon

2017-10-25 Thread David Major
I'm planning to move production Windows builds to VS2017 (15.4.1) in bug 1408789. VS2017 has optimizer improvements that produce faster code. I've seen 3-6% improvement on Speedometer. There is also increased support for C++14 and C++17 language features:

Re: Visual Studio 2017 coming soon

2017-10-25 Thread Ted Mielczarek
On Wed, Oct 25, 2017, at 05:48 PM, David Major wrote: > I'm planning to move production Windows builds to VS2017 (15.4.1) in bug > 1408789. Thanks for doing the work on this! > VS2017 has optimizer improvements that produce faster code. I've seen > 3-6% > improvement on Speedometer. There is

Re: Default Rust optimization level decreased from 2 to 1

2017-10-25 Thread Boris Zbarsky
On 10/25/17 1:34 PM, Gregory Szorc wrote: Also, due to ongoing work around Rust integration in the build system, it is dangerous to rely on manual `cargo` invocations to compile Rust because bypassing the build system (not using `mach build`) may not use the same set of RUSTFLAGS that direct

Re: Overriding JS to allow for opening in a new tab?

2017-10-25 Thread Myk Melez
Andrew Overholt 2017 October 25 at 09:41 Is there precedent for doing what a user intended which would be contrary to what the site is attempting? I recall some discussion about preventing sites from using transparent elements to block click event handling, in

Re: Overriding JS to allow for opening in a new tab?

2017-10-25 Thread Dave Townsend
We have some precedent for overriding a site. Popup blocking and redirecting new windows to tabs for example. But I'm not sure how we could technically do this here. If the site is doing some JS work (possibly including async stuff) ultimately ending with an assignment to window.location how would

Default Rust optimization level decreased from 2 to 1

2017-10-25 Thread Gregory Szorc
Compiling Rust code with optimizations is significantly slower than compiling without optimizations. As was measured in bug 1411081, the difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4 cores) for a recent revision of mozilla-central was 325s/802s wall/CPU versus 625s/1282s. This

Re: Intent to Unship: stream decoder for BinHex format

2017-10-25 Thread Eric Shepherd (Sheppy)
Man… It’s weird that this makes me all nostalgic. :) Eric Shepherd Senior Technical Writer, MDN MDN: https://developer.mozilla.org/ Blog: https://www.bitstampede.com/ On October 18, 2017 at 8:50:20 AM, Joshua Cranmer  (pidgeo...@gmail.com) wrote: FWIW, I've considered ripping out the binhex

Re: Default Rust optimization level decreased from 2 to 1

2017-10-25 Thread Boris Zbarsky
On 10/25/17 2:50 PM, Emilio Cobos Álvarez wrote: From mozilla-central I've been using ./mach cargo check gkrust, and I certainly expect it to keep working. Ah, excellent. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Default Rust optimization level decreased from 2 to 1

2017-10-25 Thread Emilio Cobos Álvarez
On 10/25/2017 07:59 PM, Boris Zbarsky wrote: > On 10/25/17 1:34 PM, Gregory Szorc wrote: >> Also, due to ongoing work around Rust integration in the build system, it >> is dangerous to rely on manual `cargo` invocations to compile Rust >> because >> bypassing the build system (not using `mach

Re: Default Rust optimization level decreased from 2 to 1

2017-10-25 Thread Gregory Szorc
On Wed, Oct 25, 2017 at 11:50 AM, Emilio Cobos Álvarez wrote: > > > On 10/25/2017 07:59 PM, Boris Zbarsky wrote: > > On 10/25/17 1:34 PM, Gregory Szorc wrote: > >> Also, due to ongoing work around Rust integration in the build system, > it > >> is dangerous to rely on manual

Re: Intent to ship: Retained Display Lists

2017-10-25 Thread mwoodrow
On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote: > > We're planning on landing the code for retaining display lists in 58, > behind the pref layout.display.list.retain. > This has now landed in Nightly, and looks to be working really well. We'd really appreciate some

Re: Overriding JS to allow for opening in a new tab?

2017-10-25 Thread Boris Zbarsky
On 10/25/17 12:41 PM, Andrew Overholt wrote: Is there precedent for doing what a user intended which would be contrary to what the site is attempting? The first problem is this: How do you know the user wasn't intending what the site is attempting? In the case that prompted my question,