Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Nicholas Nethercote]

I apologize for the sarcasm. I was frustrated with this comment:

> I looked at the query from the first post, but it's just noise to me. If it 
> included the file that it
> crashed from, it would suddenly be very useful, since it'd then be trivial to 
> see if there's
> something relevant to me.

but it wasn't a good way to respond. So I'll try again.

Most of the results in the search identify a unique string, which *is*
trivial to look up. And while it's true that file and/or function
names would help refine the small number of cases where distinct
MOZ_CRASH calls, you can also do that with a simple follow-up search
refinement, as I showed in my previous response. The required data is
present. I would describe the presentation as "slightly suboptimal but
still highly usable".

I've looked at a lot of crash reports recently and one thing I've
learned is how inadequate they often are. Many are unactionable. Many
aren't even comprehensible. In comparison, this list is a treasure
trove, containing reports that are much more comprehensible and
actionable than average. It's one which I intend to revisit, and I
hope others will too.

Nick


On Thu, Jun 2, 2016 at 5:22 AM, Jeff Gilbert  wrote:
> It would be useful to have a dashboard that collates this information better.
>
> PS: Sarcasm is unhelpful.
>
> On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote
>  wrote:
>> On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert  wrote:
>>>
>>> Perhaps this isn't meant for me then? I looked at the query from the
>>> first post, but it's just noise to me. If it included the file that it
>>> crashed from, it would suddenly be very useful, since it'd then be
>>> trivial to see if there's something relevant to me.
>>
>> Let's look at the top #3:
>>
>>
>> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
>> 129715  9.92 %
>>
>> If you use your favourite source code search tool to look for
>> "Shutdown too long", you'll find that this crash is occurring in
>> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
>> DXR link:
>>
>> https://dxr.mozilla.org/mozilla-central/search?q=%22Shutdown+too+long%22&redirect=false
>>
>> The line in question looks like this:
>>
>>  MOZ_CRASH("Shutdown too long, probably frozen, causing a crash.");
>>
>>
>> 2  MOZ_CRASH() 25987   1.99 %
>>
>> This one matches all calls to MOZ_CRASH() that don't provide a string
>> parameter. Digging into these ones is slightly harder, requiring a new
>> search for bugs that have "moz crash reason" set to "MOZ_CRASH()":
>>
>> https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%3DMOZ_CRASH%28%29&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-signature
>>
>>
>> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor) 21040.16 %
>>
>> Searching for "working D3D9 Compositor" identifies this one as coming
>> from gfx/layers/d3d9/CompositorD3D9.cpp.
>>
>>
>> And so on. Searching for strings in code is a useful technique in many
>> situations, I recommend it!
>>
>>
>> BTW, thank you to all those who have already looked through the list
>> and mentioned existing bugs and/or filed new bugs.
>>
>> Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

[Jet Villegas]

On Thu, May 26, 2016 at 7:49 PM, Tzu-Hao Kuo  wrote:


> *Link to standard*: No standard. This API was first discussed at Mozlando
> and has been discussed online here(
> https://github.com/w3c/mediacapture-worker/issues/33). The discussion has
> been led to a stream-based design which will probably take a long time so
> we would like to implement the proposed HTMLMediaElement::seekToNextFrame()
> first for testing.
>

 What's the plan for resolving Streams/MediaStream integration raised on
the github issue? I read "probably take a long time" to mean we're working
on it, but is that actually the case? This is a feature we definitely want
interop on.

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

Re: Intent to ship: Canvas CSS/SVG filters

[Jeff Muizelaar]

Can you also get results on Windows?

-Jeff

On Wed, Jun 1, 2016 at 3:05 PM, Tobias Schneider 
wrote:

> I got the following numbers running
> https://dl.dropboxusercontent.com/u/55355076/benchmark.html?filters=true
> on my MacBook Pro (Mid 2014):
>
> Firefox Developer Edition: Skia-GL: 10fps
>   Skia: 3fps
>   CG: 10fps
>   Cairo:8fps
>
> Chrome Canary 53: 3fps
>
>
> On Tue, May 31, 2016 at 11:53 AM, Jeff Muizelaar 
> wrote:
>
>> How does performance compare to Chrome?
>>
>> -Jeff
>>
>> On Thu, May 26, 2016 at 12:40 PM, Tobias Schneider <
>> tschnei...@mozilla.com> wrote:
>>
>>> I intend to turn Canvas CSS/SVG filters on by default on all platforms.
>>> It
>>> has been developed behind the canvas.filters.enabled preference. Google's
>>> Chrome is already shipping this in version 52.
>>>
>>> Related bugs:
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=927892
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1173545
>>>
>>> Specification:
>>>
>>>
>>> https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-filter
>>> ___
>>> 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: Canvas CSS/SVG filters

[Jet Villegas]

I'm surprised to see Skia (which I assume is also Chrome 53's canvas
backend) lagging behind CoreGraphics and even Cairo here. Do we have a bug
to track that down? This is the same code that powers our CSS filters, so a
speedup there should help both canvas and content.

--Jet

On Wed, Jun 1, 2016 at 12:08 PM, Tobias Schneider 
wrote:

> I got the following numbers running
> https://dl.dropboxusercontent.com/u/55355076/benchmark.html?filters=true
> on
> my MacBook Pro (Mid 2014):
>
> Firefox Developer Edition: Skia-GL: 10fps
>   Skia: 3fps
>   CG: 10fps
>   Cairo:8fps
>
> Chrome Canary 53: 3fps
>
>
> On Tue, May 31, 2016 at 11:53 AM, Jeff Muizelaar 
> wrote:
>
> > How does performance compare to Chrome?
> >
> > -Jeff
> >
> > On Thu, May 26, 2016 at 12:40 PM, Tobias Schneider <
> tschnei...@mozilla.com
> > > wrote:
> >
> >> I intend to turn Canvas CSS/SVG filters on by default on all platforms.
> It
> >> has been developed behind the canvas.filters.enabled preference.
> Google's
> >> Chrome is already shipping this in version 52.
> >>
> >> Related bugs:
> >>
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=927892
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1173545
> >>
> >> Specification:
> >>
> >>
> >>
> https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-filter
> >> ___
> >> 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: How badly out of date is this?

[Kris Maglione]

On Wed, Jun 01, 2016 at 11:23:58AM -0400, Kartikaya Gupta wrote:

On Wed, Jun 1, 2016 at 10:06 AM, Mike Hoye  wrote:

On 2016-06-01 5:02 AM, L. David Baron wrote:
So I tend to think it's worth keeping, but with a preface that 
clearly labels it as historical and no longer good practice, and 
perhaps with an appendix pointing to the current practices.


Hey, Sheppy - Should we make a practice of stripping anchor links from 
historical/outdated/archived documentation? On a few occasions I've had 
links drop me into the middle of a document, skipping over the big red 
warning at the top saying "this is old, don't do any of this". I might be 
alone in this, but I suspect I'm not the only person who's lost time because 
of it.


Or make the warning a fixed-position item, so it's on-screen
regardless of where on the page you are.


+1 I've been bitten by this more than once.

I think that archiving the page is a good solution, though. 
Archived content has a different background color, and a striped 
border around all of the article content, so it's not easy to 
miss.

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

Re: How badly out of date is this?

[Chris H-C]

position:fixed can be a usability nightmare on mobile. Here be dragons.

On Wed, Jun 1, 2016 at 11:23 AM, Kartikaya Gupta  wrote:

> Or make the warning a fixed-position item, so it's on-screen
> regardless of where on the page you are.
>
> On Wed, Jun 1, 2016 at 10:06 AM, Mike Hoye  wrote:
> > On 2016-06-01 5:02 AM, L. David Baron wrote:
> >>
> >>
> >> So I tend to think it's worth keeping, but with a preface that
> >> clearly labels it as historical and no longer good practice, and
> >> perhaps with an appendix pointing to the current practices.
> >
> >
> > Hey, Sheppy - Should we make a practice of stripping anchor links from
> > historical/outdated/archived documentation? On a few occasions I've had
> > links drop me into the middle of a document, skipping over the big red
> > warning at the top saying "this is old, don't do any of this". I might be
> > alone in this, but I suspect I'm not the only person who's lost time
> because
> > of it.
> >
> >
> > - mhoye
> >
> > ___
> > 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: Intent to ship: Canvas CSS/SVG filters

[Tobias Schneider]

I got the following numbers running
https://dl.dropboxusercontent.com/u/55355076/benchmark.html?filters=true on
my MacBook Pro (Mid 2014):

Firefox Developer Edition: Skia-GL: 10fps
  Skia: 3fps
  CG: 10fps
  Cairo:8fps

Chrome Canary 53: 3fps


On Tue, May 31, 2016 at 11:53 AM, Jeff Muizelaar 
wrote:

> How does performance compare to Chrome?
>
> -Jeff
>
> On Thu, May 26, 2016 at 12:40 PM, Tobias Schneider  > wrote:
>
>> I intend to turn Canvas CSS/SVG filters on by default on all platforms. It
>> has been developed behind the canvas.filters.enabled preference. Google's
>> Chrome is already shipping this in version 52.
>>
>> Related bugs:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=927892
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1173545
>>
>> Specification:
>>
>>
>> https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-filter
>> ___
>> 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: Service Worker - Offline fallback not working

[Mohit Bajoria]

Just read the same that service workers are served over https and it might
solve my problem :)

Thanks for your help

Regards
Mohit


On 1 June 2016 at 07:45, Andrew Sutherland 
wrote:

> Stack Overflow or other programmer discussion Q&A sites are probably
> better venues for questions like this, such as under the stack overflow
> service-worker tag, see:
> http://stackoverflow.com/questions/tagged/service-worker .  Being able to
> browse the questions and answers of others may also help shed insight on
> your problem.  dev-platform, as described at
> https://www.mozilla.org/en-US/about/forums/#dev-platform, is for
> discussion of the implementation of the underlying functionality in the
> context of Gecko.  I had responded previously because I thought it might be
> a simple thing where having someone else look at it helps and writing these
> "sorry, you're in the wrong place" messages can take a while to write and
> be frustrating to read.
>
> When posting there, I'd suggest being very explicit about the exact
> situation you're testing and what you're expecting in terms of success or
> failure.  For example, seeing that you're using the gh-pages branch, I
> tried accessing the page via the github.io url of
> https://mbj36.github.io/My-Blog/ but that redirected to
> http://mohitbajoria.com/ which, as a non-https origin (and apparently not
> listening on the https port), is not eligible to use service workers at
> all.  That may be your problem, or it could be something else.
>
> It's probably worth experimenting with the devtools on a service-worker
> enabled site such as https://www.pokedex.org/ that is known to work and
> then comparing with your (test) site.  Also, instrumenting your service
> worker with console.log/etc.
>
> Andrew
>
>
> On Tue, May 31, 2016, at 09:45 PM, Mohit Bajoria wrote:
>
> Hello
>
> I added "offline.html" in filesToCache but still the same problem arises.
> When i refresh the page in absence of internet connection "offline.html"
> doesn't show up.
>
> Github project link - https://github.com/mbj36/My-Blog/commits/gh-pages
>
> Please help
> Thanks
> Mohit
>
> On 31 May 2016 at 23:45, Andrew Sutherland 
> wrote:
>
> "offline.html" does not appear to be in filesToCache that is passed to
> cache.addAll().
>
>
> On Mon, May 30, 2016, at 03:02 PM, Mohit Bajoria wrote:
> > Hello
> >
> > There is offline.html page in repository. When there is no internet
> > connection then it should show up reading from cache.
> > Right now it doesn't read from cache and doesn't show up.
> >
> >
> >
> > On 31 May 2016 at 00:20, Ben Kelly  wrote:
> >
> > > On May 30, 2016 1:55 PM, "Mohit Bajoria" 
> wrote:
> > > > Offline fallback event is not working.
> > > > Can anyone please let me know the error and help me solving the
> issue ?
> > >
> > > Can you describe what you expect and what you are actually seeing
> happen?
> > >
> > > There is no "offline fallback event", so not sure exactly what you
> mean.
> > >
> > > 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: Service Worker - Offline fallback not working

[Mohit Bajoria]

Hello

I added "offline.html" in filesToCache but still the same problem arises.
When i refresh the page in absence of internet connection "offline.html"
doesn't show up.

Github project link - https://github.com/mbj36/My-Blog/commits/gh-pages

Please help

Thanks
Mohit

On 31 May 2016 at 23:45, Andrew Sutherland 
wrote:

> "offline.html" does not appear to be in filesToCache that is passed to
> cache.addAll().
>
> On Mon, May 30, 2016, at 03:02 PM, Mohit Bajoria wrote:
> > Hello
> >
> > There is offline.html page in repository. When there is no internet
> > connection then it should show up reading from cache.
> > Right now it doesn't read from cache and doesn't show up.
> >
> >
> >
> > On 31 May 2016 at 00:20, Ben Kelly  wrote:
> >
> > > On May 30, 2016 1:55 PM, "Mohit Bajoria" 
> wrote:
> > > > Offline fallback event is not working.
> > > > Can anyone please let me know the error and help me solving the
> issue ?
> > >
> > > Can you describe what you expect and what you are actually seeing
> happen?
> > >
> > > There is no "offline fallback event", so not sure exactly what you
> mean.
> > >
> > > 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Ted Mielczarek]

On Tue, May 31, 2016, at 09:26 PM, Jeff Gilbert wrote:
> On Tue, May 31, 2016 at 4:39 PM, Nicholas Nethercote
>  wrote:
> > On Wed, Jun 1, 2016 at 1:05 AM, Benjamin Smedberg  
> > wrote:
> >> You shouldn't need to annotate the file/line separately, because that is
> >> (or at least should be!) the top of the stack.
> >
> > Yes. Don't get hung up on the lack of annotations. It isn't much of a
> > problem; you can click through easily enough. I have filed bug 1277104
> > to fix the handful of instances that are showing up in practice, but
> > it'll only be a minor improvement.
> 
> Perhaps this isn't meant for me then? I looked at the query from the
> first post, but it's just noise to me. If it included the file that it
> crashed from, it would suddenly be very useful, since it'd then be
> trivial to see if there's something relevant to me.
> 
> As it stands now, the query alone doesn't seem useful to me. If it's
> meant to be useful to developers who write MOZ_CRASHes, this is a
> problem. If not, please ignore!
> 
> I would be extremely interested in MOZ_CRASHes and friends
> automatically getting bugs filed and needinfo'd. An index of
> crashes-by-file would get half-way there for me.

I believe at some point in the past we talked about trying to do a "top
crashes by bug component" view, but maintaining that mapping was hard.
It turns out that we're storing this data in moz.build files  nowadays
(for example[1]), and we even have a web service on hg.mozilla.org to
expose it for any given revision[2]. Unfortunately that web service is
currently broken[3], but gps tells me he's just been delaying fixing it
because there weren't any consumers complaining.

