Re: Changing .idl files

[Boris Zbarsky]

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 you force-enable them, 
you will likely have issues and should not be surprised".



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.


Right.  I'm a lot more ok with this than stealth-breaking stuff without 
people even realizing we might have broken it.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Kris Maglione]

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. I tend to 
compare this to the rooted Android ecosystem. People who develop for 
that environment know that they have no official support, and their 
apps are never going to reach a broad user base.. People who setup 
that environment know that things are going to be unstable, and apps 
are going to break. But for one reason or another, it's worth it to 
them.


Slight difference is that rooted-Android users were always in this 
situation, while things will degrade for Firefox Nightly users.


They'll degrade for Firefox nightly users one way or the other. 
The ones who want to continue using legacy add-ons will need to 
opt into continuing to use them as an unsupported feature. The 
ones that don't opt in will simply lose those add-ons.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Fabrice Desre]

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 who develop for that environment 
know that they have no official support, and their apps are never going 
to reach a broad user base.. People who setup that environment know that 
things are going to be unstable, and apps are going to break. But for 
one reason or another, it's worth it to them.


Slight difference is that rooted-Android users were always in this 
situation, while things will degrade for Firefox Nightly users.


  Fabrice

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Kris Maglione]

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. Not as such, anyway. By the end of the week, legacy 
extensions that aren't specially signed will be disabled by 
default. 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 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 who 
develop for that environment know that they have no official 
support, and their apps are never going to reach a broad user 
base.. People who setup that environment know that things are 
going to be unstable, and apps are going to break. But for one 
reason or another, it's worth it to them.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Boris Zbarsky]

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 list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Restricting the Notifications API to secure contexts

[Martin Thomson]

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 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/pull/6596
>>
>> Given that the API involves prompting the user as well as a permission
>> that remains stored across different networks it seems like a good
>> idea to restrict this API to HTTPS.
>>
>> I was wondering if anyone has concerns with restricting the API as
>> such. If there are no concerns within a week I'll let Chrome go ahead
>> with the change to the standard and tests and file the necessary
>> implementation bugs against the remaining browsers, including Firefox.
>>
>>
>> --
>> https://annevankesteren.nl/
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More Rust code

[Mike Hommey]

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 it should be possible to do that with
> > > clang producing "object files" holding LLVM IR and rustc producing
> > > "object files" holding LLVM IR and the "link" step involving mashing
> > > those together, running LLVM optimizations again and then producing
> > > machine code from a massive collection of mashed-together LLVM IR.
> > ...
> > > If we were compiling C++ using clang on all platforms, how far off
> > > would such cross-language inlining be?
> > >
> > > If we could have the cross-language inlining benefit from compiling
> > > C++ using clang on all platforms, how far off would we be from being
> > > able to switch to clang on all platforms?
> 
> Here's a bunch of data why "let's switch compilers" is not necessarily
> easy (I happen to have gathered that recently):
> 
> Windows MSVC (PGO) vs. clang-cl:
> https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=581eab2aa162=try=c963d0cd6565=1=0
> 
> Windows MSVC (PGO) vs. clang-cl -O2 (the build system currently uses -O1 for
> msvc builds, which flags we use for clang-cl builds):
> https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=581eab2aa162=try=c963d0cd6565=1=0

It was pointed to me that both urls were the same. The second is
actually:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=581eab2aa162=try=232f977d9739=1=0

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Nicholas Nethercote]

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 because we introduced a bug that they should report.
>

I switched from Nightly to Release on my main work machine after
yesterday's Nightly update broke both Tree Style Tab and ChatZilla. I heard
that Tree Style Tab was fixed again shortly afterward.

I also heard that both of these may have been caused by disabling e10s
shims, or something like that, but I don't know if it's correct.


> So I strongly feel that to avoid wasting the time and effort of our
> nightly users we should not start landing addon-breaking changes (or at
> least ones that might cause exceptions in addons that break various browser
> functionality) until after we have disabled addons.
>

Is there going to be a clear point in time when legacy extensions stop
working in Nightly? I have the impression it'll be more of a slow
degradation.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More Rust code

[Mike Hommey]

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 files" holding LLVM IR and rustc producing
> > "object files" holding LLVM IR and the "link" step involving mashing
> > those together, running LLVM optimizations again and then producing
> > machine code from a massive collection of mashed-together LLVM IR.
> ...
> > If we were compiling C++ using clang on all platforms, how far off
> > would such cross-language inlining be?
> >
> > If we could have the cross-language inlining benefit from compiling
> > C++ using clang on all platforms, how far off would we be from being
> > able to switch to clang on all platforms?

