Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[smaug]

On 06/03/2016 06:41 PM, Boris Zbarsky wrote:

Summary: The current IDL spec says that Object.prototype.toString() on a DOM prototype 
object for interface Foo is "[object FooPrototype]", whereas
for instances of the interface it's "[object Foo]", and that's what we 
implement.  However, as we try to move to the ES6 @@toStringTag world, this
causes some problems, which are described in 
.  So there is a proposal 
to change the spec to
have the string be "[object Foo]" for the prototype as well.

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

Spec: Would get adjusted as needed.

Target release: 49

Preference: None

Devtools bug: none so far, but maybe we need one?  Does devtools rely on the 
JSClass name or Object.prototype.toString anywhere?

Behavior of other browsers:

* Chrome: has been shipping the behavior I'm proposing to change to since 
Chrome 50, I believe.  Current Chrome release version is 51.

* Safari (and WebKit nightly): has the behavior we currently have.

* Edge: has the behavior we currently have.

Possible alternatives: We could make @@toStringTag an accessor on the prototype 
that returns different things for instances and the prototype itself.

-Boris



Why is the change being done?  Why do we think @@toStringTag stuff is a good 
thing?
IMHO, the current Gecko behavior for toString makes more sense than the 
proposed one.
Foo object after all is quite different beast than its prototype so I'd expect 
toString() to reflect that.

Not really objecting anything here, but just wondering why this kind of change 
is being done.
W3C bug doesn't quite capture the reasoning here.


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

Proposed W3C Charter: Web Performance Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web Performance Working Group
  https://w3c.github.io/charter-webperf/
  https://lists.w3.org/Archives/Public/public-new-work/2016Jun/0001.html

Mozilla has the opportunity to send comments or objections through
Thursday, June 30.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-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

W3C Proposed Recommendation: Subresource Integrity (SRI)

[L. David Baron]

A W3C Proposed Recommendation is available for the membership of W3C
(including Mozilla) to vote on, before it proceeds to the final
stage of being a W3C Recomendation:

  Subresource Integrity
  https://www.w3.org/TR/SRI/
  deadline: Tuesday, June 7, 2016

Given Mozilla's involvement in developing the spec, and
implementation of it, I intend to vote in favor without comments.
But if there are comments you think Mozilla should send as part of
the review, please say so in this thread.  (I'd note, however, that
there have been many previous opportunities to make comments, so
it's somewhat bad form to bring up fundamental issues for the first
time at this stage.)

If you do so, please make sure to cc: my email, as I won't be
checking the list prior to the deadline for comments.

-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

Re: Documentation on how to read crash reports

[Ted Mielczarek]

On Thu, May 26, 2016, at 02:41 PM, Benoit Girard wrote:
> - Crash address can give you a hint as to what's going on: 0x0 -> null
> crash, 0x8 -> null offset accessing a member like this->mFoo,

N.B.: due to the way addressing works on x86-64, if the crash address is
"0x0" for a Linux/OS X crash report, or "0x" for a
Windows crash report, it's highly likely that the value is incorrect[1].
This is due to how these faults are reported from the CPU. (I have an
in-progress Breakpad patch[2] to detect this and attempt to find the
actual faulting address, but it needs some more work to land upstream.
The commit message also describes the root cause more thoroughly, if
you're interested.)

You can sanity check these crashes by clicking the "Raw Dump" tab. The
top frame of the crashing stack in that JSON data will contain the
registers from the crash context. If you see a suspicious value in one
of them (like a poison pattern) more thorough analysis may be warranted.

-Ted

1. https://bugzilla.mozilla.org/show_bug.cgi?id=974420
2.
https://github.com/luser/breakpad/commit/c8c0bbcdba178b74db171c21d2c6f4a59efd0131
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documentation on how to read crash reports

[Ted Mielczarek]

On Thu, May 26, 2016, at 09:52 AM, Benjamin Smedberg wrote:
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_a_minidump

I spent some time today cleaning this page up a bit. I streamlined the
Windows section (since you no longer need to manually download the
matching binaries or source), added a section about minidump-2-core for
Linux, and added a little bit of information about some useful tools I
have for additional dump analysis.

Hope that's useful to someone,
-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Top crash list is odd right now

[Mike Conley]

I reviewed the patch. Currently, the feature is only enabled on Nightly,
Aurora and Beta. We originally wanted the beta unsubmitted crashes due
to the content process crashes we were getting there with e10s that we
didn't understand.

Now that we have a better handle on those content process crashes, I
think we're still trying to determine if letting this ride to beta makes
sense.

See bug 1269998 for context.

On 03/06/2016 11:45 AM, Lawrence Mandel wrote:
> Is the plan to prompt on release as well?
> 
> On Fri, Jun 3, 2016 at 11:33 AM, Andrew McCreight 
> wrote:
> 
>> blassey landed a patch to suggest that users submit unsubmitted crash
>> reports. This is going to make various kinds of crashes, like shutdown
>> crashes, grossly overrepresented in the crash-stats "Top Crashers" list.
>> You probably want to use "By build date" instead of the default "By report
>> date" for the next week or so until that settles out.
>>
>> Presumably the same thing will happen the first week or two of Aurora, on
>> that channel, and likewise with beta.
>> ___
>> 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

Intent to implement: a list of domains to auto-disable plugins

[Benjamin Smedberg]

Summary: plugins, especially Flash, are still a major attack vector for
malware authors. We intend to create a list of domains which are commonly
loaded in a 3rd-party context and which therefore present a higher than
normal risk of malware attacks. Sites on this list would be automatically
sandboxed so that they could not run plugins.

I am going to ask social networking/sharing sites that are commonly
embedded to join this blocklist. I'll also contact commonly-embedded web
tools such as disqus. And finally I'll be working with large ad networks,
because that is where a lot of the infection risk comes from.

The implementation of this system will likely use the sandboxed-iframe
mechanism.

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

Target release: unsure; hopefully 50

Behavior of other browsers: we have no indication that other browsers are
ready to adopt this strategy yet.

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

Re: Top crash list is odd right now

[Lawrence Mandel]

Is the plan to prompt on release as well?

On Fri, Jun 3, 2016 at 11:33 AM, Andrew McCreight 
wrote:

> blassey landed a patch to suggest that users submit unsubmitted crash
> reports. This is going to make various kinds of crashes, like shutdown
> crashes, grossly overrepresented in the crash-stats "Top Crashers" list.
> You probably want to use "By build date" instead of the default "By report
> date" for the next week or so until that settles out.
>
> Presumably the same thing will happen the first week or two of Aurora, on
> that channel, and likewise with beta.
> ___
> 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

Intent to implement and ship: Changing the toString result on DOM prototype objects

[Boris Zbarsky]

Summary: The current IDL spec says that Object.prototype.toString() on a 
DOM prototype object for interface Foo is "[object FooPrototype]", 
whereas for instances of the interface it's "[object Foo]", and that's 
what we implement.  However, as we try to move to the ES6 @@toStringTag 
world, this causes some problems, which are described in 
.  So there is a 
proposal to change the spec to have the string be "[object Foo]" for the 
prototype as well.


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

Spec: Would get adjusted as needed.

Target release: 49

Preference: None

Devtools bug: none so far, but maybe we need one?  Does devtools rely on 
the JSClass name or Object.prototype.toString anywhere?


Behavior of other browsers:

* Chrome: has been shipping the behavior I'm proposing to change to 
since Chrome 50, I believe.  Current Chrome release version is 51.


* Safari (and WebKit nightly): has the behavior we currently have.

* Edge: has the behavior we currently have.

Possible alternatives: We could make @@toStringTag an accessor on the 
prototype that returns different things for instances and the prototype 
itself.


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

Top crash list is odd right now

[Andrew McCreight]

blassey landed a patch to suggest that users submit unsubmitted crash
reports. This is going to make various kinds of crashes, like shutdown
crashes, grossly overrepresented in the crash-stats "Top Crashers" list.
You probably want to use "By build date" instead of the default "By report
date" for the next week or so until that settles out.

Presumably the same thing will happen the first week or two of Aurora, on
that channel, and likewise with beta.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 32-bit developer edition?

[Javaun Moradi]

+Clarkbw, who runs Dev Edition.

Expansion of 64 bit was on hold pending the release of 47, where we had some 
critical sandboxing issues fixed and (conveniently) the Widevine CDM also hit 
that timeframe for video support.

It’s an interesting idea to hit developers, who are a bit savvier. We assume 
elimination of small OOM and JS performance gains, security overall will be a 
tradeoff.

We need more users in-field before we start rolling win64 out by default to 
normal people. DevEdition is a potentially compelling hook. We were going to 
offer 64 selectively on the download page to some users in an A/B test to try 
to get numbers up. Ideally, we’d be able to sniff who could run it, since we 
don’t have a stub installer.



> On Jun 3, 2016, at 10:20 AM, Lawrence Mandel  wrote:
> 
> + Javaun who should be able to fill in details about timing and what we want 
> to do with Win64 and why
> 
> On Fri, Jun 3, 2016 at 8:51 AM, Ben Kelly  > wrote:
> On Jun 3, 2016 2:15 AM, "Jet Villegas"  > wrote:
> >
> > We should offer both.
> 
> If we get a net reduction in OOMs with 64-bit it seems to me we should make
> that the default download link.
> 
> In any case, we're not showing a 64-bit link anywhere now.  Who should I
> pester or where should I file a bug to get that fixed?
> 
> Thanks.
> 
> Ben
> ___
> 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: 32-bit developer edition?

[Mike Hoye]

On 2016-06-03 8:51 AM, Ben Kelly wrote:
In any case, we're not showing a 64-bit link anywhere now. Who should 
I pester or where should I file a bug to get that fixed? 

Mozilla.org :: webdev



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

Re: All about crashes

[Andrew McCreight]

On Fri, Jun 3, 2016 at 6:57 AM, Ted Mielczarek  wrote:

> BugHunter[1] attempts to reproduce crashes from crash-stats by loading
> the URLs from the crash reports, which is sometimes successful.
>

Of note, BugHunter also uses both debug and AddressSanitizer builds, which
occasionally turns up some interesting stuff.

Andrew


>
> -Ted
>
> 1. https://wiki.mozilla.org/Auto-tools/Projects/BugHunter
> ___
> 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: 32-bit developer edition?

[Lawrence Mandel]

+ Javaun who should be able to fill in details about timing and what we
want to do with Win64 and why

On Fri, Jun 3, 2016 at 8:51 AM, Ben Kelly  wrote:

> On Jun 3, 2016 2:15 AM, "Jet Villegas"  wrote:
> >
> > We should offer both.
>
> If we get a net reduction in OOMs with 64-bit it seems to me we should make
> that the default download link.
>
> In any case, we're not showing a 64-bit link anywhere now.  Who should I
> pester or where should I file a bug to get that fixed?
>
> Thanks.
>
> Ben
> ___
> 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: All about crashes

[Lars Bergstrom]

On Jun 3, 2016, at 8:53 AM, Ted Mielczarek  wrote:

> On Wed, May 25, 2016, at 10:27 PM, Eric Rescorla wrote:
>> - Making it so that certain kinds of defects still happen but they are
>> safer.
>>  For instance, in C writing dereferencing past the end of an array is
>>  undefined behavior and may well cause something horrible, in Python
>>  you get an exception, which, if not caught, causes program termination.
>>  It's safer in the sense that it's unlikely to cause a security
>> vulnerability,
>>  but it's still a crash.
> 
> Right. There are two main reasons we track and fix crashes:
> 1) They are often a sign of potentially exploitable code, and we don't
> want security holes in our product.
> 2) They create a bad user experience.
> 
> Moving code from C++ to JS or Rust improves our story around #1, since
> it mitigates classes of vulnerabilities, but it still leaves us open to
> #2, where we terminate the app unexpectedly and users are unhappy. I
> think Rust does give us a better story here, since we can safely
> restrict panics to individual threads, and as long as you don't unwrap
> the thread result you don't have to propagate that panic across threads.

To add to #2, restricting panics is a key part of the design of Servo. We work 
pretty hard to ensure that a panic in a single iframe is isolated from the rest 
of the tab so that we can just crash the buggy ad banner, social media widget, 
etc. and hopefully keep the main content acting normally.

Certainly, there are some places where that's hard for us to do (shared tasks 
such as resource loading, only taking down one of several same-origin iframes 
sharing a script task / SM JSRuntime instance, etc.) but we hope that using 
Rust to install backstops a point more fine-grained than the entire tab or 
content process will be a big improvement. It will also be challenging to 
replicate in C++ with the thread-per-tab or process-per-domain models either in 
use or planned in other engines.
- Lars
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: All about crashes

[Robert Strong]

I think that the ADI data comes from the blocklist ping which includes OS
version (possibly Windows service pack as well).

Robert

On Fri, Jun 3, 2016 at 7:02 AM, Ted Mielczarek  wrote:

> On Tue, May 24, 2016, at 04:58 PM, Lawrence Mandel wrote:
> > "Improve ranking of crash clusters."
> >
> > I think this is weighting or estimating impact of a crash instead of
> > volume
> > of submissions, which is how we have historically processed the clusters.
> > Severity is one component with startup crashes being worse than content
> > crashes being worse than shutdown crashes. (Need to figure out weighting
> > of
> > gfx and other buckets of crashes.) Potential impacted population is
> > another
> > and we have data on the differences in population size on Beta vs Release
> > for dimensions like OS version, gfx hardware, and gfx driver to make use
> > of
> > for the weighting.
>
> We currently use ADI data (I don't know where it comes from) to generate
> the chart on the front page of crash-stats.mozilla.com, which is
> "Crashes per 100 Active Daily Installs", which attempts to present an
> overview of how crashy the various release channels are, normalized to
> their usage.
>
> Presumably we could pull more data from Telemetry to get population
> estimates for more specific things, like "number of users running
> release version X on Windows XP". That would certainly be useful input
> for our reporting, where Windows crashes tend to overwhelm everything
> else just by volume.
>
> -Ted
> ___
> 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: All about crashes

[Ted Mielczarek]

On Tue, May 24, 2016, at 04:58 PM, Lawrence Mandel wrote:
> "Improve ranking of crash clusters."
> 
> I think this is weighting or estimating impact of a crash instead of
> volume
> of submissions, which is how we have historically processed the clusters.
> Severity is one component with startup crashes being worse than content
> crashes being worse than shutdown crashes. (Need to figure out weighting
> of
> gfx and other buckets of crashes.) Potential impacted population is
> another
> and we have data on the differences in population size on Beta vs Release
> for dimensions like OS version, gfx hardware, and gfx driver to make use
> of
> for the weighting.

We currently use ADI data (I don't know where it comes from) to generate
the chart on the front page of crash-stats.mozilla.com, which is
"Crashes per 100 Active Daily Installs", which attempts to present an
overview of how crashy the various release channels are, normalized to
their usage.

Presumably we could pull more data from Telemetry to get population
estimates for more specific things, like "number of users running
release version X on Windows XP". That would certainly be useful input
for our reporting, where Windows crashes tend to overwhelm everything
else just by volume.

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

Re: 32-bit developer edition?

[Ben Kelly]

On Jun 3, 2016 2:15 AM, "Jet Villegas"  wrote:
>
> We should offer both.

If we get a net reduction in OOMs with 64-bit it seems to me we should make
that the default download link.

In any case, we're not showing a 64-bit link anywhere now.  Who should I
pester or where should I file a bug to get that fixed?

Thanks.

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

Re: All about crashes

[Ted Mielczarek]

On Wed, May 25, 2016, at 01:47 AM, Eric Rahm wrote:
> Details on using rr to debug crashes would certainly be nice.

In my experience, if a crash is reproducible it's generally
straightforward to fix. rr could be useful if a crash is hard to
reproduce or intermittent, but once a developer can reproduce a crash
we're in the endgame. If a debugger doesn't give enough info, running
Valgrind usually does. The hard part is usually figuring out how to
reproduce a crash from just looking at a crash report.

BugHunter[1] attempts to reproduce crashes from crash-stats by loading
the URLs from the crash reports, which is sometimes successful.

-Ted

1. https://wiki.mozilla.org/Auto-tools/Projects/BugHunter
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: All about crashes

[Ted Mielczarek]

On Wed, May 25, 2016, at 10:27 PM, Eric Rescorla wrote:
> - Making it so that certain kinds of defects still happen but they are
> safer.
>   For instance, in C writing dereferencing past the end of an array is
>   undefined behavior and may well cause something horrible, in Python
>   you get an exception, which, if not caught, causes program termination.
>   It's safer in the sense that it's unlikely to cause a security
> vulnerability,
>   but it's still a crash.

Right. There are two main reasons we track and fix crashes:
1) They are often a sign of potentially exploitable code, and we don't
want security holes in our product.
2) They create a bad user experience.

Moving code from C++ to JS or Rust improves our story around #1, since
it mitigates classes of vulnerabilities, but it still leaves us open to
#2, where we terminate the app unexpectedly and users are unhappy. I
think Rust does give us a better story here, since we can safely
restrict panics to individual threads, and as long as you don't unwrap
the thread result you don't have to propagate that panic across threads.

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

Re: 32-bit developer edition?

[Jet Villegas]

We should offer both.

--Jet

On Thursday, June 2, 2016, Ben Kelly  wrote:

> Hi all,
>
> I noticed recently that all of the available download links for dev edition
> point to the 32-bit installer.  Is there a reason for this?
>
> Given we are talking about how to upgrade existing users to 64-bit it would
> seem good to update the download links for new installs.
>
> Thanks.
>
> Ben
> ___
> 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