On Tue, Aug 8, 2017 at 6:17 AM, Kris Maglione wrote:
> On nightlies and
> in unbranded builds, it will still be possible to enable them by flipping a
> pref, but they will be completely unsupported.
>
> Yes, that means that some users and developers will continue to use them,
> and continue to get
On Tue, Aug 8, 2017 at 1:12 AM, Mike Hommey wrote:
> Here's a bunch of data why "let's switch compilers" is not necessarily
> easy (I happen to have gathered that recently):
Thank you.
> Newer versions of clang-cl might generate faster code, but they crash
> during the build: https://bugs.llvm.o
On 8/7/17 11:17 PM, Kris Maglione wrote:
There isn't. Not as such, anyway. By the end of the week, legacy
extensions that aren't specially signed will be disabled by default.
That fits what I want. That being a notification to nightly users that
says "These are now officially unsupported; if
On Mon, Aug 07, 2017 at 08:50:38PM -0700, Fabrice Desre wrote:
On 08/07/2017 08:17 PM, Kris Maglione wrote:
Yes, that means that some users and developers will continue to use
them, and continue to get upset when they break, but that's what
they're signing up for when they flip the preference.
On 08/07/2017 08:17 PM, Kris Maglione wrote:
Yes, that means that some users and developers will continue to use
them, and continue to get upset when they break, but that's what they're
signing up for when they flip the preference. I tend to compare this to
the rooted Android ecosystem. People
On Mon, Aug 07, 2017 at 10:58:11PM -0400, Boris Zbarsky wrote:
On 8/7/17 6:17 PM, Nicholas Nethercote wrote:
Is there going to be a clear point in time when legacy extensions stop
working in Nightly?
I was under the impression that there is, and I strongly feel there
should be.
There isn't.
On 8/7/17 6:17 PM, Nicholas Nethercote wrote:
Is there going to be a clear point in time when legacy extensions stop
working in Nightly?
I was under the impression that there is, and I strongly feel there
should be.
-Boris
___
dev-platform mailing
More than fine, this is an overdue change :)
Notifications being available on http:// origins is a source of a
small amount of pain for web push, because the two share the same
permission.
On Tue, Aug 8, 2017 at 2:24 AM, Eric Rescorla wrote:
> This seems fine.
>
> -Ekr
>
>
> On Mon, Aug 7, 2017
On Tue, Aug 08, 2017 at 07:12:13AM +0900, Mike Hommey wrote:
> On Fri, Aug 04, 2017 at 08:45:14AM +0300, Henri Sivonen wrote:
> > I guess I buried my questions in too long a post, so extracting them:
> >
> > On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen wrote:
> > > Naïvely, one would think that
On Tue, Aug 8, 2017 at 7:12 AM, Boris Zbarsky wrote:
>
> So if right now we land a patch that breaks addons, and a nightly user
> updates, they get a broken browser and have to try to figure out whether
> it's because we broken an addon (and this may not be the first thing they
> think of) or bec
On Fri, Aug 04, 2017 at 08:45:14AM +0300, Henri Sivonen wrote:
> I guess I buried my questions in too long a post, so extracting them:
>
> On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen wrote:
> > Naïvely, one would think that it should be possible to do that with
> > clang producing "object file
Just for reference. With latest NoScript View Source is broken and it throws
an exception now and then. Still on Beta because of this one. I won't browse
the web without it.
For me Web Extensions do not cut it yet and Classic Extensions are unsupported
and go away. Bad timing even on a Nightly
On 8/7/17 1:05 PM, Kris Maglione wrote:
So what is the state of things at the moment? Should we just turn off
old-style addons on nightly? If not, then we should probably stop
breaking them until we _do_ turn them off.
I don't think so. Extension authors know the score here.
OK, I thought a
Correction to my earlier claims about our minimum memory requirement.
The stub installer will default to 64-bit for users with >= 1800 MB. So
users with exactly 2 GB should get 64-bit Firefox. Only Win64 users with
strictly less than 2 GB will default to 32-bit Firefox.
Why the magic number 1
On Mon, Aug 07, 2017 at 07:03:52PM +0100, Jonathan Kew wrote:
On 07/08/2017 18:05, Kris Maglione wrote:
At the moment, legacy add-ons are allowed on nightly, but are
officially unsupported. We're planning to disable them by default on
nightlies, but it will still be possible to enable them by f
On 07/08/2017 18:05, Kris Maglione wrote:
At the moment, legacy add-ons are allowed on nightly, but are officially
unsupported. We're planning to disable them by default on nightlies, but
it will still be possible to enable them by flipping a pref.
Will that pref still be available in 57 once
On Mon, Aug 7, 2017 at 10:05 AM, Kris Maglione
wrote:
> At the moment, legacy add-ons are allowed on nightly, but are officially
> unsupported. We're planning to disable them by default on nightlies, but it
> will still be possible to enable them by flipping a pref.
And we didn't mean to create
On Mon, Aug 07, 2017 at 12:31:30PM -0400, Boris Zbarsky wrote:
On 6/14/17 9:02 AM, Benjamin Smedberg wrote:
Given that old-style addons are going away for 57, if it's possible to
delay addon-breaking IDL changes by one release until 57 that's probably
the easiest way to deal with this. We're alr
On 6/14/17 9:02 AM, Benjamin Smedberg wrote:
Given that old-style addons are going away for 57, if it's possible to
delay addon-breaking IDL changes by one release until 57 that's probably
the easiest way to deal with this. We're already causing the addon
community a lot of churn.
I'd like to g
This seems fine.
-Ekr
On Mon, Aug 7, 2017 at 6:45 AM, Anne van Kesteren wrote:
> Chrome wants to restrict the Notifications API
> https://notifications.spec.whatwg.org/ to secure contexts:
>
> https://github.com/whatwg/notifications/issues/93
> https://github.com/w3c/web-platform-tests/pul
On 8/7/17 11:28 AM, Enrico Weigelt, metux IT consult wrote:
hmm, then what are the partial interfaces actually for ?
They're for use in specifications that want to add things to an existing
interface. They're a specification device, basically.
I had the impression that distributing (potent
On 07.08.2017 17:17, Boris Zbarsky wrote:
Can I move that stuff to a separate webidl file, which is only
added in dom/webidl/moz.build when wakelocks enabled ?
(so no #ifdef's in Navigator.webidl needed)
If you try to do this, you will get a message from binding codegen that
explicitly says t
On 07.08.2017 15:45, Anne van Kesteren wrote:
Chrome wants to restrict the Notifications API
https://notifications.spec.whatwg.org/ to secure contexts:
wait a second ... it was wide open all the time ?
--mtx
___
dev-platform mailing list
dev-platfor
On 8/6/17 3:56 PM, Enrico Weigelt, metux IT consult wrote:
is there a way to use the partial interfaces for build-time
configurable features ?
Not without #ifdef.
Can I move that stuff to a separate webidl file, which is only
added in dom/webidl/moz.build when wakelocks enabled ?
(so no #ifde
Chrome wants to restrict the Notifications API
https://notifications.spec.whatwg.org/ to secure contexts:
https://github.com/whatwg/notifications/issues/93
https://github.com/w3c/web-platform-tests/pull/6596
Given that the API involves prompting the user as well as a permission
that remains s
On 07.08.2017 10:31, Gabriele Svelto wrote:
On 06/08/2017 21:56, Enrico Weigelt, metux IT consult wrote:
For example, I'm currently working on making the whole wakelock
stuff optional (eg. only built on android). Navigator.webidl
references MozWakeLock, which wouldn't exist w/o wakelocks.
Do y
On 8/7/2017 3:51 AM, Chris Peterson wrote:
Do we test 32-bit Firefox on Win32 or Win64 today?
Our Win32 tests run on 32-bit Windows 7 instances. I don't know offhand
if we're using the /3GB switch or not.
-Ryan
___
dev-platform mailing list
dev-pla
Hi everyone,
Here's the list of new issues found and filed by the Desktop Release QA
Team last week, *July 31 - August 4* (week 31).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://public.etherpad-mozilla.org/p/De
On 06/08/2017 21:56, Enrico Weigelt, metux IT consult wrote:
> For example, I'm currently working on making the whole wakelock
> stuff optional (eg. only built on android). Navigator.webidl
> references MozWakeLock, which wouldn't exist w/o wakelocks.
Do you mean navigator.requestWakeLock()? That'
I think the 2GB "requirement" from Microsoft should be ignored, because
plenty of our users are ignoring it.
Nick
On Mon, Aug 7, 2017 at 5:51 PM, Chris Peterson
wrote:
> On 2017-08-06 11:26 PM, Henri Sivonen wrote:
>
>> On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson
>> wrote:
>>
>>> Users wit
On 2017-08-06 11:26 PM, Henri Sivonen wrote:
On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson wrote:
Users with only 2 GB and 5 minute browser sessions would probably have a
faster user experience with 32-bit Firefox than with 64-bit, but how do we
weigh that experience versus the security bene
31 matches
Mail list logo