Here's a bunch of data why "let's switch compilers" is not necessarily
easy (I happen to have gathered that recently):

Windows MSVC (PGO) vs. clang-cl:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=581eab2aa162=try=c963d0cd6565=1=0

Windows MSVC (PGO) vs. clang-cl -O2 (the build system currently uses -O1 for
msvc builds, which flags we use for clang-cl builds):
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=581eab2aa162=try=c963d0cd6565=1=0

Newer versions of clang-cl might generate faster code, but they crash
during the build: https://bugs.llvm.org/show_bug.cgi?id=33997

  Note that the tp5n main_startup_fileio reflects the resulting size of
  xul.dll, which also impacts the installer size:
 32-bits   64-bits
  MSVC (PGO):   37904383  40803170
  clang-cl: 39537860  40561849
  clang-cl -O2: 41976097  43338891

  64-bits clang-cl is miraculously smaller, but the zip is larger, and so
  is the on-disk xul.dll.


Linux gcc 4.9 PGO vs clang trunk (r309511):
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=3c83f65009d6=try=5d22234f2596=1=0

This might look unfair (PGO vs. not-PGO), but for some reason, trying
PGO with clang breaks the build... while invoking cargo...
https://treeherder.mozilla.org/#/jobs?repo=try=8aeb26f7b22b7c8a03602229caa79d20bdadc94d
if anyone wants to take a look.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Frank-Rainer Grahl]

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. You should have waited till ESR 59 
for mass removals of interfaces and to stabilize this more.


FRG

Boris Zbarsky wrote:

On 8/7/17 1:05 PM, Kris Maglione 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 because we introduced a bug that they should report.


So I strongly feel that to avoid wasting the time and effort of our nightly 
users we should not start landing addon-breaking changes (or at least ones 
that might cause exceptions in addons that break various browser 
functionality) until after we have disabled addons.


Note that the issues addon authors are having are precisely the "we don't want 
to make nightly users' lives hell, so we're trying to make sure our addons 
keep working for the users who have them installed" issue.  As in, they're 
caring more about our nightly users a lot more than some of our developers 
seem to be.  :(


If people just want to clean up IDL, which is what I'm seeing, they should 
start with the ton of noscript interfaces we have that need cleanup and which 
are known to not break any addons ever since we remove binary addon support.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Boris Zbarsky]

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 about this some more, and here's the problem as I see it. 
Extension authors may know the score (though see below), but nightly 
users may not, and even if they do they may not realize that addons are 
involved in breakage.


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 because we introduced a bug that they should report.


So I strongly feel that to avoid wasting the time and effort of our 
nightly users we should not start landing addon-breaking changes (or at 
least ones that might cause exceptions in addons that break various 
browser functionality) until after we have disabled addons.


Note that the issues addon authors are having are precisely the "we 
don't want to make nightly users' lives hell, so we're trying to make 
sure our addons keep working for the users who have them installed" 
issue.  As in, they're caring more about our nightly users a lot more 
than some of our developers seem to be.  :(


If people just want to clean up IDL, which is what I'm seeing, they 
should start with the ton of noscript interfaces we have that need 
cleanup and which are known to not break any addons ever since we remove 
binary addon support.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Kris Maglione]

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 flipping 
a pref.


Will that pref still be available in 57 once it reaches Release (and 
then for how much longer?), or will it be going away somewhere between 
now and then?


It will be nightly-only. In release builds, legacy extensions 
will be disabled by a compile-time constant.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Jonathan Kew]

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 it reaches Release (and 
then for how much longer?), or will it be going away somewhere between 
now and then?


(I'd been under the impression that legacy add-ons would be dead as of 
FF57, but if they can be re-enabled by flipping a pref, then that's not 
as clear-cut as I thought.)


Thanks,

JK
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Andrew Swan]

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 unnecessary suspense around this, there are a
few loose ends related to things like test pilot, shield, etc. that need to
be tied up before we flip the default on Nightly.  But that should happen
later this week.  The main tracker is bug 1336576 if you'd like to follow
along.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Kris Maglione]

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 already causing the addon
community a lot of churn.


I'd like to get some clarity on what's going on here, actually.

