Re: Treeherder New Login Flow

On 2/9/18 9:30 AM, ha...@mozilla.com wrote: > - Treeherder session will stay alive as long as access to the site > happens once every 24 hours. 3 days session expiry is no longer in > effect. This doesn't seem to be the case: I'm logged in when I go to bed, and 7 hours later when I get up I'm

Re: Improved wpt-sync now running experimentally

On 09/02/2018 19:59, Josh Bowman-Matthews wrote: On 2/9/18 1:26 PM, James Graham wrote: * One bug per PR we downstream, filed in a component determined by the files changed in the PR. What does this mean exactly? What is the desired outcome of these bugs? They're tracking the process and

Re: Improved wpt-sync now running experimentally

On 2/9/18 1:26 PM, James Graham wrote: * One bug per PR we downstream, filed in a component determined by the files changed in the PR. What does this mean exactly? What is the desired outcome of these bugs? Cheers, Josh ___ dev-platform mailing list

Re: Improved wpt-sync now running experimentally

On 2/9/18 1:26 PM, James Graham wrote: The new code is intended to provide the following improvements over the old periodic batch sync approach: Thank you. This is awesome. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Improved wpt-sync now running experimentally

The new sync for web-platform-tests is now running experimentally. This provides two way sync between the w3c/web-platform-tests repository on GitHub and mozilla-central, so allowing gecko developers to contribute to web-platform-tests using their normal gecko workflow, and ensuring that we

Treeherder New Login Flow

Hi, I am writing to inform you about Treeherder’s new login flow. In the past, logging in with Treeherder meant being redirected to the login.taskcluster.net service. This had a couple of drawbacks, but one of the main annoyance was that credentials expired every 3 days. You are probably

Re: Chrome will start marking HTTP pages as "Not secure"

Yeah, there's a team working on this stuff (and they/we have been in touch with the Chrome people for a long time) and this is not a call we should make on a mailing list. There's a valid concern around warning fatigue (plastering so many sites with "Insecure" that users easily dismiss it) and we

Re: Chrome will start marking HTTP pages as "Not secure"

Hey, So we have two issues here: - We have less testing on security.insecure_connection_text.enabled - security.insecure_connection_icon.enabled is a lot heavier handed as MT notes and also we use this for insecure passwords too. We also have the pbmode variants if we wanted both enabled when in

Intent to remove: Throttling of timeouts from tracking scripts

TL;DR We have decided to not (re-)turn on throttling of timeouts from tracking scripts, and also remove throttling of timeouts from tracking scripts altogether. This feature was, in the beginning, only intended for tabs in the background, but experiments were also conducted to see the effect of

Re: Chrome will start marking HTTP pages as "Not secure"

If you flip just security.insecure_connection_text.enabled and not security.insecure_connection_icon.enabled you get Chrome's behavior. Flipping both gives you the broken lock and the "Not Secure" text. I don't see a big difference there and I hope we can ship this as soon as possible. On Fri,

Re: gkrust compilation RAM requirements and 32-bit systems

On Fri, Feb 9, 2018 at 12:00 PM, Emilio Cobos Álvarez wrote: > On 02/09/2018 10:49 AM, Henri Sivonen wrote: >> Is there some trick to make gkrust compilation succeed on a 32-bit system? > > The BSD folks seem to be using --disable-debug-symbols for that, see >

Re: PSA: HTML injection in chrome documents is now automatically sanitized

Sorry about the waste of time. :-( Re: difficulty: it depends on your measure of 'very'. Internally the sanitization is whitelist-based. It is used in many places (not just for chrome-privileged docs), where it would be wrong to show warnings (possibly very *many* warnings!). It may be

Re: gkrust compilation RAM requirements and 32-bit systems

On Fri, Feb 9, 2018, at 4:49 AM, Henri Sivonen wrote: > Is it expected that Firefox can no longer be built on a 32-bit system? Yes. > The cross-compilation documentation on MDN seems to predate Rust code > in Firefox. Is there an up-to-date guide for compiling Firefox for > ARMv7+NEON (or

Re: gkrust compilation RAM requirements and 32-bit systems

On 02/09/2018 10:49 AM, Henri Sivonen wrote: > Is there some trick to make gkrust compilation succeed on a 32-bit system? The BSD folks seem to be using --disable-debug-symbols for that, see https://bugzilla.mozilla.org/show_bug.cgi?id=1401093 -- Emilio

gkrust compilation RAM requirements and 32-bit systems

Previously, the RAM-critical operation during Firefox build was linking libxul, which on Linux was known not to work with 1 GB of RAM but did work with 2 GB of RAM. Now, when trying to build Firefox (opt build) on ARMv7 Linux with 2.3 GB of *free* RAM at the start of the build, building gkrust

Re: PSA: HTML injection in chrome documents is now automatically sanitized

On Friday, February 2, 2018 at 2:11:02 AM UTC-8, Gijs Kruitbosch wrote: > In the further future, I expect this type of problem will go away > entirely because of Fluent. That's correct! Fluent brings the concept of DOM Overlays which allow for safe mixing between developer provided DOM