When the source file from the last frame of the stack used to generate
the signature points to hg.mozilla.org we could query that web service
to get a bug component for the file in question and put that in the
crash report, and expose it to queries. That would make it easy to get
lists of crashes by component, which I think would do what people here
are asking for. I filed bug 1277337 to track this idea.

-Ted

1.
https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/dom/media/moz.build#7
2.
http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/mozbuildinfo.html
3. https://bugzilla.mozilla.org/show_bug.cgi?id=1263973
4. https://bugzilla.mozilla.org/show_bug.cgi?id=1277337
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Jeff Gilbert]

Awesome, this sounds like what I was after. (though actual components
isn't really necessary. If that part is a pain point, I would prefer
to have a tool without it, than to have no tool)

On Wed, Jun 1, 2016 at 12:23 PM, Ted Mielczarek  wrote:
> On Tue, May 31, 2016, at 09:26 PM, Jeff Gilbert wrote:
>> On Tue, May 31, 2016 at 4:39 PM, Nicholas Nethercote
>>  wrote:
>> > On Wed, Jun 1, 2016 at 1:05 AM, Benjamin Smedberg  
>> > wrote:
>> >> You shouldn't need to annotate the file/line separately, because that is
>> >> (or at least should be!) the top of the stack.
>> >
>> > Yes. Don't get hung up on the lack of annotations. It isn't much of a
>> > problem; you can click through easily enough. I have filed bug 1277104
>> > to fix the handful of instances that are showing up in practice, but
>> > it'll only be a minor improvement.
>>
>> Perhaps this isn't meant for me then? I looked at the query from the
>> first post, but it's just noise to me. If it included the file that it
>> crashed from, it would suddenly be very useful, since it'd then be
>> trivial to see if there's something relevant to me.
>>
>> As it stands now, the query alone doesn't seem useful to me. If it's
>> meant to be useful to developers who write MOZ_CRASHes, this is a
>> problem. If not, please ignore!
>>
>> I would be extremely interested in MOZ_CRASHes and friends
>> automatically getting bugs filed and needinfo'd. An index of
>> crashes-by-file would get half-way there for me.
>
> I believe at some point in the past we talked about trying to do a "top
> crashes by bug component" view, but maintaining that mapping was hard.
> It turns out that we're storing this data in moz.build files  nowadays
> (for example[1]), and we even have a web service on hg.mozilla.org to
> expose it for any given revision[2]. Unfortunately that web service is
> currently broken[3], but gps tells me he's just been delaying fixing it
> because there weren't any consumers complaining.
>
> When the source file from the last frame of the stack used to generate
> the signature points to hg.mozilla.org we could query that web service
> to get a bug component for the file in question and put that in the
> crash report, and expose it to queries. That would make it easy to get
> lists of crashes by component, which I think would do what people here
> are asking for. I filed bug 1277337 to track this idea.
>
> -Ted
>
> 1.
> https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/dom/media/moz.build#7
> 2.
> http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/mozbuildinfo.html
> 3. https://bugzilla.mozilla.org/show_bug.cgi?id=1263973
> 4. https://bugzilla.mozilla.org/show_bug.cgi?id=1277337
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Jeff Gilbert]

It would be useful to have a dashboard that collates this information better.

PS: Sarcasm is unhelpful.

On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote
 wrote:
> On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert  wrote:
>>
>> Perhaps this isn't meant for me then? I looked at the query from the
>> first post, but it's just noise to me. If it included the file that it
>> crashed from, it would suddenly be very useful, since it'd then be
>> trivial to see if there's something relevant to me.
>
> Let's look at the top #3:
>
>
> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
> 129715  9.92 %
>
> If you use your favourite source code search tool to look for
> "Shutdown too long", you'll find that this crash is occurring in
> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
> DXR link:
>
> https://dxr.mozilla.org/mozilla-central/search?q=%22Shutdown+too+long%22&redirect=false
>
> The line in question looks like this:
>
>  MOZ_CRASH("Shutdown too long, probably frozen, causing a crash.");
>
>
> 2  MOZ_CRASH() 25987   1.99 %
>
> This one matches all calls to MOZ_CRASH() that don't provide a string
> parameter. Digging into these ones is slightly harder, requiring a new
> search for bugs that have "moz crash reason" set to "MOZ_CRASH()":
>
> https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%3DMOZ_CRASH%28%29&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-signature
>
>
> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor) 21040.16 %
>
> Searching for "working D3D9 Compositor" identifies this one as coming
> from gfx/layers/d3d9/CompositorD3D9.cpp.
>
>
> And so on. Searching for strings in code is a useful technique in many
> situations, I recommend it!
>
>
> BTW, thank you to all those who have already looked through the list
> and mentioned existing bugs and/or filed new bugs.
>
> Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: UTF-16 encoders from the XUL platform

[Henri Sivonen]