57 tip right now still allows old-style addons, right?  But people 
have started landing interface changes that break those addons quite 
badly; see https://bugzilla.mozilla.org/show_bug.cgi?id=1326520 for an 
example.


This is causing addon authors a bunch of pain as they struggle to keep 
their addons working on nightly (where they are theoretically still 
supported, per above) while also trying to port them to WebExtensions. 
I can't find a link to the bug comments complaining about this right 
now, but I recall it being connected to the nsIURI changes.


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.


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. There's 
no official support for legacy add-ons in 57. If they want to 
continue attempting to support them, they need to expect 
frequent breakage.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Boris Zbarsky]

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 get some clarity on what's going on here, actually.

57 tip right now still allows old-style addons, right?  But people have 
started landing interface changes that break those addons quite badly; 
see https://bugzilla.mozilla.org/show_bug.cgi?id=1326520 for an example.


This is causing addon authors a bunch of pain as they struggle to keep 
their addons working on nightly (where they are theoretically still 
supported, per above) while also trying to port them to WebExtensions. 
I can't find a link to the bug comments complaining about this right 
now, but I recall it being connected to the nsIURI changes.


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.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Restricting the Notifications API to secure contexts

[Eric Rescorla]

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/pull/6596
>
> Given that the API involves prompting the user as well as a permission
> that remains stored across different networks it seems like a good
> idea to restrict this API to HTTPS.
>
> I was wondering if anyone has concerns with restricting the API as
> such. If there are no concerns within a week I'll let Chrome go ahead
> with the change to the standard and tests and file the necessary
> implementation bugs against the remaining browsers, including Firefox.
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: webidl: partial interfaces and build-time configuration

[Boris Zbarsky]

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 (potentially optional) parts of
the interface over several files was exactly the usecase behind.


There is no implementation usecase for them.  We considered not 
supporting them at all, but decided the value of being able to 
copy/paste IDL snippets directly from specifications was worth doing a 
bit of work to add some support for the syntax.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: webidl: partial interfaces and build-time configuration

[Enrico Weigelt, metux IT consult]

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 this is not supported:


   TypeError: The binding build system doesn't really support partial
   interfaces which don't appear in the file in which the interface they
   are extending is defined.  Don't do this.

Of course using partial interfaces can make the #ifdef bits simpler in 
some cases.


hmm, then what are the partial interfaces actually for ?

I had the impression that distributing (potentially optional) parts of
the interface over several files was exactly the usecase behind.

--mtx
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Restricting the Notifications API to secure contexts

[Enrico Weigelt, metux IT consult]

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-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: webidl: partial interfaces and build-time configuration

[Boris Zbarsky]

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 #ifdef's in Navigator.webidl needed)


If you try to do this, you will get a message from binding codegen that 
explicitly says this is not supported:


  TypeError: The binding build system doesn't really support partial
  interfaces which don't appear in the file in which the interface they
  are extending is defined.  Don't do this.

Of course using partial interfaces can make the #ifdef bits simpler in 
some cases.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Restricting the Notifications API to secure contexts

[Anne van Kesteren]

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 stored across different networks it seems like a good
idea to restrict this API to HTTPS.

I was wondering if anyone has concerns with restricting the API as
such. If there are no concerns within a week I'll let Chrome go ahead
with the change to the standard and tests and file the necessary
implementation bugs against the remaining browsers, including Firefox.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: webidl: partial interfaces and build-time configuration

[Enrico Weigelt, metux IT consult]

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 you mean navigator.requestWakeLock()? That's deprecated and should be
removed altogether.


Okay, added it to my pipeline.
Are there more wakelock-related things to be removed ?

Anyway, my question is more genric: can we get rid of #ifdef's in
*.webidl files by partial interfaces in separate file ?
(also affects other things, eg. gamepad)


--mtx
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Ryan VanderMeulen]

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-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: July 31st to August 4th

[Cornel Ionce]

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/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1387079 
	[Linux] Noticeable performance issues when scrolling on some popular 
websites (twitter, linkedin, pinterest)

Core
Layout: View Rendering
	YES 
 
	NOBODY



*BETA CHANNEL
*none


*NIGHTLY CHANNEL*
none

*ESR CHANNEL*
none


Regards,
Cornel (:cornel_ionce)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: webidl: partial interfaces and build-time configuration

[Gabriele Svelto]

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's deprecated and should be
removed altogether. We already have bug 1369194 [1] for that, I haven't
had time to work on it yet so patches are welcome. You can needinfo me
for details about which parts of the implementation should also be removed.

 Gabriele

[1] Remove navigator.requestWakeLock()
https://bugzilla.mozilla.org/show_bug.cgi?id=1369194



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Nicholas Nethercote]

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 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 benefits of ASLR?
>>>
>> Not giving users a security mechanism due to a non-obvious reason
>> feels bad. Furthermore, considering that Microsoft documents 2 GB as a
>> "requirement" for 64-bit Windows, is it really worthwhile for us to
>> treat three Windows pointer size combinations (32-bit on 32-bit,
>> 64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
>> the combinations is in contradiction with the OS vendor's stated
>> requirements?
>>
>> Do we have any metrics on whether 32-bit on 64-bit exhibits bugs that
>> 32-bit on 32-bit and 64-bit on 64-bit don't? That is, what kind of bug
>> burden are we keeping by catering to users who've installed 64-bit
>> Windows with less than 2 GB of RAM in contradiction with what
>> Microsoft states as a requirement?
>>
>
> That's a fair question. 32-bit applications can only access 2 GB of
> virtual address space on Win32 OS, but can access 4 GB on Win64 OS. So in
> theory, some 32-bit pointer bugs could manifest differently on Win64 and
> Win32.
>
> Do we test 32-bit Firefox on Win32 or Win64 today? I know we build 32-bit
> Firefox on Win64. Since more people will run 32-bit Firefox on Win32 than
> on Win64, we should probably test on Win32 or at least test on Win64
> configured to only allow Firefox access to 2 GB of virtual address space.
>
> In our experiments with Win64 OS users, users with 2 GB or less had
> slightly worse retention and crash rates when running 64-bit Firefox than
> 32-bit Firefox.
>
> About 8% of Win64 users in our experiment had 2 GB or less, so we are
> talking about choosing a worse user experience for a fair number of people.
> (We didn't break out how many users had strictly less than 2 GB.) 64-bit
> Chrome's minimum memory requirement is 4 GB, so Google has similarly
> decided that supporting 32-bit on Win64 is worth the trouble.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

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 benefits of ASLR?

Not giving users a security mechanism due to a non-obvious reason
feels bad. Furthermore, considering that Microsoft documents 2 GB as a
"requirement" for 64-bit Windows, is it really worthwhile for us to
treat three Windows pointer size combinations (32-bit on 32-bit,
64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
the combinations is in contradiction with the OS vendor's stated
requirements?

Do we have any metrics on whether 32-bit on 64-bit exhibits bugs that
32-bit on 32-bit and 64-bit on 64-bit don't? That is, what kind of bug
burden are we keeping by catering to users who've installed 64-bit
Windows with less than 2 GB of RAM in contradiction with what
Microsoft states as a requirement?


That's a fair question. 32-bit applications can only access 2 GB of 
virtual address space on Win32 OS, but can access 4 GB on Win64 OS. So 
in theory, some 32-bit pointer bugs could manifest differently on Win64 
and Win32.


Do we test 32-bit Firefox on Win32 or Win64 today? I know we build 
32-bit Firefox on Win64. Since more people will run 32-bit Firefox on 
Win32 than on Win64, we should probably test on Win32 or at least test 
on Win64 configured to only allow Firefox access to 2 GB of virtual 
address space.


In our experiments with Win64 OS users, users with 2 GB or less had 
slightly worse retention and crash rates when running 64-bit Firefox 
than 32-bit Firefox.


About 8% of Win64 users in our experiment had 2 GB or less, so we are 
talking about choosing a worse user experience for a fair number of 
people. (We didn't break out how many users had strictly less than 2 
GB.) 64-bit Chrome's minimum memory requirement is 4 GB, so Google has 
similarly decided that supporting 32-bit on Win64 is worth the trouble.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Henri Sivonen]

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 benefits of ASLR?

Not giving users a security mechanism due to a non-obvious reason
feels bad. Furthermore, considering that Microsoft documents 2 GB as a
"requirement" for 64-bit Windows, is it really worthwhile for us to
treat three Windows pointer size combinations (32-bit on 32-bit,
64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
the combinations is in contradiction with the OS vendor's stated
requirements?

Do we have any metrics on whether 32-bit on 64-bit exhibits bugs that
32-bit on 32-bit and 64-bit on 64-bit don't? That is, what kind of bug
burden are we keeping by catering to users who've installed 64-bit
Windows with less than 2 GB of RAM in contradiction with what
Microsoft states as a requirement?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform