Changed the loading behavior of resource:// URI since Nightly 57

[Chung-Sheng Fu]

Hi everyone,


== Background ==

Firefox and add-ons use the resource:// scheme to load resources
internally, but some of the information is available to sites the browser
connects to as well.

This means a web page can run internal scripts and inspect internal
resources of Firefox Browser, including the default preferences, which
could be a serious security and privacy issue.

== Threats ==

For example, a script on Browserleaks 
highlights what Firefox reveals when queried by a simple script running on
the site (you can find the code in https://browserleaks.com/firefox#more).

The file firefox.js passes preference names and values to the pref()
function.

Example:
http://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/browser/app/profile/firefox.js#575

Web sites can easily collect Firefox default preferences by overriding this
pref() function and using the script
“resource:///defaults/preferences/firefox.js”.

Furthermore, some default values of preferences differ between build
configurations, such as platform and locale, which means web sites could
identify individual users using this information.

== Solution ==

In order to fix these issues, we changed the behavior of loading
resource:// URIs in bug 863246
, which has been
landed in NIghtly 57.  Now, web content is not able to access resource://
URIs by default, unless the resource:// URI is declared
contentaccessible=yes in the manifests.

For Mozilla developers who need to load resource:// URIs in the web
content, here are some tips.

   1.

   Simple resource files: add them to CONTENT_ACCESSIBLE_FILES in moz.build
   

   and they will be located in resource://content-accessible/.  Currently we
   have these files moved:
   1.

  resouce://gre/res/ImageDocument.css =>
  resource://content-accessible/ImageDocument.css
  2. resource://gre/res/TopLevelImageDocument.css =>
  resource://content-accessible/TopLevelImageDocument.css
  3. resource://gre/res/TopLevelVideoDocument.css =>
  resource://content-accessible/TopLevelVideoDocument.css
  4. resource://gre-resources/viewsource.css =>
  resource://content-accessible/viewsource.css
  2.

   Folders:
   1.

  Move your folder to resource://content-accessible/.  If not
  applicable,
  2.

  Add the contentaccessble=yes flag in jar.mn where you define the URI
  mapping, e.g., about:newtab
  

  and jsonview
  

  .


== Follow-up ==

If there is anything which was impacted by this change and not caught by
us, or you are not sure how to deal with resource:// URIs in your case,
please file a bug and set it as depending on bug 863246
.  We will try the
best to resolve the compatibility issue.


Best regards,

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

Re: More Rust code

[Mike Hommey]

On Tue, Aug 08, 2017 at 09:09:09AM +0900, Mike Hommey wrote:
> On Tue, Aug 08, 2017 at 07:12:13AM +0900, Mike Hommey wrote:
> > On Fri, Aug 04, 2017 at 08:45:14AM +0300, Henri Sivonen wrote:
> > > I guess I buried my questions in too long a post, so extracting them:
> > > 
> > > On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen  
> > > wrote:
> > > > Naïvely, one would think that it should be possible to do that with
> > > > clang producing "object files" holding LLVM IR and rustc producing
> > > > "object files" holding LLVM IR and the "link" step involving mashing
> > > > those together, running LLVM optimizations again and then producing
> > > > machine code from a massive collection of mashed-together LLVM IR.
> > > ...
> > > > If we were compiling C++ using clang on all platforms, how far off
> > > > would such cross-language inlining be?
> > > >
> > > > If we could have the cross-language inlining benefit from compiling
> > > > C++ using clang on all platforms, how far off would we be from being
> > > > able to switch to clang on all platforms?
> > 
> > Here's a bunch of data why "let's switch compilers" is not necessarily
> > easy (I happen to have gathered that recently):
> > 
> > Windows MSVC (PGO) vs. clang-cl:
> > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=581eab2aa162=try=c963d0cd6565=1=0
> > 
> > Windows MSVC (PGO) vs. clang-cl -O2 (the build system currently uses -O1 for
> > msvc builds, which flags we use for clang-cl builds):
> > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=581eab2aa162=try=c963d0cd6565=1=0
> 
> It was pointed to me that both urls were the same. The second is
> actually:
> https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=581eab2aa162=try=232f977d9739=1=0

And now that the clang trunk bug that made it crash when building
Firefox is fixed, here's another go at MSVC(PGO) vs. clang-cl -O2:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=f8ff2c492d2e=try=868f0ef87a7d=1=0

(tl;dr: not much change from the version we were using before)

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

Re: Coding style: Argument alignment

[Gregory Szorc]

On Tue, Aug 29, 2017 at 7:07 PM, L. David Baron  wrote:

> On Tuesday 2017-08-29 18:32 -0700, Eric Rahm wrote:
> > Do we explicitly state a preferred alignment of arguments in multi-line
> > function declarations (primarily in the context of C++) [1]? This
> question
> > has come up in regards to using clang-format for cleaning up code [2] and
> > it would be helpful to be able to reference a concrete example in the
> style
> > guide.
> >
> > Given this example:
> >
> > int
> > Foo(const nsACstring& aStr,
> > mozilla::UniquePtr&& aBuffer,
> > nsISupports* aOptionalThing = nullptr);
> >
> > Should the reformatted style:
> >
> > a) *stay the same*
> > b) align the argument names like so:
> >
> > int
> > Foo(const nsACstring& aStr,
> > mozilla::UniquePtr&& aBuffer,
> > nsISupports*  aOptionalThing = nullptr);
> >
> > c) some other option
>
> I don't know if we've had any official statements, but I tend to
> reformat code *away* from option (b) towards your original example
> if I'm modifying it and need to add a parameter than would throw
> things out of alignment.
>
> I think I do this because (b) has the disadvantage that more code
> changes require touching additional lines, which is both changes
> blame and is extra work (although it's not extra work if we're using
> clang-format tree-wide).  Option (b) is also more likely to lead to
> overly long lines that require wrapping.


I agree with dbaron.

Vertical alignment just creates more work and code churn. Keep it simple
and don't require extra code to be changed just because you rename or
add/remove arguments. We should be encouraging code to be refactored when
justified. Extra, avoidable code churn via vertical alignment therefore
discourages cleanups and is counter-productive to long-term maintainability.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[L. David Baron]

On Tuesday 2017-08-29 18:32 -0700, Eric Rahm wrote:
> Do we explicitly state a preferred alignment of arguments in multi-line
> function declarations (primarily in the context of C++) [1]? This question
> has come up in regards to using clang-format for cleaning up code [2] and
> it would be helpful to be able to reference a concrete example in the style
> guide.
> 
> Given this example:
> 
> int
> Foo(const nsACstring& aStr,
> mozilla::UniquePtr&& aBuffer,
> nsISupports* aOptionalThing = nullptr);
> 
> Should the reformatted style:
> 
> a) *stay the same*
> b) align the argument names like so:
> 
> int
> Foo(const nsACstring& aStr,
> mozilla::UniquePtr&& aBuffer,
> nsISupports*  aOptionalThing = nullptr);
> 
> c) some other option

I don't know if we've had any official statements, but I tend to
reformat code *away* from option (b) towards your original example
if I'm modifying it and need to add a parameter than would throw
things out of alignment.

I think I do this because (b) has the disadvantage that more code
changes require touching additional lines, which is both changes
blame and is extra work (although it's not extra work if we're using
clang-format tree-wide).  Option (b) is also more likely to lead to
overly long lines that require wrapping.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Coding style: Argument alignment

[Eric Rahm]

Hi folks-

Do we explicitly state a preferred alignment of arguments in multi-line
function declarations (primarily in the context of C++) [1]? This question
has come up in regards to using clang-format for cleaning up code [2] and
it would be helpful to be able to reference a concrete example in the style
guide.