UTF-16 encoders are not part of the Web Platform. Therefore, it
doesn't make sense to implement them in a Web-oriented encoding
library that has the Encoding Standard as its conformance target. As a
result, I intend not to add UTF-16 encoders to encoding-rs
(https://github.com/hsivonen/encoding-rs).

As a result, once the time comes to replace uconv with encoding-rs
(see 
https://groups.google.com/d/msg/mozilla.dev.platform/sefrg5Of8tw/_WK7Vtk9AAAJ
), UTF-16 encoders will get removed from the XUL platform as a side
effect.

Note: "Encoders" above means components that output a byte stream for
interchange. It's always a bad idea to use UTF-16 for interchange.
There's still going be support for conversions where the output is an
application-internal sequence of char16_t. (Those are pretty vital to
Gecko!)

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

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

[Eric Shepherd]

This will be great for writing JavaScript code that applies filters or
effects to video, too. Sweet.


> *Summary*: HTMLMediaElement::seekToNextFrame() is an experimental feature
> which enables JS developers to access video frames one-by-one without going
> through the real-time playback. Internally, this feature could could be
> used to writ media tests.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network 
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: Dropping support for VS2013

[Liz Henry (:lizzard)]

Hi Greg and others,

I was just about to raise the issue of performance regression from this
change. If we are aiming this at the 49 release, I would like for us to
improve the situation described in bug 1259923, a 15% performance
regression across all Talos tests covering Windows platforms, which Joel
brought to my attention yesterday.  I don't think we can accept that if it
means a large noticeable slowdown in performance for Windows users in the
release population.   (Even though we really, really want to improve the
toolchain and build time for developers and our own infrastructure.)

Can we put some engineering resources into investigating the test results
and mitigating the perf regression?   15% worse across all Windows tests
should probably block the release. We don't have hard and fast criteria for
what would be an acceptable perf hit.  I think the platform (and probably
product team) should discuss that.

Thanks,

Liz


On Tue, May 31, 2016 at 4:22 PM, Gregory Szorc  wrote:

> Heads up: we'll soon be dropping support for building mozilla-central with
> VS2013. Bug 1186064 tracks and the patch has already received r+.
>
> I'm going to wait a few days before landing because this could be
> disruptive and I want to at least give a heads up before I create a fire.
> Please install VS2015 in the next 48 hours to avoid a surprise the next
> time you pull.
>
> (We've previously recommended everyone install VS2015, so this
> announcement should come as no surprise.)
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>


-- 

Liz Henry (:lizzard)
Firefox Release Manager
lhe...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Milan Sreckovic]

Perhaps we can exercise restraint on doing a wholesale removal of the <10.9 
code, as doing so could make uplifting to 48 and earlier more of a mess.  Maybe 
in a few weeks?
—
- Milan



> On May 31, 2016, at 11:16 , Benjamin Smedberg  wrote:
> 
> Yes.
> 
> --BDS
> 
> On Sun, May 29, 2016 at 6:59 PM, Chris Pearce  wrote:
> 
>> So, given that users won't be able to install Firefox on unsupported
>> versions of MacOSX, and unsupported users won't be upgraded, can we proceed
>> to remove all the nsCocoaFeatures::On[Mountain]LionOrLater() calls in
>> Firefox 49 and just assume everywhere that MacOSX specific Gecko code is
>> running on 10.9 or later?
>> 
>> 
>> 
>> On Fri, May 27, 2016 at 4:59 PM, Ralph Giles  wrote:
>> 
>>> On Thu, May 26, 2016 at 3:37 PM, L. David Baron 
>> wrote:
>>> 
 There's a screenshot in:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
 (which is the bug that made the necessary changes for the Mac OS X
 support change in Firefox 49).
>>> 
>>> Ah, that's great. Thanks!
>>> 
>>> -r
>>> 
>> ___
>> 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

Not sure what you mean - the stack information is there, right?  This is my 
workflow:

Search for all the MOZ_CRASHes (e.g., moz crash reason “exists” (sometimes I 
just search for the graphics reasons, but we don’t have the GFX prefix on all 
the crashes, so that doesn’t quite work all the time)
Look at the top N signatures, pick one that looks like it could be graphics 
related
See what the MOZ_CRASH string is for that particular crash
Search for MOZ_CRASH reason that matches that string.  Just in case it returns 
more than “other reports”
DXR for the MOZ_CRASH reason - this gets me to the current version of the code, 
instead of the version specific one form the crash report itself.

—
- Milan



> On Jun 1, 2016, at 10:13 , Andrew McCreight  wrote:
> 
> On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote > wrote:
> 
>> If you use your favourite source code search tool to look for
>> "Shutdown too long", you'll find that this crash is occurring in
>> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
>> DXR link:
>> 
> 
> Sure, you can individually search for each assertion failure, but that's
> not useful if you are just trying to skim the list looking for assertions
> in code you are familiar with. The crash stack contains file information,
> so it would be nice if that could be exposed somehow in a search. I don't
> think you can do that right now, but I could be wrong.
> 
> Andrew
> ___
> 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: How badly out of date is this?

[Kartikaya Gupta]

Or make the warning a fixed-position item, so it's on-screen
regardless of where on the page you are.

On Wed, Jun 1, 2016 at 10:06 AM, Mike Hoye  wrote:
> On 2016-06-01 5:02 AM, L. David Baron wrote:
>>
>>
>> So I tend to think it's worth keeping, but with a preface that
>> clearly labels it as historical and no longer good practice, and
>> perhaps with an appendix pointing to the current practices.
>
>
> Hey, Sheppy - Should we make a practice of stripping anchor links from
> historical/outdated/archived documentation? On a few occasions I've had
> links drop me into the middle of a document, skipping over the big red
> warning at the top saying "this is old, don't do any of this". I might be
> alone in this, but I suspect I'm not the only person who's lost time because
> of it.
>
>
> - mhoye
>
> ___
> 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

Cairo graphics reports “out of memory” error condition when the author didn’t 
have time to figure out what went wrong.  We caught a few problems that were 
being reported as out of memory (we would pick up the Cairo library error as 
out of memory, and dutifully propagate it up the chain), when they weren’t and 
could be properly handled.

We will also report out of memory when we mean out of resources.  If Direct3D 
library can’t give us what we’re asking for, they will give us the out of 
memory error code, but that doesn’t mean that we are out of memory as such.  We 
could be out of file descriptors or some other resource (or contiguous memory 
on the graphics card.)  We can’t really easily tell these apart, so the best we 
can report is OOM.

I don’t know if there are any other places in our code where this kind of thing 
happens, and I don’t know if we care about the second one, but wanted to point 
out that showing a lot of available “regular” memory would be something that 
would happen in both of the cases I mentioned above.

—
- Milan



> On May 31, 2016, at 19:51 , Nicholas Nethercote  
> wrote:
> 
> On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew  wrote:
>> 
>> I took a quick look at a random one of these OOMs[1], and what strikes me
>> about it is that according to the crash report:
>> 
>>Total Virtual Memory2147352576
>> 
>>Available Virtual Memory122331136
>> 
>>System Memory Use Percentage52
>> 
>>Available Page File 4932567040
>> 
>>Available Physical Memory   1790652416
>> 
>>OOM Allocation Size 24
>> 
>> it seems like the system is still some way from running out of memory.
>> Available Virtual Memory is "only" 122MB, which admittedly isn't very much
>> in present-day terms, but stillwhy can't we successfully allocate a
>> 24-byte block? Can those 122MB really be _so_ fragmented?!
> 
> I looked at a bunch of these yesterday. It's pretty common for OOM to
> occur when there is around 200--250 MiB of available virtual memory;
> 122 MB is probably lower than normal. As bsmedberg said, jemalloc uses
> 1 MiB chunks so the size of 24 is something of a red herring here.
> (It's still useful in the sense that it's tiny, so making this
> allocation fallible is unlikely to be helpful.)
> 
> More generally, I did a search yesterday of all our "OOM | small"
> crashes for the past week. About 5% of them occur when the user has >
> 1 GiB of available virtual memory *and* > 1 GiB of available physical
> memory, which is surprising. I would love to see a scatter plot
> showing available physical memory vs. available virtual memory for all
> our "OOM | small" crashes. bsmedberg, do we have tools to extract that
> kind of data from crash-stats?
> 
> Nick
> ___
> 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Andrew McCreight]

On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote  wrote:

> If you use your favourite source code search tool to look for
> "Shutdown too long", you'll find that this crash is occurring in
> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
> DXR link:
>

Sure, you can individually search for each assertion failure, but that's
not useful if you are just trying to skim the list looking for assertions
in code you are familiar with. The crash stack contains file information,
so it would be nice if that could be exposed somehow in a search. I don't
think you can do that right now, but I could be wrong.

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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Andrew McCreight]

On Mon, May 30, 2016 at 11:22 PM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:

> 6  MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
> collector found more references to an object than its refcount)509
> 0.04 %
>

That's bug 1266882.

15 MOZ_RELEASE_ASSERT(aRefCount != 0) (CCed refcounted object has zero
> refcount)   113 0.01 %
>

That's odd. I'll file a bug on it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How badly out of date is this?

[Mike Hoye]

On 2016-06-01 5:02 AM, L. David Baron wrote:


So I tend to think it's worth keeping, but with a preface that
clearly labels it as historical and no longer good practice, and
perhaps with an appendix pointing to the current practices.


Hey, Sheppy - Should we make a practice of stripping anchor links from 
historical/outdated/archived documentation? On a few occasions I've had 
links drop me into the middle of a document, skipping over the big red 
warning at the top saying "this is old, don't do any of this". I might 
be alone in this, but I suspect I'm not the only person who's lost time 
because of it.



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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Boris Zbarsky]

On 6/1/16 2:32 AM, Nicholas Nethercote wrote:

4  MOZ_CRASH(Unexpected error during FakeBlack creation.)  16790.13 %


This is https://bugzilla.mozilla.org/show_bug.cgi?id=1247977 (credit to 
Milan for noticing that).



49 MOZ_CRASH(Accessing the Subject Principal without an AutoJSAPI on
the stack is forbidden)   7   0.00 %


I looked at these.  One of these was real and got fixed by 
https://bugzilla.mozilla.org/show_bug.cgi?id=1235411


The next six signatures look like a tour of busted vtables or something:


https://crash-stats.mozilla.com/report/index/5edf0db2-44d4-4a00-94b2-89b752160527 
-- shows _moz_cairo_surface_destroy calling 
XPCJSRuntime::InterruptCallback(JSContext*) which then calls 
nsContentUtils::IsCallerChrome().  The latter call makes sense, but the 
former does not.



https://crash-stats.mozilla.com/report/index/95363c0a-bdab-4810-b4be-a07552160526 
-- shows XPCJSRuntime::PrepareForForgetSkippable() calling 
"BRFrame::`scalar deleting destructor'(unsigned int)" calling 
nsGlobalWindow::UnmarkGrayTimers() calling nsXPCComponents_ID::Call 
which does in fact end up touching the subject principal.  But the other 
calls in that stack are bunk.  :(



https://crash-stats.mozilla.com/report/index/a7b5408d-1087-4fe6-914e-5320f2160527 
-- shows mozilla::ipc::MessageChannel::DispatchAsyncMessage calling 
mozilla::dom::SubtleCrypto::Verify calling "@0x10db" calling 
nsContentUtils::SubjectPrincipal.  Still nonsense.  :(



https://crash-stats.mozilla.com/report/index/e981363d-5bd5-4a09-b121-1263c2160527 
-- Shows nsCOMPtr_base::~nsCOMPtr_base calling 
mozilla::dom::StructuredCloneHolder::CustomReadHandler, which is pretty 
darned unlikely, I think.  Apart from that, this stack actually makes 
sense, but that one spot is really going off the rails.



https://crash-stats.mozilla.com/report/index/089ba17c-d2cf-4cc5-bf02-6134b2160530 
-- shows nsImageFrame::GetLogicalSkipSides calling 
nsGenericHTMLElement::Click on this line:


if (nullptr != GetNextInFlow()) {


https://crash-stats.mozilla.com/report/index/95391d22-6236-4397-b694-61c102160527 
-- shows nsIContent::PreHandleEvent calling nsGenericHTMLElement::Click 
on this line:


  nsTArray* destPoints = GetExistingDestInsertionPoints();

Finally, 
https://crash-stats.mozilla.com/report/index/8c472aa1-7eff-409a-b9b0-4abaa2160527 
and 
https://crash-stats.mozilla.com/report/index/8c472aa1-7eff-409a-b9b0-4abaa2160527 
-- the stack is totally sensible, but it should have an AutoJSAPI on the 
stack!  It's coming through nsFrameMessageManager::ReceiveMessage which 
totally uses one (via AutoEntryScript) to get its JSContext.  No idea 
what's going on there.


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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Jonathan Kew]

On 1/6/16 00:51, Nicholas Nethercote wrote:

On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew  wrote:


I took a quick look at a random one of these OOMs[1], and what strikes me
about it is that according to the crash report:

 Total Virtual Memory2147352576

 Available Virtual Memory122331136

 System Memory Use Percentage52

 Available Page File 4932567040

 Available Physical Memory   1790652416

 OOM Allocation Size 24

it seems like the system is still some way from running out of memory.
Available Virtual Memory is "only" 122MB, which admittedly isn't very much
in present-day terms, but stillwhy can't we successfully allocate a
24-byte block? Can those 122MB really be _so_ fragmented?!


I looked at a bunch of these yesterday. It's pretty common for OOM to
occur when there is around 200--250 MiB of available virtual memory;
122 MB is probably lower than normal.


Does this suggest that we're not sufficiently proactive about firing 
memory-pressure notifications, so that we'll free up memory from various 
caches, etc? It looks like we regard 128MB of available VM as "low" (see 
[1]) on Windows 32-bit, but apparently we're liable to suffer small-OOM 
crashes well before we reach that point. That doesn't seem like a 
healthy balance.


JK


[1] 
https://dxr.mozilla.org/mozilla-central/source/xpcom/base/AvailableMemoryTracker.cpp#497-498


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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Josh Matthews]

On 2016-06-01 2:32 AM, Nicholas Nethercote wrote:

37 MOZ_RELEASE_ASSERT(aInAndOutListener) (can not perform CORS checks
without a listener)  23  0.00 %


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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Nicholas Nethercote]

Here's an update. This one is bug 1235183:

> 7  MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 %

This one is covered by bug 616421 (the signature includes a
combination of MOZ_CRASHes and other kinds of crashes):

> 8  MOZ_CRASH(Bogus tree op)459 0.04 %

Below are all the ones that don't have a bug associated with them, as
determined from replies to this thread.

Nick


