Response.body streams landing on trunk, default off

[Ben Kelly]

Hi all,

As some of you may know :till and :baku have been working hard to implement
ReadableStream support.  Till landed the js bits in bug 1272697:

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

Andrea has been working on the DOM integration with Fetch API in bug
1128959:

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

This second bug is now on inbound and looks like its going to stick (famous
last words...).  Hopefully it will be in trunk tomorrow and in Saturday's
nightly.

Please note that streams will be disabled by default for now.  There are a
few more issues to address before we can enable it by default.

If you would like to test Response.body please enable these two prefs:

  javascript.options.streams
  dom.streams.enabled

Please test and file any bugs you might find. I've done some local testing
on a few sites I'm aware of that use streams and so far I have not found
any functional problems.

Many thanks to Till and Andrea for their hard work on streams!

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

Quantum Flow Engineering Newsletter #19

[Ehsan Akhgari]

Hi everyone,

As usual, I have some quick updates to share about what we've been up to on
improving the performance of the browser in the past week or so.  Let's
first look at our progress on the Speedometer benchmark.  Our performance
goal for Firefox 57 was to get within 20% of Chrome's benchmark score on
our Acer reference hardware  on
Win64.  Those of you who watch the Firefox Health Dashboards
 every once in a while may have noticed
that now we are well within that target:

[image: Speedometer Progress Chart from the Firefox Health Dashboard,
within 14.86% of Chrome's benchmark score]


It's nice to see the smiley face on this chart, finally!  You can see the
more detailed downward slope on the AWFY graph that shows the progress

in the past couple of weeks or so (dark red dots are PGO builds, orange
dots are non-PGO builds, and of course green in Chrome):

[image: Detailed Speedometer progress in the past couple of weeks on Win64
(Acer reference hardware)]
The
situation on Win32 is a bit worse, due to Chrome's recent switch

to use clang-cl  on
Windows instead of MSVC which gave them an around 30% speed boost on the
32-bit Speedometer score, but we have made progress nonetheless.  Such is
the nature of tracking moving targets!

[image: Speedometer progress chart on Win32]
The
other performance aspect to have a look at again is our progress at
eliminating slow synchronous IPC calls.  I last wrote about this about three
weeks ago
,
and since then at least one major change happened: the infamous
document.cookie synchronous IPC
 call was eliminated,
so I figured it may be a good time to look at the data

again.

[image: Sync IPC Analysis for 2017-08-10]
Telemetry
data is laggy since it includes data from older versions of Nightly, but if
you compare this to the previous chart
,
there should be a stark difference visible:
PCookieService::Msg_GetCookieString is now a much smaller part of the
overall data (at around 26.1%).  Looking at the list of the top ten
messages, the next ones in order are the usual suspects for those who have
followed these newsletters for a while: some JS initiated IPC,
PAPZCTreeManager::Msg_ReceiveMouseInputEvent, followed by more JS IPC,
followed by PBrowser::Msg_NotifyIMEFocus
, followed by even
more JS IPC, followed by 2 new messages that are now surfacing as we've
fixed the worst ones of these: PDocAccessible::Msg_SyncTextChangeEvent
which is related to accessibility and the data shows it affects a
relatively small number of sessions due to its low submission rate, and
PContent::Msg_ClassifyLocal, which probably comes from turning the Flash
plugin click-to-play by default
.

Now let's look at the breakdown of synchronous IPC messages initiated from
JS:

[image: JS Sync IPC Analysis for 2017-08-10]


The story here remains unchanged: most of the sync IPC messages we're
seeing come from legacy extensions, and there is also the contextmenu sync
IPC , which has a
patch pending review.  However, the picture here may start changing quite
soon.  You may have seen the recent announcement

about legacy extensions being disabled on Nightly starting from tomorrow,
so hopefully this data (and the C++ sync IPC data) will soon start to shift
to reflect more of the performance characteristics that our users on the
release channel will experience for Firefox 57.

Now please let me to acknowledge the great work

   - Ting-Yu Chou removed some needless copying from SpiderMonkey
   HashTable::lookupForAdd()
   .
   - Jim Chen fixed a hang during text selection
    which 

Re: CodeCoverage! Monthly Update

[Sylvestre Ledru]

The patch providing coverage in rust landed here:
https://github.com/rust-lang/rust/pull/42433

If I understood correctly, we are waiting for rust 1.20 to be able to
use it.

Sylvestre




Le 10/08/2017 à 22:03, Chris Peterson a écrit :
> Kyle, do you know if Rust code coverage is blocked on any remaining
> Rust toolchain issues?
>
> chris
>
>
> On 2017-08-10 11:31 AM, Kyle Lahnakoski wrote:
>>
>>
>> Did you have that sense you were missing something? Well, you were
>> right: You were missing your ...
>>
>> # *Monthly CodeCoverage! update!  \o/ *
>>
>> /If you //want to hear more about an//y of the//s//e items, please
>> contact me and I will get you more detailed information/*
>> *
>>
>> *## **Summary of July*
>>
>>   * *More hard work on the ETL pipeline*: Condensing the data to make
>> it manageable, and writing more efficient code for faster
>> processing. There is still more work to be done, but it's
>> working.  Marco summarized this work with an excellent blog post:
>> [1]
>> https://marco-c.github.io/2017/07/28/code-coverage-architecture.html
>>   * *Analyzing coverage variability* - If you recall from previous
>> months, I mentioned that different coverage runs show different
>> coverage numbers: We call this "coverage variability", and it
>> even exists when comparing two runs from the same revision.
>> gmierz has been looking into this variability to better
>> understand its size, and character. [2], [3]
>>   * *Finished detailed the plan for the MVP *[4] - This MVP is for
>> visualizing coverage of net-new lines: Relman is interested in
>> the coverage on the net-new lines of every changeset  This is
>> hard given we can only run coverage on every central push. We now
>> have a plan for how to get this done, as best as possible, with
>> the information given.
>>
>> *## Plans for August*
>>
>>   * *Build the MVP* - Visualize coverage of net new lines by
>> changeset: Now that we have a plan,  armenzg has already started
>> the frontend UI work [5], [6], and will be working with marco
>> working on the backend [7]
>>   * *Continue work on optimizing the ETL pipelines* - necessary work *
>> *
>>
>> *
>> **## Meetings*
>>
>> We have weekly CodeCoverage meetings, and you are welcome to attend:
>>
>>   * When: Held every Friday @ 11:30 EDT (08:30 PDT)
>>   * Where: Kyle's video room
>> https://v.mozilla.com/flex.html?roomdirect.html=huhL8WaTwCwC
>>   * Etherpad: https://public.etherpad-mozilla.org/p/code_coverage_Q1_17
>>
>>
>> *## Reference*
>>
>> [1] Blog post on coverage collection and aggregation:
>> https://marco-c.github.io/2017/07/28/code-coverage-architecture.html
>>
>> [2] Variability analysis code - 
>> https://github.com/gmierz/coco-variability-tools
>>
>> [3] Example variability output -
>> https://gmierz.github.io/variability/variability_index.html
>>
>> [4] Details for UI -
>> https://public.etherpad-mozilla.org/p/code_coverage_Q3_17
>>
>> [5] Code for UI - https://github.com/armenzg/code_cov_experiments
>>
>> [6] Example UI (very rough, but stay tuned!) -
>> https://armenzg.github.io/code_cov_experiments/
>>
>> [7] Code for backend -
>> https://github.com/mozilla-releng/services/tree/master/src/shipit_code_coverage
>>
>>
>>
>>
>> On 2017-07-06 21:37, Kyle Lahnakoski wrote:
>>>
>>>
>>>
>>> ## Summary of Past Quarter
>>>
>>> Coverage is enabled for nearly all tests, and scheduled every push
>>> [1]!!
>>>
>>>   * All c/c++ test suites have coverage enabled
>>>   * talos coverage is enabled
>>>   * jsvm[7] coverage is enabled, and running
>>>   * codecov.io [2] shows the results, broken down by directory
>>>
>>> ## Plans for Q3
>>>
>>> The overall plan for Q3 is laid out in the planning document [12]. 
>>> Put simply, a **coverage differential viewer**, operating at low
>>> resolution (per central push), has enough promise to justify Q3
>>> effort on CodeCoverage.
>>>
>>> ## The Complications
>>>
>>>   * Rust code coverage is still delayed [6] - maybe by mid quarter
>>>   * The data volume is very large; coveralls.io and codecov.io are
>>> having some difficulty dealing with the volume.
>>>   * There is instability in the coverage numbers due to variability
>>> in our test runs; think GC and telemetry logic.  Multiple
>>> coverage runs will be required to get a total coverage number
>>>   * Intermittents are impacting coverage reliability - we will
>>> require a coverage health monitor to know if coverage is "complete"
>>>
>>> ## Summary of this past June
>>>
>>>   * upgrading tests to use Ubuntu 16.04
>>>   * fixing blockers that stood in the way of rust coverage[6]
>>>   * enabling coverage to even more suites, like talos [10]
>>>   * adding JavaScript to the codecov/coveralls report
>>>   * getting a handle on the volume of data code coverage is producing
>>>
>>> ## Plans for July
>>>
>>>   * continued work on ETL pipeline
>>>   * enable coverage for spidermonkey [11]
>>>   * see the first 

Fwd: Security releases for Git, Mercurial, and Subversion

[Gregory Szorc]

-- Forwarded message --
From: Gregory Szorc 
Date: Thu, Aug 10, 2017 at 12:10 PM
Subject: Security releases for Git, Mercurial, and Subversion
To: Firefox Dev , dev-version-control <
dev-version-cont...@lists.mozilla.org>


Git, Mercurial, and Subversion just had a coordinated release to mitigate a
security vulnerability regarding the parsing of ssh:// URLs. Essentially,
well-crafted ssh:// URLs (e.g. in a subrepo, submodule, or svn:externals
references) could lead to local code execution. If you run a command like
`git clone --recurse-submodules` or `hg pull --update` and nefarious data
is received, you could be p0wned.

This is tracked in at least CVE-2017-1000116 and CVE-2017-1000117.

In addition, Mercurial issued a security fix for symlink handling that
could result in arbitrary filesystem write (attempts) for well-crafted
symlinks. This is CVE-2017-1000115.

You should upgrade your version control clients ASAP to eliminate exposure
to these bugs. Until you do, be extra cognizant where you pull from -
especially any operation related to subrepos/submodules.

As of today, hg.mozilla.org is now configured to not allow subrepos and
symlinks on non-user repos. The main Firefox repos have been audited and no
"bad" data is present. So, the canonical Firefox repos cannot be used as a
delivery vehicle for these exploits. I anticipate popular hosting services
like GitHub and Bitbucket will take similar actions and make similar
announcements.

Critical version control infrastructure like hg.mozilla.org and Autoland
has been patched for several days courtesy of responsible early disclosure
of the vulnerabilities and fixes from the Mercurial Project.

Announcements:

hg: https://www.mercurial-scm.org/pipermail/mercurial/2017-
August/050522.html
git: http://marc.info/?l=git=150238802328673=2
svn: http://mail-archives.apache.org/mod_mbox/subversion-
announce/201708.mbox/%3C2fefe468-7d41-11e7-aea1-9312c6089150%40apache.org%3E
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CodeCoverage! Monthly Update

[Chris Peterson]

Kyle, do you know if Rust code coverage is blocked on any remaining Rust 
toolchain issues?


chris


On 2017-08-10 11:31 AM, Kyle Lahnakoski wrote:



Did you have that sense you were missing something? Well, you were 
right: You were missing your ...


# *Monthly CodeCoverage! update!  \o/ *

/If you //want to hear more about an//y of the//s//e items, please 
contact me and I will get you more detailed information/*

*

*## **Summary of July*

  * *More hard work on the ETL pipeline*: Condensing the data to make
it manageable, and writing more efficient code for faster
processing. There is still more work to be done, but it's
working.  Marco summarized this work with an excellent blog post:
[1]
https://marco-c.github.io/2017/07/28/code-coverage-architecture.html
  * *Analyzing coverage variability* - If you recall from previous
months, I mentioned that different coverage runs show different
coverage numbers: We call this "coverage variability", and it even
exists when comparing two runs from the same revision. gmierz has
been looking into this variability to better understand its size,
and character. [2], [3]
  * *Finished detailed the plan for the MVP *[4] - This MVP is for
visualizing coverage of net-new lines: Relman is interested in the
coverage on the net-new lines of every changeset  This is hard
given we can only run coverage on every central push. We now have
a plan for how to get this done, as best as possible, with the
information given.

*## Plans for August*

  * *Build the MVP* - Visualize coverage of net new lines by
changeset: Now that we have a plan,  armenzg has already started
the frontend UI work [5], [6], and will be working with marco
working on the backend [7]
  * *Continue work on optimizing the ETL pipelines* - necessary work *
*

*
**## Meetings*

We have weekly CodeCoverage meetings, and you are welcome to attend:

  * When: Held every Friday @ 11:30 EDT (08:30 PDT)
  * Where: Kyle's video room
https://v.mozilla.com/flex.html?roomdirect.html=huhL8WaTwCwC
  * Etherpad: https://public.etherpad-mozilla.org/p/code_coverage_Q1_17


*## Reference*

[1] Blog post on coverage collection and aggregation: 
https://marco-c.github.io/2017/07/28/code-coverage-architecture.html


[2] Variability analysis code - 
https://github.com/gmierz/coco-variability-tools


[3] Example variability output - 
https://gmierz.github.io/variability/variability_index.html


[4] Details for UI - 
https://public.etherpad-mozilla.org/p/code_coverage_Q3_17


[5] Code for UI - https://github.com/armenzg/code_cov_experiments

[6] Example UI (very rough, but stay tuned!) - 
https://armenzg.github.io/code_cov_experiments/


[7] Code for backend - 
https://github.com/mozilla-releng/services/tree/master/src/shipit_code_coverage





On 2017-07-06 21:37, Kyle Lahnakoski wrote:




## Summary of Past Quarter

Coverage is enabled for nearly all tests, and scheduled every push [1]!!

  * All c/c++ test suites have coverage enabled
  * talos coverage is enabled
  * jsvm[7] coverage is enabled, and running
  * codecov.io [2] shows the results, broken down by directory

## Plans for Q3

The overall plan for Q3 is laid out in the planning document [12].  
Put simply, a **coverage differential viewer**, operating at low 
resolution (per central push), has enough promise to justify Q3 
effort on CodeCoverage.


## The Complications

  * Rust code coverage is still delayed [6] - maybe by mid quarter
  * The data volume is very large; coveralls.io and codecov.io are
having some difficulty dealing with the volume.
  * There is instability in the coverage numbers due to variability
in our test runs; think GC and telemetry logic.  Multiple
coverage runs will be required to get a total coverage number
  * Intermittents are impacting coverage reliability - we will
require a coverage health monitor to know if coverage is "complete"

## Summary of this past June

  * upgrading tests to use Ubuntu 16.04
  * fixing blockers that stood in the way of rust coverage[6]
  * enabling coverage to even more suites, like talos [10]
  * adding JavaScript to the codecov/coveralls report
  * getting a handle on the volume of data code coverage is producing

## Plans for July

  * continued work on ETL pipeline
  * enable coverage for spidermonkey [11]
  * see the first hints of Rust coverage
  * build a coverage health monitor to deal with "the complications"
(above)

## Meetings

We have weekly CodeCoverage meetings, and you are welcome to attend:

  * When: Held every Friday @ 11:30 EDT (08:30 PDT)
  * Where: Kyle's video room
https://v.mozilla.com/flex.html?roomdirect.html=huhL8WaTwCwC
  * Etherpad: https://public.etherpad-mozilla.org/p/code_coverage_Q1_17


## Reference

[1] See coverage on TH 
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central=ccov


[1b] Example on TH: 

CodeCoverage! Monthly Update

[Kyle Lahnakoski]

Did you have that sense you were missing something? Well, you were
right: You were missing your ...

# *Monthly CodeCoverage! update!  \o/ *

/If you //want to hear more about an//y of the//s//e items, please
contact me and I will get you more detailed information/*
*

*## **Summary of July*

  * *More hard work on the ETL pipeline*: Condensing the data to make it
manageable, and writing more efficient code for faster processing.
There is still more work to be done, but it's working.  Marco
summarized this work with an excellent blog post: [1]
https://marco-c.github.io/2017/07/28/code-coverage-architecture.html
  * *Analyzing coverage variability* - If you recall from previous
months, I mentioned that different coverage runs show different
coverage numbers: We call this "coverage variability", and it even
exists when comparing two runs from the same revision. gmierz has
been looking into this variability to better understand its size,
and character. [2], [3]
  * *Finished detailed the plan for the MVP *[4] - This MVP is for
visualizing coverage of net-new lines: Relman is interested in the
coverage on the net-new lines of every changeset  This is hard given
we can only run coverage on every central push. We now have a plan
for how to get this done, as best as possible, with the information
given.

*## Plans for August*

  * *Build the MVP* - Visualize coverage of net new lines by changeset:
Now that we have a plan,  armenzg has already started the frontend
UI work [5], [6], and will be working with marco working on the
backend [7]
  * *Continue work on optimizing the ETL pipelines* - necessary work *
*

*
**## Meetings*

We have weekly CodeCoverage meetings, and you are welcome to attend:

  * When: Held every Friday @ 11:30 EDT (08:30 PDT)
  * Where: Kyle's video room
https://v.mozilla.com/flex.html?roomdirect.html=huhL8WaTwCwC
  * Etherpad: https://public.etherpad-mozilla.org/p/code_coverage_Q1_17


*## Reference*

[1] Blog post on coverage collection and aggregation:
https://marco-c.github.io/2017/07/28/code-coverage-architecture.html

[2] Variability analysis code - 
https://github.com/gmierz/coco-variability-tools

[3] Example variability output -
https://gmierz.github.io/variability/variability_index.html

[4] Details for UI -
https://public.etherpad-mozilla.org/p/code_coverage_Q3_17

[5] Code for UI - https://github.com/armenzg/code_cov_experiments

[6] Example UI (very rough, but stay tuned!) -
https://armenzg.github.io/code_cov_experiments/

[7] Code for backend -
https://github.com/mozilla-releng/services/tree/master/src/shipit_code_coverage




On 2017-07-06 21:37, Kyle Lahnakoski wrote:
>
>
>
> ## Summary of Past Quarter
>
> Coverage is enabled for nearly all tests, and scheduled every push [1]!!
>
>   * All c/c++ test suites have coverage enabled
>   * talos coverage is enabled
>   * jsvm[7] coverage is enabled, and running
>   * codecov.io [2] shows the results, broken down by directory
>
> ## Plans for Q3
>
> The overall plan for Q3 is laid out in the planning document [12]. 
> Put simply, a **coverage differential viewer**, operating at low
> resolution (per central push), has enough promise to justify Q3 effort
> on CodeCoverage.
>
> ## The Complications
>
>   * Rust code coverage is still delayed [6] - maybe by mid quarter
>   * The data volume is very large; coveralls.io and codecov.io are
> having some difficulty dealing with the volume.
>   * There is instability in the coverage numbers due to variability in
> our test runs; think GC and telemetry logic.  Multiple coverage
> runs will be required to get a total coverage number
>   * Intermittents are impacting coverage reliability - we will require
> a coverage health monitor to know if coverage is "complete"
>
> ## Summary of this past June
>
>   * upgrading tests to use Ubuntu 16.04
>   * fixing blockers that stood in the way of rust coverage[6]
>   * enabling coverage to even more suites, like talos [10]
>   * adding JavaScript to the codecov/coveralls report
>   * getting a handle on the volume of data code coverage is producing
>
> ## Plans for July
>
>   * continued work on ETL pipeline
>   * enable coverage for spidermonkey [11]
>   * see the first hints of Rust coverage
>   * build a coverage health monitor to deal with "the complications"
> (above)
>
> ## Meetings
>
> We have weekly CodeCoverage meetings, and you are welcome to attend:
>
>   * When: Held every Friday @ 11:30 EDT (08:30 PDT)
>   * Where: Kyle's video room
> https://v.mozilla.com/flex.html?roomdirect.html=huhL8WaTwCwC
>   * Etherpad: https://public.etherpad-mozilla.org/p/code_coverage_Q1_17
>
>
> ## Reference
>
> [1] See coverage on TH
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-central=ccov
>
> [1b] Example on TH:
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-central=433c379d6e448dc64df25a6b4d8739c99e84d102=ccov
>
>
> [2] codecov.io 

Re: disabled non-e10s tests on trunk

[Ben Kelly]

On Tue, Aug 8, 2017 at 5:18 PM, Ben Kelly  wrote:

> On Tue, Aug 8, 2017 at 5:12 PM,  wrote:
>
>> In bug 1386689, we have turned them off.  There was some surprise in
>> doing this and some valid concerns expressed in comments in the bug.  Given
>> that, I thought we should bring this information to a wider audience on
>> dev.platform so more developers are aware of the change.
>>
>> While we get some advantages to not running duplicated tests (faster try
>> results, less backlogs, fewer intermittent failures) there might be
>> compelling reasons to run some tests in e10s based on specific coverage.
>> With that said, I would like to say that any tests we turn on as non-e10s
>> must have a clearly marked end date- as in this is only a temporary measure
>> while we schedule work in to gain this coverage fully with e10s tests.
>>
>
> If we have an android test disabled (a lot I think), then we should
> consider continuing to run the test in non-e10s on desktop linux.  Having
> more real devices to run android tests on would probably reduce the number
> of tests that are disabled.  The emulator is extremely slow and not
> representative of real hardware.
>

BTW, we have a large corpus of tests that don't run on android at all:
WPT.  Increasingly over time features are only covered by WPT tests.

I think we should keep at least non-e10s running on linux or linux64 for
now until we can improve our android test coverage or move android to e10s.

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

Re: Quantum Flow Engineering Newsletter #18

[David Durst]

While we're pushing forward on Quantum Flow things, there are a lot of
people looking to help out where they can.

To make this at least a little organized, please remember to assign a bug
to yourself if you're working on it (or planning to).
https://charts.mozilla.org/quantum/blockers.html# is showing a few
unassigned that are actually assigned (judging from the comments).

Similarly, if something IS assigned to you, but it's not actively being
worked on and you're OK with someone else doing so, please un-assign
yourself.

Thanks...


--
David Durst [:ddurst]

On Tue, Aug 8, 2017 at 9:26 AM, Mike Conley  wrote:

> Mike Conley ported scrollbox to use smooth scrolling instead of JS driven
>> scrolling .  This
>> affects most importantly scrolling the tab bar, and should make it more
>> smooth by removing a lot of slow code that used to run and off-loading that
>> work to the compositor through CSS-based smooth scrolling!  He notes
>>  on the bug
>> that in order to achieve great performance some follow-ups may be needed.
>
>
> Just to ensure credit is given where it's due - that was 95% Dão
> Gottwald's work. I just helped push the last 5% over the line when he got
> focused on getting square tabs landed. Thanks Dão!
>
> On 4 August 2017 at 04:04, Ehsan Akhgari  wrote:
>
>> Hi everyone,
>>
>> This has been a busy week.  A lot of fixes have landed, setting up the
>> Firefox 57 cycle for a good start.  On the platform side, a notable change
>> that will be in the upcoming Nightly is the fix for document.cookie using
>> synchronous IPC.  This super popular API call slows down various web pages
>> today in Firefox, and starting from tomorrow, the affected pages should
>> experience a great speedup.  I have sometimes seen the slowdown caused by
>> this one issue to amount to a second or more in some situations, thanks a
>> lot to Amy and Josh for their hard work on this feature.  The readers of
>> these newsletters know that the work on fixing this issue has gone on for a
>> long time, and it's great to see it land early in the cycle.
>>
>> On the front-end side, more and more of the UI changes of Photon are
>> landing in Nightly.  One of the overall changes that I have seen is that
>> the interface is starting to feel a lot more responsive and snappy than it
>> was around this time last year.  This is due to many different details.  A
>> lot of work has gone into fixing rough edges in the performance of the
>> existing code, some of which I have covered but most of which is under the 
>> Photon
>> Performance project
>> .  Also the new UI
>> is built with performance in mind, so for example where animations are
>> used, they use the compositor and don't run on the main thread.  All of the
>> pieces of this performance puzzle are nicely coming to fit in together, and
>> it is great to see that this hard work is paying off.
>>
>> On the Speedometer front, things are progressing with fast pace.  We have
>> been fixing issues that have been on our list from the previous findings,
>> which has somewhat slowed down the pace of finding new issues to work on.
>> Although the SpiderMonkey team haven't waited around
>>  and are
>> continually finding new optimization opportunities out of further
>> investigations.  There is still more work to be done there!
>>
>> I will now move own to acknowledge the great work of all of those who
>> helped make Firefox faster last week.  I hope I am not mistakenly
>> forgetting any names here!
>>
>>- Andrew McCreight got rid of some cycle collector overhead
>> related to
>>using QueryInterface to canonicalize the nsISupports pointers stored in 
>> the
>>purple buffer, and similarly for pointers encountered during
>>traversal of native roots
>> as well.
>>- Kris Maglione added some utilities to BrowserUtils
>> that should
>>help our front-end devs avoid synchronous layout and style flushes.
>>- Amy Chung got rid of the sync IPC messages in the cookie service
>>! This was a
>>substantial amount of work and should eliminate jank on a number of sites
>>that get and set cookies frequently.
>>- Jessica Jong made us check a boolean flag instead of doing a linear
>>search looking for an attribute in order to determine whether an Element 
>> is
>>required .
>>- André Bargull made String.prototype.toLower/UpperCase use direct VM
>>calls, and also added specialized unicode::CanLower/UpperCase 

Re: nsIURI API changes - punycode domain names

[Anne van Kesteren]

On Wed, Aug 9, 2017 at 8:37 PM, Boris Zbarsky  wrote:
> On 8/9/17 1:43 PM, Daniel Veditz wrote:
>>
>> What do web pages do if they want to reflect a pretty URL into their page?
>
> Cry, basically.

I have a proposal: https://github.com/whatwg/url/pull/288.

There's two issues:

1) Ryan Sleevi is opposed and nobody else from Google seems to care
enough to convince him. (We could potentially try to convince them by
shipping something in Firefox and Safari (Apple has shown interest).)

2) What is the exact algorithm that it should use. In particular,
should it use the same heuristics as the browser for whether it
becomes Punycode or Unicode, should those heuristics be standardized,
or should it always go to Unicode if possible, even if the browser
wouldn't (e.g., in case of mixed scripts).


> This is the fundamental reason I was opposed to this behavior change, but
> apparently no other browsers care about this issue and we were getting
> compat problems.  :(

Well, we also didn't use an algorithm that was standardized anywhere
so other browsers sticking with Punycode seems fairly reasonable in
light of that.


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

Re: Phabricator and confidential reviews

[Frederik Braun]

Having both reported, fixed and reviewed security bugs, I feel an
uni-directional sync from Phabricator to BMO is not going to cut it. I
think it will be unexpected for most users and might just lead to
additional "why can I not see the patch" bug comments.

I understand that it's more work, but I really think we should aim for
"perfect" rather than "good enough", when it comes to developer experience.

I don't see a strong "security reason" not to include people copied in
the bug to see the patch. Quite contrary: It's also what distinguishes
our bug bounty program from others. We're more open, we have outside
reporters work with us on the patch and see all the comments and
iterations that lead to its perfection. This encourages early feedback
and improves the outcome.

On 10.08.2017 00:57, Daniel Veditz wrote:
> On Wed, Aug 9, 2017 at 11:32 AM, Mark Côté  wrote:
> 
>> I actually like Gijs's proposal, to mirror *from* Phabricator *to* BMO.
>> That way, if you're looking at the bug and want to pull someone in, you CC
>> them; if you're looking at the fix and want to involve someone, you add
>> them as a subscriber which then incidentally lets them view the bug, for
>> background and updates and such.
> 
> 
> ​What if there's not "the" fix but multiple patches? This is quite common
> for security bugs where a testcase that reveals the vulnerability is done
> in a separate patch so it can be checked in after we release the fix. Or
> occasionally bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1371259
> that had 9 separate patches. Would the same people have to be separately
> subscribed to each?​
> 
> ​There's a case to be made for adding in both directions. How much work
> would it be to (add all CCs to subscriber list) when attaching a new patch,
> and (subscribe person to all existing patches)​ when someone new is CC'd to
> a bug? This was my attempt to match your "one time mirroring" approach to
> going the other way, which makes sense to me.
> 
> And don't forget reporter and assignees. Occasionally a reporter not in the
> security group will notice that a patch is insufficient which is nicer to
> find before the patch is committed than after the commit link is added to
> the bug. Sometimes someone other than the official assignee adds a patch
> for an alternate approach to a fix and asks the assignee for feedback,
> though that's uncommon and the assignee could just be manually subscribed
> to the patch at that point.
> 
> We can wait and see how common the "please subscribe me to the patch"
> requests are, but I suspect they'll be common enough.
> 
> -
> ​Dan Veditz​
> ___
> 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