Given this example:

int
Foo(const nsACstring& aStr,
mozilla::UniquePtr&& aBuffer,
nsISupports* aOptionalThing = nullptr);

Should the reformatted style:

a) *stay the same*
b) align the argument names like so:

int
Foo(const nsACstring& aStr,
mozilla::UniquePtr&& aBuffer,
nsISupports*  aOptionalThing = nullptr);

c) some other option

-e

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

NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION_INHERITED is gone

[Andrew McCreight]

Just use NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION instead.

These have been identical for years, so I just removed the _INHERITED
variant in an attempt to make the CC macros a little simpler to deal with,
in bug 1391005.

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

Re: Debugging Firefox e10s with rr?

[Robert O'Callahan]

On Wed, Aug 30, 2017 at 1:16 AM, Kartikaya Gupta  wrote:

> rr works just fine with multiple processes. Once you have a recording
> you can use `rr ps` to show all the process that were recorded and `rr
> replay -p ` to attach to a particular process. You can combine -p
> with -g as Cameron mentioned to jump to a particular point in a
> particular process' lifetime.
>

You can also do "rr replay -p plugin-container" to debug the first
plugin-container process.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Triage Report 2017-08-28

[Emma Humphries]

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

Poll

Would you like a logged in BMO home page like:
https://fitzgen.github.io/bugzilla-todos/?

https://twitter.com/triagegirl/status/902327322178609153

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

471

477

2

Core: Build Config

450

459

3

Firefox for Android: General

406

408

4

Firefox: General

246

254

5

Core: General

235

241

6

Core: XPCOM

178

180

7

Core: JavaScript: GC

168

171

8

Core: Networking

161

159

All Components

8,703

8,822

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.

Next Release


Version

56

56

57

57

57

Date

7/31

8/7

8/14

8/21

8/28

Untriaged this Cycle

4,479

479

835

1,196

1,481

Unassigned Untriaged this Cycle

3,674

356

634

968

1,266

Affected this Release

139

125

123

119

42

Enhancements

103

3

5

11

17

Orphaned P1s

192

196

191

183

18

Inactive P1s

179

157

152

155

13

Stale Bugs

–

–

–

–

117


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.

Bugs I Want to Close

There are over 10,000 unconfirmed bugs with no activity in at least a year.

https://mzl.la/2wNLrbS

There are over 45,000 bugs which are not in the General or Untriaged
components with no activity in at least a year.

https://mzl.la/2wNXiGC

I would like to close these.

Once the noise-free closing script is ready, my plan is to automate bug
stewardship.

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


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

Re: Intent to ship: Abort API

[Ben Kelly]

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

Mozilla Log Analyzer

[Honza Bambas]

tl;dr: if you need to analyze a log file (MOZ_LOG), you may want to make 
it easy with https://janbambas.cz/moz/logan/



Long version: have a 1TB log to dive into?  Yeah.. been there :) So, 
couple months back I started to work on a log analyzer that would make 
filtering and reading large, specifically network, logs easier, more 
reliable and faster.  We often hunt for 'the network channel' with 'the 
url' and what its socket or http/2 session was doing.  Before logan this 
was hard (grep and grep and so on..). Now, load your logs to logan and 
search for your objects of interest in a very convenient way.


Logan front page links to documentation on use and hacking, as well as 
to its github repo.


The parser is very generic and extendible, open to adding new parsing 
rules and object tracking!  There is also a network breakdown/diagnostic 
functionality, see [1].


Cheers!
-hb-

[1] 
https://www.janbambas.cz/mozilla-log-analyzer-added-basic-network-diagnostics/


___
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 Tue, Aug 29, 2017 at 2:05 AM, Andrea Marchesini 
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.


> Other vendors:
> Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=750599
> I haven't found anything about Edge and Safari.
>

Edge has marked their issue for this "fixed":

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/13009916/

It hasn't shipped yet, of course.