> 4  MOZ_CRASH(Unexpected error during FakeBlack creation.)  16790.13 %
> 5  MOZ_CRASH(IPC FatalError in the parent process!)783 0.06 %
> 6  MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
> collector found more references to an object than its refcount)509
> 0.04 %
> 13 MOZ_RELEASE_ASSERT(NS_IsMainThread())   131 0.01 %
> 14 MOZ_RELEASE_ASSERT(aMsg.priority() ==
> IPC::Message::PRIORITY_NORMAL)120 0.01 %
> 15 MOZ_RELEASE_ASSERT(aRefCount != 0) (CCed refcounted object has zero
> refcount)   113 0.01 %
> 16 MOZ_RELEASE_ASSERT(!mAudio.HasPromise()) (No duplicate sample
> requests) 110 0.01 %
> 17 MOZ_RELEASE_ASSERT(ok)  105 0.01 %
> 19 MOZ_CRASH(invalid process aSelector)73  0.01 %
> 20 MOZ_CRASH(We lost the following char message)   58  0.00 %
> 21 MOZ_CRASH(Unhandlable OOM while clearing document dependent slots.)
> 53  0.00 %
> 23 MOZ_RELEASE_ASSERT(prio == IPC::Message::PRIORITY_NORMAL ||
> NS_IsMainThread())  51  0.00 %
> 24 MOZ_CRASH(GFX: Failed to update reference draw target after device
> reset)   45  0.00 %
> 25 MOZ_RELEASE_ASSERT(isSystem)42  0.00 %
> 26 MOZ_CRASH(Crash creating texture. See bug 1221348.) 41  0.00 %
> 27 MOZ_CRASH(sandbox_init() failed)41  0.00 %
> 28 MOZ_CRASH(Unable to get a working D3D9 Compositor)  37  0.00 %
> 29 MOZ_CRASH(GFX: Invalid D3D11 content device)33  0.00 %
> 30 MOZ_CRASH(Initial length is too large)  30  0.00 %
> 32 MOZ_CRASH(IPC message size is too large)25  0.00 %
> 33 MOZ_RELEASE_ASSERT(mWorkerLoopID == MessageLoop::current()->id())
> (not on worker thread!)   25  0.00 %
> 34 MOZ_RELEASE_ASSERT(!mInWriteTransaction)24  0.00 %
> 35 MOZ_CRASH(NativeKey tries to dispatch a key event on destroyed
> widget)  23  0.00 %
> 36 MOZ_RELEASE_ASSERT(((bool)(!!(!NS_FAILED_impl(rv && thread)
> (Should successfully create image decoding threads) 23  0.00 %
> 37 MOZ_RELEASE_ASSERT(aInAndOutListener) (can not perform CORS checks
> without a listener)  23  0.00 %
> 38 MOZ_CRASH(Unknown unit type?)   18  0.00 %
> 40 MOZ_RELEASE_ASSERT(msg->size() < IPC::Channel::kMaximumMessageSize)
> 17  0.00 %
> 41 MOZ_RELEASE_ASSERT(!r.IsEmpty())14  0.00 %
> 42 MOZ_RELEASE_ASSERT(!r->IsEmpty())   13  0.00 %
> 43 MOZ_RELEASE_ASSERT(CheckDocTree())  12  0.00 %
> 44 MOZ_RELEASE_ASSERT(mDestroyCalled)  11  0.00 %
> 45 MOZ_RELEASE_ASSERT(!!compositor)10  0.00 %
> 46 MOZ_RELEASE_ASSERT(MessageLoop::current() == mWorkerLoop)   10
> 0.00 %
> 47 MOZ_RELEASE_ASSERT(sDebugOwningThread != currentThread) 10
> 0.00 %
> 48 MOZ_RELEASE_ASSERT(SizeOfEntryStore(CapacityFromHashShift(),
> mEntrySize, &nbytes))  8   0.00 %
> 49 MOZ_CRASH(Accessing the Subject Principal without an AutoJSAPI on
> the stack is forbidden)   7   0.00 %
> 50 MOZ_CRASH(Initial entry store size is too large)7   0.00 %
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How badly out of date is this?

[L. David Baron]

On Tuesday 2016-05-31 23:59 -0400, Eric Shepherd wrote:
> Found myself looking at this page today, which is now labeled as
> potentially obsolete due to not having undergone any substantial changes
> in many years. Could someone please look it over and let me know if it's
> worth keeping or salvageable at least?
> 
> https://developer.mozilla.org/en-US/docs/Modularization_Techniques
> 
> If it's worth keeping, I'll move it to the Mozilla documentation area.
> If not, the archival area.

I think it's not salvageable in the sense of being turned into
documentation that tells people what they ought to be doing.  Almost
all of the things it recommends are poor practice today because we
have macros or other helpers that do them in much simpler (and in
some cases also more efficient) ways.

However, I think it's historically quite interesting for people
trying to understand how XPCOM works, because it shows the basic
pieces of the XPCOM component model and how they can be implemented
(but probably shouldn't be anymore) in a nice and simple way, before
they were obscured by lots of macros, and by lots of performance and
code size optimizations hidden underneath even more macros.

So I tend to think it's worth keeping, but with a preface that
clearly labels it as historical and no longer good practice, and
perhaps with an appendix pointing to the current practices.

-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