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 logg
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 wil
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
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
https://
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 get
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 alrea
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 m
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
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
th
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, Feb
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
> https://bugzilla.mozilla.org/show_bug
My bad! This is certainly a bug in the linter.
The fix is underway.
On 09.02.2018 12:35, Gijs Kruitbosch wrote:
> 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
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 possibl
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 aarch6
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
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 fai
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 fragmen
17 matches
Mail list logo