> Estimated target date: Firefox 58.
>

If you are asking to enable the Abort API by default now, wouldn't that put
it in FF57?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Debugging Firefox e10s with rr?

[Emilio Cobos Álvarez]

On 08/29/2017 03:16 PM, Kartikaya Gupta wrote:
> Once you have a recording
> you can use `rr ps` to show all the process that were recorded and `rr
> replay -p ` to attach to a particular process.

I see, so `rr ps` was the bit whose existence I was missing :)

Thanks a lot!

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

Re: Debugging Firefox e10s with rr?

[Kartikaya Gupta]

rr works just fine with multiple processes. Once you have a recording
you can use `rr ps` to show all the process that were recorded and `rr
replay -p ` to attach to a particular process. You can combine -p
with -g as Cameron mentioned to jump to a particular point in a
particular process' lifetime.

On Tue, Aug 29, 2017 at 9:12 AM, Cameron McCormack  wrote:
> On Tue, Aug 29, 2017, at 08:58 PM, Emilio Cobos Álvarez wrote:
>> I didn't find any obvious docs in either the rr wiki[1] or MDN, so I
>> thought I'd ask before I actually need it.
>>
>> What is the best/easiest way to debug Firefox multi-process using rr?
>>
>> Right now I just disable e10s, but that's probably not a great long-term
>> solution...
>
> I do that too. :-)
>
> Mine is probably not the most efficient method, but most of the time I
> record with -M, and use output lines (either turning on logging, like
> RUST_LOG=debug, or adding printfs showing details of documents/elements)
> to orient myself when debugging.  Doing a "rr replay -g " for a
> particular output line will break in the process that printed out that
> line.  (I've never had to debug something under rr that involves the
> interaction between processes.)
> ___
> 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: Debugging Firefox e10s with rr?

[Cameron McCormack]

On Tue, Aug 29, 2017, at 08:58 PM, Emilio Cobos Álvarez wrote:
> I didn't find any obvious docs in either the rr wiki[1] or MDN, so I
> thought I'd ask before I actually need it.
> 
> What is the best/easiest way to debug Firefox multi-process using rr?
> 
> Right now I just disable e10s, but that's probably not a great long-term
> solution...

I do that too. :-)

Mine is probably not the most efficient method, but most of the time I
record with -M, and use output lines (either turning on logging, like
RUST_LOG=debug, or adding printfs showing details of documents/elements)
to orient myself when debugging.  Doing a "rr replay -g " for a
particular output line will break in the process that printed out that
line.  (I've never had to debug something under rr that involves the
interaction between processes.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Debugging Firefox e10s with rr?

[Emilio Cobos Álvarez]

Hi,

I didn't find any obvious docs in either the rr wiki[1] or MDN, so I
thought I'd ask before I actually need it.

What is the best/easiest way to debug Firefox multi-process using rr?

Right now I just disable e10s, but that's probably not a great long-term
solution...

 -- Emilio

[1]: https://github.com/mozilla/rr/wiki/Recording-Firefox
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Abort API

[Andrea Marchesini]

Standards: https://dom.spec.whatwg.org/#aborting-ongoing-activities
https://github.com/whatwg/fetch/pull/523

Summary: In bug 1378342 I have been working on Abort API and its
integration with Fetch API.
There are 2 separate prefs: dom.abortController.enabled and
dom.abortController.fetch.enabled both set to false in release, and to true
in nightly. These allow the enabling of Abort API independently, and the
enabling of Abort + Fetch.
Abort API is a simple API that can be used separately, but when integrated
with Fetch, if a fetch() operation is aborted, this involves the canceling
of the networking, and the body consuming, and the ReadableStream (if
involved and enabled).

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).

Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1394085
https://bugzilla.mozilla.org/show_bug.cgi?id=1378342

Other vendors:
Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=750599
I haven't found anything about Edge and Safari.

Estimated target date: Firefox 58.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform