Firefox 55.* in Windows/Ubuntu - every day CPU 100%/Hangs Up. Please to do something!

[Alexey Zvyagin]

Dear developers of Firefox,

I have 55.* version of Firefox at work and at home
At work i have Windows 7 OS, at home the Ubuntu 16.04 LTE
I have my own synced profile. I don't have problem with syncing...

In both OSes i regulary and every day i see the situation when after few work 
time (may be even after 1-5 minutes) of Firefox i see the CPU 100% of Firefox 
and the Firefox hangs up after... Only one way i have for repairing of this: 
"killall -HUP firefox" command at Ubuntu and "End Task" in Windows.

In both cases i have turned on option about "report health" and about "reports 
to Mozilla". I know about the page "about:crashes" and regulary to see there. 
The main problem is there: this hangings up cases are not generated there. When 
i killed the Firefox and restarted its i didn't see fresh some reports in 
"about:crashes". I tried to tun on safe mode too. In safe mode the Firefox has 
same buggy behaviour - after some minutes it starts to eat 100% of CPU and no 
responding after... And again in "about:crashes" doesn't have there any fresh 
generated reports (about:crashes sometime has reports there which were created 
by other situation - may be by like "segmentation faults" errors).

I conclude that this "CPU bug" is not reported to you in many user cases! And i 
conclude that this is global problem (some OSes) not related with hardware and 
plugins.

I don't know how to report about this to you. I love your browser but your last 
version (55.0.2 & 55.0.3) are very very buggy. This is very annoying!

Best regards, Alexey
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving from xulrunner to firefox SDK

[Manish]

On Friday, 25 August 2017 20:58:06 UTC+5:30, Myk Melez  wrote:
> > Manish 
> > 2017 August 21 at 23:53
> > from where can I find the latest firefox SDK version for all the 
> > platforms eg: windows, linux and mac. Second can the directory 
> > structure remains the same as earlier like for xulrunner.
> There isn't a Firefox SDK, as Mozilla decided to stop supporting the 
> embedding use cases that were previously supported by XULRunner.
> 
> However, Firefox continues to ship a "private XULRunner" that other 
> applications can access via its --app command-line flag, which means 
> that you can run a XUL application on a system with Firefox via 
> /path/to/firefox --app /path/to/application.ini.
> 
> That also means that you could technically repurpose a Firefox 
> distribution to serve as your application's distribution by replacing 
> its application.ini and other application/branding files with your 
> application's files. The experimental qbrt project 
>  does this.
> 
> Note that these approaches aren't officially supported. However, the 
> --app flag has been present in Firefox for a long time, and I'm not 
> aware of any plans to remove it.
> 
> -myk

Thanks Myk

But I am bit confuse here. If we go by this way

/path/to/firefox --app /path/to/application.ini.

First there may be a possibility that Firefox is not installed and if it is 
installed and someone updates the firefox to latest version and the max ver. 
defined under application.ini is the older one, then the application won't 
start and will through the version mismatch alert.

Isn't there any method or terms defined where I can ship the firefox directory 
in the application folder rather than re-brading it or should we by default set 
the max version in application.ini to a higher value i.e 99 or if you can 
suggest any other way.

Also if we can ship firefox directory in the application folder "-app" thing 
will always work with the last firefox version supported.

Any help will be useful. 

Thanks in advance.

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

Re: Device Memory header and JS API

[Chris Peterson]

On 2017-09-06 11:48 AM, Tom Ritter wrote:

Steam's hardware survey shows the following distribution percentages.

Less than 512 MB 0.00%
512 Mb to 999 MB 0.03%
1 GB 0.52%
2 GB 3.30%
3 GB  6.27%
4 GB  14.96%
5 GB  0.66%
6 GB  3.23%
7 GB  2.33%
8 GB  42.77%
9 GB  0.04%
10 GB  0.29%
11 GB  0.18%
12 GB and higher  25.39%


The memory distribution of Firefox desktop users is shared on the 
Firefox Hardware Report dashboard. Unsurprisingly, Firefox users have 
less memory than Steam users.


https://hardware.metrics.mozilla.com/#goto-cpu-and-memory
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Andrew Overholt]

On Wed, Sep 6, 2017 at 2:53 PM, Daniel Veditz  wrote:

> I do not know what are plans are about Client Hints in general, whether we
> intend to or when, and obviously that's a prerequisite.
>

Client Hints is https://bugzilla.mozilla.org/show_bug.cgi?id=935216, FWIW.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Coding style: Placement of binary operators when breaking a long line

[Eric Rahm]

Hi folks-

*Note: Previously we've discussed the placement of logical operators && and
||; a decision was made and I do not wish to re-litigate that here*.

Currently we have a somewhat convoluted set of rules about where to place
boolean operators when breaking long lines [1]. Essentially we say that
logical operators such as `&&` stay at the end, but boolean opertators such
as `>` move to the new line. It's possible I'm misreading that (others
certainly have [2]).

This is incompatible with tools like clang-format [3] which support either
leaving the operator at the end of the line or moving it to the new line,
but not a half and half approach. It is very unlikely we could convince
them to upstream such a change given we are the only organization that has
requested it.

I would like to propose that we adjust our style guide to remove the
distinction between logical operators and boolean operators for the purpose
of line breaking and use a unified style.

*Examples*

Current rules:

if ((aArgument == 100) &&
(anotherReallyLongArgument
 > 2000)) {

Proposed change if we unify the rules, favoring the logical operator
placement:

if ((aArgument == 100) &&
(anotherReallyLongArgument >
 2000)) {

I want to emphasize this is a *pragmatic* change, our style guide is out of
the norm, and the ability of our developers being able to use tools like
clang-format is a big win.

Please let me know what you think.

-e

[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Operators
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1396515
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1338105#c16
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intermittent oranges and when to disable the related test case - a simplified policy

[jmaher]

Over the last 9 months a few of us have really watched intermittent test 
failures almost daily and done a lot to pester people as well as fix many.  
While there are over 420 bugs that have been fixed since the beginning of the 
year, there are half that many (211+) which have been disabled in some form 
(including turning off the jobs).

We don't like to disable and have been pretty relaxed in recommending disabling 
a test.  Overall we have tried to adhere to a policy of:
* >=30 failures/week- ask for owner to look at failure and fix it, if this 
persists for a few weeks with no real traction we would go ahead [and 
recommend] disabling it.
* >= 75 failures/week- ask for people to fix this in a shorter time frame and 
recommend disabling the test in a week or so
* >= 150 failures/week- often just disable the test

This is confusing and hard to manage.  Since then we have started adjusting 
triage queries and some teams are doing their own triage and we are ignoring 
those bugs (while they are getting prioritized properly). 

What we are looking to start doing this month is adopting a simpler policy:
* any bug that has >=200 instances in the last 30 days will be disabled
** this will be a manual process, so it will happen a couple times/week

We expect the outcome of this to be a similar amount of disabling, just an 
easier method for doing so.  It is very possible we might recommend disabling a 
test before it hits the threshold- keep in mind a disabled test is easy to 
re-enable (so feel free to disable for that one platform until you have time to 
look at fixing it)

To be clear we (and some component owners) will continue triaging bugs and 
trying to get fixes in place as often as possible and prefer a fix, not a 
disabled test!

Please raise any concerns, otherwise we will move forward with this in the 
coming weeks.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: Unified Bootstrap Stages for Gecko

[zbraniecki]

On Tuesday, September 5, 2017 at 8:18:40 AM UTC-7, Mike Conley wrote:
> We should also consider adding a milestone for the "hero element" for
> the browser. There's some discussion fragments in bug 1369417 about this
> (which I see you're already involved in! Great!), captured from a very
> caffeinated discussion with jmaher, florian and a few other folks in SF
> this past all-hands.

I think we can dissect it in several ways:

1) We can separate firstContentfulPaint (any DOM is painted) from 
firstMeaningfulPaint (the paint that contains the selected hero element(s)).

I would be happy to see it as a progression. Once again, this way we can 
instrument our own code *and* our tp6 suite by marking which elements are 
"meaningful" and mark the timestamp only when those were accounted for in a 
paint that was completed.

The difference between firstPaint and firstContentfulPaint is the time when the 
page was "blank" but something (from  or manifest, so title or 
background) indicated that the load is successful.

The difference between firstContentfulPaint and firstMeaningfulPaint would be 
the time when the document was being reflowed. I expect that in most cases, and 
definitely in case of browser.xul, those two (actually, those three) will stay 
the same.
But you can imagine that we could then, say, switch URL bar to be injected from 
JS, and since it's marked as meaningful, we'd mark the timestamp only when this 
element was accounted for in the paint.

2) There's a distinction between visible and interactive.

In theory, we could paint, say the url bar, but until its JS is ready and 
hooked, it's not interactive.

I was thinking about defining the "uiInteractive" mark to be set when the JS 
required for making the meaningful UI pieces is ready. That could be up to 
Firefox UI owners discretion - maybe URL bar and tabbar is enough, maybe we 
want to wait for something more.

> 
> At any rate, this all sounds strictly better than what ts_paint
> currently captures. We just need to ensure that we measure paint times
> when they're presented to the user (so after composite), and using the
> timestamps on the MozAfterPaint events themselves[1] (and not taking a
> timestamp at the event-servicing time, as this adds noise and padding to
> the timestamp).

Yeah. That seems the hardest part for me, since the required instrumentation 
goes far beyond my skills.
In bug 1388157 comment 5 [0] Markus described what has to happen for us to make 
us register full paints (including composition) timestamps involving given 
requirements.

> So, uh, thumbs up from me. :)

In comment 2 of the same bug, Markus pointed out that we'd need a product / 
metrics decision on it.

I'd be happy to formalize the proposal into a document and build a plan for 
implementing it (starting with a new firstPaint that will unify all 
firstpaints!). But I believe before I invest that time, I'd like to get 
consensus among platform, metrics, and graphics engineers to know that this 
proposal is something they'd be willing to work toward.

zb.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1388157
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Daniel Veditz]

On Tue, Sep 5, 2017 at 10:13 AM, Shubhie Panicker via dev-platform <
dev-platform@lists.mozilla.org> wrote:

> Boris expressed privacy concern with the API and suggested starting a
> thread here to get some concrete feedback.


​It's great that you agreed to send this (and other client hints?) only
for​ secure connections.

I share Boris's concern that the buckets are too fine-grained. Are those
fine distinctions likely to matter to content producers compared to the
additional fingerprintability?  Of course if we implemented client hints we
could simply send less information, like 0.5, 1, and 2. Maybe 4 if some
sites really would send resources large enough to where that is an issue.
And I guess Firefox for Android claims to be able to run on a 384Mb device
so maybe 0.25 is a useful value as well.

Sending the info to 3rd party resources increases tracking risk, though I
suppose if we didn't sites could still pass the info along through URL
parameters.

I do not know what are plans are about Client Hints in general, whether we
intend to or when, and obviously that's a prerequisite.

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

Re: Intermittent oranges and when to disable the related test case - a simplified policy

[Emma Humphries]

In order to be more consistent, marking a failing test as disabled should
be done with a keyword instead of a whiteboard tag.

Proposed keyword: test-disabled
Description: Used by test automation team to indicate the failing test
associated with this bug has a failure rate above a threshold level and has
been disabled. To check the consistency of this keyword, bugs with it
keyword should be filed by the intermittent-bug-filer user.

On Wed, Sep 6, 2017 at 2:10 PM,  wrote:

> Over the last 9 months a few of us have really watched intermittent test
> failures almost daily and done a lot to pester people as well as fix many.
> While there are over 420 bugs that have been fixed since the beginning of
> the year, there are half that many (211+) which have been disabled in some
> form (including turning off the jobs).
>
> We don't like to disable and have been pretty relaxed in recommending
> disabling a test.  Overall we have tried to adhere to a policy of:
> * >=30 failures/week- ask for owner to look at failure and fix it, if this
> persists for a few weeks with no real traction we would go ahead [and
> recommend] disabling it.
> * >= 75 failures/week- ask for people to fix this in a shorter time frame
> and recommend disabling the test in a week or so
> * >= 150 failures/week- often just disable the test
>
> This is confusing and hard to manage.  Since then we have started
> adjusting triage queries and some teams are doing their own triage and we
> are ignoring those bugs (while they are getting prioritized properly).
>
> What we are looking to start doing this month is adopting a simpler policy:
> * any bug that has >=200 instances in the last 30 days will be disabled
> ** this will be a manual process, so it will happen a couple times/week
>
> We expect the outcome of this to be a similar amount of disabling, just an
> easier method for doing so.  It is very possible we might recommend
> disabling a test before it hits the threshold- keep in mind a disabled test
> is easy to re-enable (so feel free to disable for that one platform until
> you have time to look at fixing it)
>
> To be clear we (and some component owners) will continue triaging bugs and
> trying to get fixes in place as often as possible and prefer a fix, not a
> disabled test!
>
> Please raise any concerns, otherwise we will move forward with this in the
> coming weeks.
> ___
> 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: Telemetry Histogram Expiry

[Ehsan Akhgari]

I don't think this probe is needed any more.  Filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1397371 to remove it.

On Wed, Sep 6, 2017 at 1:55 AM,  wrote:

> The following histograms will be expiring on 2017-09-20, and should be
> removed from the codebase, or have their expiry versions updated:
>
> * DOCUMENT_WITH_EXPANDED_PRINCIPAL expires in version 58.0a1 (watched by
> dev-platform@lists.mozilla.org) - Number of documents encountered using
> an expanded principal.
>
> This is an automated message sent by Cerberus. See
> https://github.com/mozilla/cerberus for details and source code.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



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

Re: Intent to implement: RTCRtpTransceiver

[Tom Ritter]

IIRC, the rework won't be able to be switched 'back-to-existing' with
a pref, but we'll continue to respect existing disable-webrtc prefs
and the --disable-webrtc compiler switch, right?

-tom

On Wed, Sep 6, 2017 at 11:41 AM, Byron Campen  wrote:
> What: RTCRtpTransceiver is a central part of the w3c webrtc API
> (https://www.w3.org/TR/webrtc/) and JSEP spec
> (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep). This is a significant
> addition to the webrtc API, and entails a rework of the internals (it is not
> practical to hide this rework code behind a pref). This work will apply to
> all platforms and in all situations where RTCPeerConnection is supported
> now.
>
> Why: This has been in the relevant specifications for a year and a half,
> is considered "done" from a spec perspective, but still hasn't been
> implemented. Given that this spec involves browser-to-browser interop, it is
> vital that there be some running code out there.
>
> Where: https://bugzilla.mozilla.org/show_bug.cgi?id=1290948
>
> When: My intent is to land this early in the 58 release cycle.
>
>
> Our existing test suite will do a good job of covering the internal
> rework, and I have written some additional test-cases to cover the new API.
> web-platform-tests has some coverage of the new API also (in
> https://github.com/w3c/web-platform-tests/blob/master/webrtc/RTCPeerConnection-addTransceiver.html
> and
> https://github.com/w3c/web-platform-tests/blob/master/webrtc/RTCPeerConnection-getTransceivers.html).
>
> Best regards,
> Byron Campen
> ___
> 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: Device Memory header and JS API

[Tom Ritter]

This is pretty concerning to me from a fingerprinting POV. The spec
currently rounds up to one of the following values:

0.25, 0.5, 0.75, 1, 1.5, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128

Steam's hardware survey shows the following distribution percentages.

Less than 512 MB 0.00%
512 Mb to 999 MB 0.03%
1 GB 0.52%
2 GB 3.30%
3 GB  6.27%
4 GB  14.96%
5 GB  0.66%
6 GB  3.23%
7 GB  2.33%
8 GB  42.77%
9 GB  0.04%
10 GB  0.29%
11 GB  0.18%
12 GB and higher  25.39%

The low end is extremely small buckets, and the high end isn't even
fleshed out but I'm certain that's becomes small buckets too >16GB
too. (Obviously this doesn't take into account mobile, and I couldn't
find any reports on distribution of android devices by RAM.)

I'm not thrilled about including this at all, but if we did I would
strongly recommend significantly reducing the number of buckets
reported. Ideally to 2.

I haven't seen anything in this that indicates people want to use such
nuanced data; they just want to know whether to serve the 'light' or
the 'normal' mode. This is reminiscent of NetworkInformaiton API where
it was designed to expose a ton of information but really people just
wanted to know "Will this cost the user money or not".

Is there any reason it can't just report that: 'Low Memory' or 'Not Low Memory'.

-tom

On Tue, Sep 5, 2017 at 12:13 PM, Shubhie Panicker via dev-platform
 wrote:
> Hi,
> I work on Chrome Web Platform and we just shipped an API for detecting
> Device Memory:
> header
> 
> and JS API
> 
> .
> Boris expressed privacy concern with the API and suggested starting a
> thread here to get some concrete feedback. We would love to get this
> feedback and are open to updating the header and API as it would be great
> to get FF behind this API.
> (It's not too late to update this, larger adoption is gated on
> Accept-CH-Lifetime
> header
> 
> which would enable sending the CH header on the first request)
>
> Sincerely,
> Shubhie
>
> PS: As an aside, we discussed the API in the Web Perf WG but unfortunately
> Mozilla is not currently participating in the WG and we'd love to address
> that going forward.
> ___
> 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

Kris Maglione and Andrew McCreight are now XPConnect Peers

[Bobby Holley]

XPConnect is not exactly a fun module. When I took the reins from mrbkap
4.5 years ago, Peter wiped a tear from his eye and said "Congratulations,
Blake."

Still, it's at the heart of Gecko, and needs ongoing attention from deep
hackers. With the old hands busy with other things recently, Kris and
Andrew have stepped up and done a lot of the heavy lifting, especially
around Quantum Flow.

Andrew became a peer in May, and Kris become a peer a few minutes ago.
Please be sure to congratulate me and offer your condolences to Kris and
Andrew. ;-)

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

Re: Intermittent oranges and when to disable the related test case - a simplified policy

[Emma Humphries]

Andrew Swan noticed that whiteboard tag was showing up on bugs not filed by
the intermittent-test-failure bot (thanks!)

Here's the queries restricted to just bot filed bugs:

https://mzl.la/2eMnMRz (add ons)
https://mzl.la/2eMaPqQ (all core/ffx/toolkit)

This begs the question, why was that whiteboard tag being used that way?


On Wed, Sep 6, 2017 at 4:32 PM, Emma Humphries  wrote:

> Andy
>
> To start:
>
> https://bugzilla.mozilla.org/buglist.cgi?product=Core;
> product=Firefox=Firefox%20for%20Android&
> product=Firefox%20for%20iOS=Toolkit_format=
> advanced=---_whiteboard=test%20disabled%2Ctest-disabled%
> 2Ctestdisabled_whiteboard_type=anywordssubstr=bug_id=0
>
> Add-ons, Web Extensions, and Plugins related:
>
> https://bugzilla.mozilla.org/buglist.cgi?resolution=---;
> status_whiteboard_type=anywordssubstr_format=
> advanced_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled&
> component=Add-on%20Manager=Add-ons%20Manager&
> component=Plug-ins=WebExtensions%3A%20Android&
> component=WebExtensions%3A%20Compatibility=
> WebExtensions%3A%20Developer%20Tools=WebExtensions%3A%
> 20Experiments=WebExtensions%3A%20Frontend&
> component=WebExtensions%3A%20General=WebExtensions%3A%20Request%
> 20Handling=WebExtensions%3A%20Untriaged&
> product=Core=Firefox=Firefox%20for%
> 20Android=Firefox%20for%20iOS=Toolkit
>
> On Wed, Sep 6, 2017 at 3:46 PM, Andrew McKay  wrote:
>
>> Is there an easy way for me to track what tests have been disabled as
>> result of intermittent issues we haven't been able to fix?
>>
>> On 6 September 2017 at 14:10,   wrote:
>> > Over the last 9 months a few of us have really watched intermittent
>> test failures almost daily and done a lot to pester people as well as fix
>> many.  While there are over 420 bugs that have been fixed since the
>> beginning of the year, there are half that many (211+) which have been
>> disabled in some form (including turning off the jobs).
>> >
>> > We don't like to disable and have been pretty relaxed in recommending
>> disabling a test.  Overall we have tried to adhere to a policy of:
>> > * >=30 failures/week- ask for owner to look at failure and fix it, if
>> this persists for a few weeks with no real traction we would go ahead [and
>> recommend] disabling it.
>> > * >= 75 failures/week- ask for people to fix this in a shorter time
>> frame and recommend disabling the test in a week or so
>> > * >= 150 failures/week- often just disable the test
>> >
>> > This is confusing and hard to manage.  Since then we have started
>> adjusting triage queries and some teams are doing their own triage and we
>> are ignoring those bugs (while they are getting prioritized properly).
>> >
>> > What we are looking to start doing this month is adopting a simpler
>> policy:
>> > * any bug that has >=200 instances in the last 30 days will be disabled
>> > ** this will be a manual process, so it will happen a couple times/week
>> >
>> > We expect the outcome of this to be a similar amount of disabling, just
>> an easier method for doing so.  It is very possible we might recommend
>> disabling a test before it hits the threshold- keep in mind a disabled test
>> is easy to re-enable (so feel free to disable for that one platform until
>> you have time to look at fixing it)
>> >
>> > To be clear we (and some component owners) will continue triaging bugs
>> and trying to get fixes in place as often as possible and prefer a fix, not
>> a disabled test!
>> >
>> > Please raise any concerns, otherwise we will move forward with this in
>> the coming weeks.
>> > ___
>> > 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: Coding style: Placement of binary operators when breaking a long line

[Mike Hommey]

On Wed, Sep 06, 2017 at 12:30:58PM -0700, Eric Rahm wrote:
> Hi folks-
> 
> *Note: Previously we've discussed the placement of logical operators && and
> ||; a decision was made and I do not wish to re-litigate that here*.
> 
> Currently we have a somewhat convoluted set of rules about where to place
> boolean operators when breaking long lines [1]. Essentially we say that
> logical operators such as `&&` stay at the end, but boolean opertators such
> as `>` move to the new line. It's possible I'm misreading that (others
> certainly have [2]).
> 
> This is incompatible with tools like clang-format [3] which support either
> leaving the operator at the end of the line or moving it to the new line,
> but not a half and half approach. It is very unlikely we could convince
> them to upstream such a change given we are the only organization that has
> requested it.
> 
> I would like to propose that we adjust our style guide to remove the
> distinction between logical operators and boolean operators for the purpose
> of line breaking and use a unified style.
> 
> *Examples*
> 
> Current rules:
> 
> if ((aArgument == 100) &&
> (anotherReallyLongArgument
>  > 2000)) {
> 
> Proposed change if we unify the rules, favoring the logical operator
> placement:
> 
> if ((aArgument == 100) &&
> (anotherReallyLongArgument >
>  2000)) {

On a personal note, I find > 2000 as in the first sample more readable
than the latter. So much so that I'd actually prefer the logical
operators to be on the next line than boolean operator being on the
previous.

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

Re: Intermittent oranges and when to disable the related test case - a simplified policy

[Daniel Veditz]

On Wed, Sep 6, 2017 at 4:53 PM, Emma Humphries  wrote:

> This begs the question, why was that whiteboard tag being used that way?
>

​Surely there are other reasons to disable tests, and people might want to
track those too. If you want to restrict your new keyword to just "disabled
because intermittent" you should put intermittent in the keyword name​
(e.g. intermittent-test-disabled). Personally I'd go ahead and accept that
other people want to flag disabled tests; it's simple enough to query on
both test-disabled and intermittent-failure to get just that subset.

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

Re: Coding style: Placement of binary operators when breaking a long line

[Eric Rahm]

As I said, I was hoping to avoid rehashing this point, but the general
consensus from the last rather contentious post [1] was that changing from
the prevalent style of the codebase for primarily aesthetic reasons was
hard to justify (points about readability were made on both sides). Nick
pointed out that our code base very clearly tilts to the operators on the
end of the line style [2].

Carrying forward this wisdom for this case makes sense, but I'll admit
moving everything to the newline is certainly an option that would provide
a unified style which is my greater concern. I don't think we could
reasonably make that change until some sort of flag day when we convert
everything as the new style would clash with the prevalent style. I also
don't want to start a discussion about that again :)

-e

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/LD_KCtmmH74/dLckkuFjBwAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.platform/LD_KCtmmH74/ErPunKZ_BwAJ

On Wed, Sep 6, 2017 at 5:18 PM, Mike Hommey  wrote:

> On Wed, Sep 06, 2017 at 12:30:58PM -0700, Eric Rahm wrote:
> > Hi folks-
> >
> > *Note: Previously we've discussed the placement of logical operators &&
> and
> > ||; a decision was made and I do not wish to re-litigate that here*.
> >
> > Currently we have a somewhat convoluted set of rules about where to place
> > boolean operators when breaking long lines [1]. Essentially we say that
> > logical operators such as `&&` stay at the end, but boolean opertators
> such
> > as `>` move to the new line. It's possible I'm misreading that (others
> > certainly have [2]).
> >
> > This is incompatible with tools like clang-format [3] which support
> either
> > leaving the operator at the end of the line or moving it to the new line,
> > but not a half and half approach. It is very unlikely we could convince
> > them to upstream such a change given we are the only organization that
> has
> > requested it.
> >
> > I would like to propose that we adjust our style guide to remove the
> > distinction between logical operators and boolean operators for the
> purpose
> > of line breaking and use a unified style.
> >
> > *Examples*
> >
> > Current rules:
> >
> > if ((aArgument == 100) &&
> > (anotherReallyLongArgument
> >  > 2000)) {
> >
> > Proposed change if we unify the rules, favoring the logical operator
> > placement:
> >
> > if ((aArgument == 100) &&
> > (anotherReallyLongArgument >
> >  2000)) {
>
> On a personal note, I find > 2000 as in the first sample more readable
> than the latter. So much so that I'd actually prefer the logical
> operators to be on the next line than boolean operator being on the
> previous.
>
> Mike
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Kris Maglione and Andrew McCreight are now XPConnect Peers

[Boris Zbarsky]

On 9/6/17 7:47 PM, Bobby Holley wrote:

Andrew became a peer in May, and Kris become a peer a few minutes ago.


Excellent.  Congrats to them both!

And I do mean congrats, not condolences.  ;)

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

Re: Device Memory header and JS API

[Martin Thomson]

Why do the numbers need to be standardized?  Could we give browsers
the ability to change the value in response to their understanding of
the current situation.

Surely an Android device is easily identifiable as such, so we could
choose values that reflect our Android population at the current
moment and we could choose numbers so that no bucket is too small.  We
could say that the number is decimal, that it needs to be at least the
identified value, and have a  wrote:
> On 2017-09-06 11:48 AM, Tom Ritter wrote:
>>
>> Steam's hardware survey shows the following distribution percentages.
>>
>> Less than 512 MB 0.00%
>> 512 Mb to 999 MB 0.03%
>> 1 GB 0.52%
>> 2 GB 3.30%
>> 3 GB  6.27%
>> 4 GB  14.96%
>> 5 GB  0.66%
>> 6 GB  3.23%
>> 7 GB  2.33%
>> 8 GB  42.77%
>> 9 GB  0.04%
>> 10 GB  0.29%
>> 11 GB  0.18%
>> 12 GB and higher  25.39%
>
>
> The memory distribution of Firefox desktop users is shared on the Firefox
> Hardware Report dashboard. Unsurprisingly, Firefox users have less memory
> than Steam users.
>
> https://hardware.metrics.mozilla.com/#goto-cpu-and-memory
>
> ___
> 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: Intent to ship version 4 of the Safe Browsing protocol

[Eric Shepherd (Sheppy)]

On August 18, 2017 at 2:57:13 AM, Mike Hommey (m...@glandium.org) wrote:

On Wed, Aug 16, 2017 at 12:43:19PM -0700, Daniel Veditz wrote:
> 100 options is 4950 configurations to test.

I think you mean 2^100. That's 1.26 x 10^30.

Also known as “a boatload.”



Eric Shepherd
Senior Technical Writer, MDN
MDN: https://developer.mozilla.org/
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intermittent oranges and when to disable the related test case - a simplified policy

[Emma Humphries]

Andy

To start:

https://bugzilla.mozilla.org/buglist.cgi?product=Core=Firefox=Firefox%20for%20Android=Firefox%20for%20iOS=Toolkit_format=advanced=---_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled_whiteboard_type=anywordssubstr=bug_id=0

Add-ons, Web Extensions, and Plugins related:

https://bugzilla.mozilla.org/buglist.cgi?resolution=---_whiteboard_type=anywordssubstr_format=advanced_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled=Add-on%20Manager=Add-ons%20Manager=Plug-ins=WebExtensions%3A%20Android=WebExtensions%3A%20Compatibility=WebExtensions%3A%20Developer%20Tools=WebExtensions%3A%20Experiments=WebExtensions%3A%20Frontend=WebExtensions%3A%20General=WebExtensions%3A%20Request%20Handling=WebExtensions%3A%20Untriaged=Core=Firefox=Firefox%20for%20Android=Firefox%20for%20iOS=Toolkit

On Wed, Sep 6, 2017 at 3:46 PM, Andrew McKay  wrote:

> Is there an easy way for me to track what tests have been disabled as
> result of intermittent issues we haven't been able to fix?
>
> On 6 September 2017 at 14:10,   wrote:
> > Over the last 9 months a few of us have really watched intermittent test
> failures almost daily and done a lot to pester people as well as fix many.
> While there are over 420 bugs that have been fixed since the beginning of
> the year, there are half that many (211+) which have been disabled in some
> form (including turning off the jobs).
> >
> > We don't like to disable and have been pretty relaxed in recommending
> disabling a test.  Overall we have tried to adhere to a policy of:
> > * >=30 failures/week- ask for owner to look at failure and fix it, if
> this persists for a few weeks with no real traction we would go ahead [and
> recommend] disabling it.
> > * >= 75 failures/week- ask for people to fix this in a shorter time
> frame and recommend disabling the test in a week or so
> > * >= 150 failures/week- often just disable the test
> >
> > This is confusing and hard to manage.  Since then we have started
> adjusting triage queries and some teams are doing their own triage and we
> are ignoring those bugs (while they are getting prioritized properly).
> >
> > What we are looking to start doing this month is adopting a simpler
> policy:
> > * any bug that has >=200 instances in the last 30 days will be disabled
> > ** this will be a manual process, so it will happen a couple times/week
> >
> > We expect the outcome of this to be a similar amount of disabling, just
> an easier method for doing so.  It is very possible we might recommend
> disabling a test before it hits the threshold- keep in mind a disabled test
> is easy to re-enable (so feel free to disable for that one platform until
> you have time to look at fixing it)
> >
> > To be clear we (and some component owners) will continue triaging bugs
> and trying to get fixes in place as often as possible and prefer a fix, not
> a disabled test!
> >
> > Please raise any concerns, otherwise we will move forward with this in
> the coming weeks.
> > ___
> > 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: Intermittent oranges and when to disable the related test case - a simplified policy

[Andrew McKay]

Is there an easy way for me to track what tests have been disabled as
result of intermittent issues we haven't been able to fix?

On 6 September 2017 at 14:10,   wrote:
> Over the last 9 months a few of us have really watched intermittent test 
> failures almost daily and done a lot to pester people as well as fix many.  
> While there are over 420 bugs that have been fixed since the beginning of the 
> year, there are half that many (211+) which have been disabled in some form 
> (including turning off the jobs).
>
> We don't like to disable and have been pretty relaxed in recommending 
> disabling a test.  Overall we have tried to adhere to a policy of:
> * >=30 failures/week- ask for owner to look at failure and fix it, if this 
> persists for a few weeks with no real traction we would go ahead [and 
> recommend] disabling it.
> * >= 75 failures/week- ask for people to fix this in a shorter time frame and 
> recommend disabling the test in a week or so
> * >= 150 failures/week- often just disable the test
>
> This is confusing and hard to manage.  Since then we have started adjusting 
> triage queries and some teams are doing their own triage and we are ignoring 
> those bugs (while they are getting prioritized properly).
>
> What we are looking to start doing this month is adopting a simpler policy:
> * any bug that has >=200 instances in the last 30 days will be disabled
> ** this will be a manual process, so it will happen a couple times/week
>
> We expect the outcome of this to be a similar amount of disabling, just an 
> easier method for doing so.  It is very possible we might recommend disabling 
> a test before it hits the threshold- keep in mind a disabled test is easy to 
> re-enable (so feel free to disable for that one platform until you have time 
> to look at fixing it)
>
> To be clear we (and some component owners) will continue triaging bugs and 
> trying to get fixes in place as often as possible and prefer a fix, not a 
> disabled test!
>
> Please raise any concerns, otherwise we will move forward with this in the 
> coming weeks.
> ___
> 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: Intermittent oranges and when to disable the related test case - a simplified policy

[Andrew McKay]

Cool, thanks.

On 6 September 2017 at 16:32, Emma Humphries  wrote:
> Andy
>
> To start:
>
> https://bugzilla.mozilla.org/buglist.cgi?product=Core=Firefox=Firefox%20for%20Android=Firefox%20for%20iOS=Toolkit_format=advanced=---_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled_whiteboard_type=anywordssubstr=bug_id=0
>
> Add-ons, Web Extensions, and Plugins related:
>
> https://bugzilla.mozilla.org/buglist.cgi?resolution=---_whiteboard_type=anywordssubstr_format=advanced_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled=Add-on%20Manager=Add-ons%20Manager=Plug-ins=WebExtensions%3A%20Android=WebExtensions%3A%20Compatibility=WebExtensions%3A%20Developer%20Tools=WebExtensions%3A%20Experiments=WebExtensions%3A%20Frontend=WebExtensions%3A%20General=WebExtensions%3A%20Request%20Handling=WebExtensions%3A%20Untriaged=Core=Firefox=Firefox%20for%20Android=Firefox%20for%20iOS=Toolkit
>
> On Wed, Sep 6, 2017 at 3:46 PM, Andrew McKay  wrote:
>>
>> Is there an easy way for me to track what tests have been disabled as
>> result of intermittent issues we haven't been able to fix?
>>
>> On 6 September 2017 at 14:10,   wrote:
>> > Over the last 9 months a few of us have really watched intermittent test
>> > failures almost daily and done a lot to pester people as well as fix many.
>> > While there are over 420 bugs that have been fixed since the beginning of
>> > the year, there are half that many (211+) which have been disabled in some
>> > form (including turning off the jobs).
>> >
>> > We don't like to disable and have been pretty relaxed in recommending
>> > disabling a test.  Overall we have tried to adhere to a policy of:
>> > * >=30 failures/week- ask for owner to look at failure and fix it, if
>> > this persists for a few weeks with no real traction we would go ahead [and
>> > recommend] disabling it.
>> > * >= 75 failures/week- ask for people to fix this in a shorter time
>> > frame and recommend disabling the test in a week or so
>> > * >= 150 failures/week- often just disable the test
>> >
>> > This is confusing and hard to manage.  Since then we have started
>> > adjusting triage queries and some teams are doing their own triage and we
>> > are ignoring those bugs (while they are getting prioritized properly).
>> >
>> > What we are looking to start doing this month is adopting a simpler
>> > policy:
>> > * any bug that has >=200 instances in the last 30 days will be disabled
>> > ** this will be a manual process, so it will happen a couple times/week
>> >
>> > We expect the outcome of this to be a similar amount of disabling, just
>> > an easier method for doing so.  It is very possible we might recommend
>> > disabling a test before it hits the threshold- keep in mind a disabled test
>> > is easy to re-enable (so feel free to disable for that one platform until
>> > you have time to look at fixing it)
>> >
>> > To be clear we (and some component owners) will continue triaging bugs
>> > and trying to get fixes in place as often as possible and prefer a fix, not
>> > a disabled test!
>> >
>> > Please raise any concerns, otherwise we will move forward with this in
>> > the coming weeks.
>> > ___
>> > 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: Coding style: Placement of binary operators when breaking a long line

[Ehsan Akhgari]

On 09/06/2017 09:03 PM, Eric Rahm wrote:
As I said, I was hoping to avoid rehashing this point, but the general 
consensus from the last rather contentious post [1] was that changing 
from the prevalent style of the codebase for primarily aesthetic 
reasons was hard to justify (points about readability were made on 
both sides). Nick pointed out that our code base very clearly tilts to 
the operators on the end of the line style [2].


This has already been discussed to a great length as you note Eric, and 
like you I don't think rehashing the previous discussions is 
particularly helpful.


Also, while I understand that people will certainly have (sometimes 
strongly held) personal preferences, the Mozilla Coding Style isn't a 
place where everyone's personal preferences can win, for the obvious 
reason that these personal preferences are often mutually exclusive.


The interesting points to consider is the data that Nick alluded to in 
the previous discussion about the existing prevalent style.


Also, the point you up about the pragmatic aspect of the need to be able 
to use automated tools in order to manage our Coding Style is right on.  
As things stand, the only viable option of such a tool that I'm aware of 
is clang-format, and given the standing situation with regards to what 
formatting options we can make that tool support in this case, I think 
the pragmatic decision is to pick *one* option here for the placement of 
operators across line breaks: either at the end of long lines or in the 
beginning of the next line.


The combination of the above points makes me prefer adopting the 
proposal to treat all operators like && and ||.


Carrying forward this wisdom for this case makes sense, but I'll admit 
moving everything to the newline is certainly an option that would 
provide a unified style which is my greater concern. I don't think we 
could reasonably make that change until some sort of flag day when we 
convert everything as the new style would clash with the prevalent 
style. I also don't want to start a discussion about that again :)


Yes, I think once we get to a point where we format our code using 
clang-format it would be much easier to argue for changes to the Coding 
Style like this, but a discussion about that right now seems premature.



-e

[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/LD_KCtmmH74/dLckkuFjBwAJ
[2] 
https://groups.google.com/d/msg/mozilla.dev.platform/LD_KCtmmH74/ErPunKZ_BwAJ


On Wed, Sep 6, 2017 at 5:18 PM, Mike Hommey > wrote:


On Wed, Sep 06, 2017 at 12:30:58PM -0700, Eric Rahm wrote:
> Hi folks-
>
> *Note: Previously we've discussed the placement of logical
operators && and
> ||; a decision was made and I do not wish to re-litigate that here*.
>
> Currently we have a somewhat convoluted set of rules about where
to place
> boolean operators when breaking long lines [1]. Essentially we
say that
> logical operators such as `&&` stay at the end, but boolean
opertators such
> as `>` move to the new line. It's possible I'm misreading that
(others
> certainly have [2]).
>
> This is incompatible with tools like clang-format [3] which
support either
> leaving the operator at the end of the line or moving it to the
new line,
> but not a half and half approach. It is very unlikely we could
convince
> them to upstream such a change given we are the only
organization that has
> requested it.
>
> I would like to propose that we adjust our style guide to remove the
> distinction between logical operators and boolean operators for
the purpose
> of line breaking and use a unified style.
>
> *Examples*
>
> Current rules:
>
> if ((aArgument == 100) &&
> (anotherReallyLongArgument
>  > 2000)) {
>
> Proposed change if we unify the rules, favoring the logical operator
> placement:
>
> if ((aArgument == 100) &&
> (anotherReallyLongArgument >
>  2000)) {

On a personal note, I find > 2000 as in the first sample more readable
than the latter. So much so that I'd actually prefer the logical
operators to be on the next line than boolean operator being on the
previous.

Mike




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

Re: Kris Maglione and Andrew McCreight are now XPConnect Peers

[Ehsan Akhgari]

On 09/06/2017 07:47 PM, Bobby Holley wrote:

XPConnect is not exactly a fun module. When I took the reins from mrbkap
4.5 years ago, Peter wiped a tear from his eye and said "Congratulations,
Blake."

Still, it's at the heart of Gecko, and needs ongoing attention from deep
hackers. With the old hands busy with other things recently, Kris and
Andrew have stepped up and done a lot of the heavy lifting, especially
around Quantum Flow.

Andrew became a peer in May, and Kris become a peer a few minutes ago.
Please be sure to congratulate me and offer your condolences to Kris and
Andrew. ;-)
Great additions to the peers list for this module, congrats to all three 
of you.  Great to see more bandwidth for this module.

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

Re: Intent to ship: Abort API

[Andrea Marchesini]

I spoke with Ben yesterday and today and we decided that bug 1394102 should
not block the shipping of this feature. That bug will be fixed as part of
the Service Worker refactoring.
Abort API and the Fetch() integration should be enabled by default in the
next nightly.

On Tue, Aug 29, 2017 at 4:25 PM, Ben Kelly  wrote:

> On Tue, Aug 29, 2017 at 9:39 AM, Ben Kelly  wrote:
>
>> On Tue, Aug 29, 2017 at 2:05 AM, Andrea Marchesini <
>> amarches...@mozilla.com> wrote:
>>
>>> Abort API is already part of the DOM spec and I would like to enable it
>>> by
>>> default everywhere in our codebase (dom.abortController.enabled). Abort +
>>> Fetch integration is not part of the spec yet. There is a read-ish
>>> pull-request, but as soon as it is merged, I would like to enable the
>>> second pref as well (dom.abortController.fetch.enabled).
>>>
>>
>> I don't understand why we would potentially ship these separately.
>> AFAICT the abort API is only really useful if its integrated into something
>> like fetch().  Currently the Fetch API is the only part of the platform
>> that uses it.
>>
>> Also, we have seen people do thing like feature detect for ReadableStream
>> and assume Response.body can be a ReadableStream.  This is why we are not
>> shipping the js ReadableStream until the fetch body stream can ship as
>> well.  I worry that people would do a similar kind of feature detection
>> with Abort API.
>>
>> Also, while the fetch+abort spec change has not landed yet, we pretty
>> much have consensus.  There are WPT tests in the tree already.  I don't
>> think this is what is blocking shipping the fetch+abort code.  To me its a
>> bigger issue that we still don't pass many of those WPT tests.  If we
>> passed the tests then I think we could reasonably ship it given the current
>> level of consensus on the spec.
>>
>
> I spoke with Andrea and Jake (the spec author on this feature) a bit this
> morning.  Our current test failures are all reasonable for different
> reasons:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1394085#c4
>
> So I would just like to see bug 1394102 land before we let abortable fetch
> ride the trains.
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox 55.* in Windows/Ubuntu - every day CPU 100%/Hangs Up. Please to do something!

[Panos Astithas]

Hi,

if you could file a bug, we can try to figure this out:

https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox=Untriaged

Please attach the contents of about:support as an attachment, so we can get
some idea of your configuration.

Thanks,
Panos


On Wed, Sep 6, 2017 at 10:45 AM, Alexey Zvyagin 
wrote:

> Dear developers of Firefox,
>
> I have 55.* version of Firefox at work and at home
> At work i have Windows 7 OS, at home the Ubuntu 16.04 LTE
> I have my own synced profile. I don't have problem with syncing...
>
> In both OSes i regulary and every day i see the situation when after few
> work time (may be even after 1-5 minutes) of Firefox i see the CPU 100% of
> Firefox and the Firefox hangs up after... Only one way i have for repairing
> of this: "killall -HUP firefox" command at Ubuntu and "End Task" in Windows.
>
> In both cases i have turned on option about "report health" and about
> "reports to Mozilla". I know about the page "about:crashes" and regulary to
> see there. The main problem is there: this hangings up cases are not
> generated there. When i killed the Firefox and restarted its i didn't see
> fresh some reports in "about:crashes". I tried to tun on safe mode too. In
> safe mode the Firefox has same buggy behaviour - after some minutes it
> starts to eat 100% of CPU and no responding after... And again in
> "about:crashes" doesn't have there any fresh generated reports
> (about:crashes sometime has reports there which were created by other
> situation - may be by like "segmentation faults" errors).
>
> I conclude that this "CPU bug" is not reported to you in many user cases!
> And i conclude that this is global problem (some OSes) not related with
> hardware and plugins.
>
> I don't know how to report about this to you. I love your browser but your
> last version (55.0.2 & 55.0.3) are very very buggy. This is very annoying!
>
> Best regards, Alexey
> ___
> 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: Intent to ship: Abort API

[Ben Kelly]

On Wed, Sep 6, 2017 at 12:27 PM, Andrea Marchesini 
wrote:

> Abort API and the Fetch() integration should be enabled by default in the
> next nightly.
>

To clarify, its already enabled in nightly, but the patch to let it ride
the trains is now in inbound.

Thanks for implementing this Andrea!

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

Device Memory header and JS API

[Shubhie Panicker via dev-platform]

Hi,
I work on Chrome Web Platform and we just shipped an API for detecting
Device Memory:
header

and JS API

.
Boris expressed privacy concern with the API and suggested starting a
thread here to get some concrete feedback. We would love to get this
feedback and are open to updating the header and API as it would be great
to get FF behind this API.
(It's not too late to update this, larger adoption is gated on
Accept-CH-Lifetime
header

which would enable sending the CH header on the first request)

Sincerely,
Shubhie

PS: As an aside, we discussed the API in the Web Perf WG but unfortunately
Mozilla is not currently participating in the WG and we'd love to address
that going forward.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[no subject]

[Emma Humphries]

It's the weekly report on the state of triage in Firefox-related components.

Marking Bugs for the Firefox 57 Release

The bug that will overshadow all the hard work we put into the Firefox 57
release has probably already been filed. We need to find it and fix it. If
you think a bug might affect users in the 57 release, please set the
correct Firefox versions affected in the bug, and then set the
tracking-request flag to request tracking of bug by release management team
.


Poll Result

It’s not a large sample, but by an 8-1-1 margin, you said you’d like a
logged-in BMO home page like: https://fitzgen.github.io/bugzilla-todos/.

Now, the catch. We don’t have staff to work on this, but I’ve filed a bug,
https://bugzilla.mozilla.org/show_bug.cgi?id=1397063 to do this work. If
you’d like undying gratitude, and some WONTFIX swag, grab this bug.

Hotspots

The components with the most untriaged bugs remain the JavaScript Engine
and Build Config.

Rank

Component

Last Week

This Week

1

Core: JavaScript Engine

477

472

2

Core: Build Config

459

455

3

Firefox for Android: General

408

415

4

Firefox: General

254

258

5

Core: General

241

235

6

Core: JavaScript: GC

180

175

7

Core: XPCOM

171

172

8

Core: Networking

159

167

All Components

8,822

8,962

Please make sure you’ve made it clear what, if anything will happen with
these bugs.

Not sure how to triage? Read
https://wiki.mozilla.org/Bugmasters/Process/Triage.


We know the JS numbers are artificially-high, and working on a solution for
cleaning that up.

Next Release


Version

56

56

57

57

57

57

Date

7/31

8/7

8/14

8/21

8/21

9/5

Untriaged this Cycle

4,479

479

835

1,196

1,481

1,785

Unassigned Untriaged this Cycle

3,674

356

634

968

1,266

1,477

Affected this Release

139

125

123

119

42

83

Enhancements

103

3

5

11

17

15

Orphaned P1s

192

196

191

183

18

23

Stalled P1s

179

157

152

155

13

23

What should we do with these bugs? Bulk close them? Make them into P3s?
Bugs without decisions add noise to our system, cause despair in those
trying to triage bugs, and leaves the community wondering if we listen to
them.

Methods and Definitions

In this report I talk about bugs in Core, Firefox, Firefox for Android,
Firefox for IOs, and Toolkit which are unresolved, not filed from
treeherder using the intermittent-bug-filer account*, and have no pending
needinfos.

By triaged, I mean a bug has been marked as P1 (work on now), P2 (work on
next), P3 (backlog), or P5 (will not work on but will accept a patch).

https://wiki.mozilla.org/Bugmasters#Triage_Process

A triage decision is not the same as a release decision (status and
tracking flags.)

https://mozilla.github.io/triage-report/#report

Untriaged Bugs in Current Cycle

Bugs filed since the start of the Firefox 57 release cycle (August 2nd,
2017) which do not have a triage decision.

https://mzl.la/2wzJxLP

Recommendation: review bugs you are responsible for (
https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html) and make
triage decision, or RESOLVE.

Untriaged Bugs in Current Cycle Affecting Next Release

Bugs marked status_firefox56 = affected and untriaged.

https://mzl.la/2wzjHaH

Enhancements in Release Cycle

Bugs filed in the release cycle which are enhancement requests, severity =
enhancement, and untriaged.

https://mzl.la/2wzCBy8

​Recommendation: ​product managers should review and mark as P3, P5, or
RESOLVE as WONTFIX.

High Priority Bugs without Owners

Bugs with a priority of P1, which do not have an assignee, have not been
modified in the past two weeks, and do not have pending needinfos.

https://mzl.la/2sJxPbK

Recommendation: review priorities and assign bugs, re-prioritize to P2, P3,
P5, or RESOLVE.

Inactive High Priority Bugs

There 159 bugs with a priority of P1, which have an assignee, but have not
been modified in the past two weeks.

https://mzl.la/2u2poMJ

Recommendation: review assignments, determine if the priority should be
changed to P2, P3, P5 or RESOLVE.

Stale Bugs

Bugs in need of review by triage owners. Updated weekly.

https://mzl.la/2wNyONP

* New intermittents are filed as P5s, and we are still cleaning up bugs
after this change, See  https://bugzilla.mozilla.org/show_bug.cgi?id=1381587
,
https://bugzilla.mozilla.org/show_bug.cgi?id=1381960, and
https://bugzilla.mozilla.org/show_bug.cgi?id=1383923

If you have questions or enhancements you want to see in this report,
please reply to me here, on IRC, or Slack and thank you for reading.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: RTCRtpTransceiver

[Byron Campen]

    What: RTCRtpTransceiver is a central part of the w3c webrtc API 
(https://www.w3.org/TR/webrtc/) and JSEP spec 
(https://tools.ietf.org/html/draft-ietf-rtcweb-jsep). This is a 
significant addition to the webrtc API, and entails a rework of the 
internals (it is not practical to hide this rework code behind a pref). 
This work will apply to all platforms and in all situations where 
RTCPeerConnection is supported now.


    Why: This has been in the relevant specifications for a year and a 
half, is considered "done" from a spec perspective, but still hasn't 
been implemented. Given that this spec involves browser-to-browser 
interop, it is vital that there be some running code out there.


    Where: https://bugzilla.mozilla.org/show_bug.cgi?id=1290948

    When: My intent is to land this early in the 58 release cycle.


    Our existing test suite will do a good job of covering the internal 
rework, and I have written some additional test-cases to cover the new 
API. web-platform-tests has some coverage of the new API also (in 
https://github.com/w3c/web-platform-tests/blob/master/webrtc/RTCPeerConnection-addTransceiver.html 
and 
https://github.com/w3c/web-platform-tests/blob/master/webrtc/RTCPeerConnection-getTransceivers.html).


Best regards,
Byron Campen
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: RTCRtpTransceiver

[Byron Campen]

    That's right.

Best regards,
Byron Campen

On 9/6/17 1:30 PM, Tom Ritter wrote:

IIRC, the rework won't be able to be switched 'back-to-existing' with
a pref, but we'll continue to respect existing disable-webrtc prefs
and the --disable-webrtc compiler switch, right?

-tom

On Wed, Sep 6, 2017 at 11:41 AM, Byron Campen  wrote:

 What: RTCRtpTransceiver is a central part of the w3c webrtc API
(https://www.w3.org/TR/webrtc/) and JSEP spec
(https://tools.ietf.org/html/draft-ietf-rtcweb-jsep). This is a significant
addition to the webrtc API, and entails a rework of the internals (it is not
practical to hide this rework code behind a pref). This work will apply to
all platforms and in all situations where RTCPeerConnection is supported
now.

 Why: This has been in the relevant specifications for a year and a half,
is considered "done" from a spec perspective, but still hasn't been
implemented. Given that this spec involves browser-to-browser interop, it is
vital that there be some running code out there.

 Where: https://bugzilla.mozilla.org/show_bug.cgi?id=1290948

 When: My intent is to land this early in the 58 release cycle.


 Our existing test suite will do a good job of covering the internal
rework, and I have written some additional test-cases to cover the new API.
web-platform-tests has some coverage of the new API also (in
https://github.com/w3c/web-platform-tests/blob/master/webrtc/RTCPeerConnection-addTransceiver.html
and
https://github.com/w3c/web-platform-tests/blob/master/webrtc/RTCPeerConnection-getTransceivers.html).

Best regards,
Byron Campen
___
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: Coding style: Placement of binary operators when breaking a long line

[Tom Ritter]

On Wed, Sep 6, 2017 at 7:18 PM, Mike Hommey  wrote:
> On a personal note, I find > 2000 as in the first sample more readable
> than the latter. So much so that I'd actually prefer the logical
> operators to be on the next line than boolean operator being on the
> previous.

A small +1. =)

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