Re: One Firefox repository to rule them all

[Eric Shepherd]

For what it's worth it would be an absolute game changer for the
developer docs team. I already commented that having the unified repo is
a big deal, but having it go all the way to the beginning would rock our
worlds.

Having to wade through by hand and basically do a manual binary search
to figure out which release a change took place in can take a lot of our
time. If we could get this all in one place -- holy cow, I would be
bursting with happy sparkly rainbow kittens!


> No. Adding a Mercurial repo with CVS history isn't on the priority
> list. Make a case for it improving developer productivity and it could
> be. 

-- 

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: One Firefox repository to rule them all

[Eric Shepherd]

Yes, this is how I feel too, but anything that gets all revisions in one
place would be a huge win for us.


> For me, having the CVS history in the mozilla-central repo

-- 

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: One Firefox repository to rule them all

[Eric Shepherd]

This has potential to be a Huge Deal for the MDN content team, too.
Figuring out when things were added or removed or changed can be hard
across so many repositories.


> I'm pleased to announce the immediate availability of some
> *experimental* read-only Mercurial repositories containing the
> combined, useful history of the various Firefox repositories, all in
> chronological order and stored in a more efficient format that is
> faster to clone and pull from and results in faster client operations.
>
> The repositories can be found at https://hg.mozilla.org/experimental.
> The repository you likely want to clone is
> https://hg.mozilla.org/experimental/firefox-unified. A visualization
> showing the chronological history of the repo can be seen at
> https://hg.mozilla.org/experimental/firefox-unified/graph.
>
> The primary goal of these repositories is to provide developers (and
> eventually automation) with more efficient interaction with the
> Firefox source repositories. There are several secondary and
> side-benefits, including improving the scalability of Try and
> MozReview's repositories.

-- 

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: Intent to deprecate: MacOS 10.6-10.8 support

[Chris Peterson]

On 5/2/16 5:18 PM, Gregory Szorc wrote:

On Mon, May 2, 2016 at 5:12 PM, Chris Peterson 
wrote:


On 5/2/16 4:10 PM, Gregory Szorc wrote:


So where does that leave us on Universal OS X builds? IIRC our blocker is
the need to support 32-bit Silverlight in the plugin container so various
streaming services using it don't break. Where are we on that front?
(Reminder: killing Universal OS X packages will make automation builds
significantly faster and will reduce the DMG size by almost half.)



I don't know the status of 32-bit Silverlight on OS X, but we're shipping
Widevine support in Firefox 47 (for Windows 7+ and OS X 10.6+). Streaming
services will have an easy migration path from Silverlight to their
existing Widevine player code.

That said, I don't expect the long-tail of streaming services to complete
this transition before the end of 2016, when we already plan to drop NPAPI
plugins.



Fair enough.

So what's the last Firefox release to support NPAPI plugins? 50? 51?


We're tentatively planning to remove NPAPI support (for plugins other 
than Flash) in 53 because 52 is the next ESR. We'd like ESR 52 to 
support NPAPI as a transition option for enterprise users that rely on Java.


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

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Jeff Walden]

On 04/30/2016 01:26 PM, L. David Baron wrote:
> I still find it sad that ECMAScript Intl came (as I understand it)
> very close to just standardizing on a piece of software (ICU)

I'm fuzzy on the details as well, but I don't believe it was ever going to be 
the case that the spec would be "do what ICU does". Language *had* to be 
hand-wavy, because what is the custom in one language now, will not always be 
the custom. So some flexibility must be granted to accommodate this, as well as 
to not (in effect) specify entire languages as they exist right now.

Now, in *practice* it might work out that behaviors would be what ICU does. But 
even there I'm not so sure about it. What ICU does, as I understand it, is 
approximately only what CLDR (all the language/locale-specific information 
about formatting, pluralization, word-breaking, etc.), plus standardized things 
like IETF BCP 47, tells it to. And CLDR's purview is not really areas where 
technical debate/disagreement/dissent makes a whole lot of sense, because it's 
just setting down what the rest of the world does.

In any event, the "doomsday" scenario did not occur, so we're safe.

> and also find it disturbing that we're going to extend that
> standardization on a particular piece of software (possibly even
> more rigidly) into other areas.

Using a library to do certain things we do other ways right now, in sometimes 
inferior fashion, doesn't seem inherently objectionable to me. So long as the 
library's internal decisions don't bleed too far into the visible API, which I 
don't believe they did here.

> I think many of the arguments we
> made against standardizing on SQLite seem to apply to ICU as well,
> such as security risk and needing to reverse-engineer when writing
> future implementations of parts of the Web platform.

I believe this should be mitigated by its being CLDR that will be the true 
dependency, and CLDR not containing anything but the most highly constrained of 
"algorithms" (for things like pluralization). But I'm happy to be 
corrected/enlightened by someone who understands ICU/CLDR better.

> I think enough of our users are on Windows XP that decisions about
> dropping Windows XP are not a purely engineering decision.

Unfortunately I agree.

Jeff
___
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

[Chris Peterson]

On 5/2/16 4:10 PM, Gregory Szorc wrote:

So where does that leave us on Universal OS X builds? IIRC our blocker is
the need to support 32-bit Silverlight in the plugin container so various
streaming services using it don't break. Where are we on that front?
(Reminder: killing Universal OS X packages will make automation builds
significantly faster and will reduce the DMG size by almost half.)


I don't know the status of 32-bit Silverlight on OS X, but we're 
shipping Widevine support in Firefox 47 (for Windows 7+ and OS X 10.6+). 
Streaming services will have an easy migration path from Silverlight to 
their existing Widevine player code.


That said, I don't expect the long-tail of streaming services to 
complete this transition before the end of 2016, when we already plan to 
drop NPAPI plugins.

___
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

[Gregory Szorc]

On Mon, May 2, 2016 at 4:10 PM, Gregory Szorc  wrote:

> On Mon, May 2, 2016 at 3:51 PM, Lawrence Mandel 
> wrote:
>
>> On Mon, May 2, 2016 at 2:28 PM, Ralph Giles  wrote:
>>
>> > On Fri, Apr 29, 2016 at 9:52 PM, Lawrence Mandel 
>> > wrote:
>> >
>> > > I had planned to update the thread after the post went live so that I
>> had
>> > > the link. Thank you for posting it.
>> >
>> > The blog post just says "August 2016". Firefox 48 is scheduled for
>> > release August 2. Can you confirm that means we can start removing
>> > 10.6-10.8 support in mozilla-central now, which will be Firefox 49?
>> >
>>
>> Yes. Confirmed.
>>
>
> \o/
>
> So this presumably means we can turn off automation running on 10.6-10.8
> on mozilla-central? I believe that will drastically increase our OS X
> automation capacity...
>

I filed bug 1269542 to remove 10.6-10.8 jobs from tier-1 and bug 1269543 to
remove the jobs from automation scheduling.


>
> So where does that leave us on Universal OS X builds? IIRC our blocker is
> the need to support 32-bit Silverlight in the plugin container so various
> streaming services using it don't break. Where are we on that front?
> (Reminder: killing Universal OS X packages will make automation builds
> significantly faster and will reduce the DMG size by almost half.)
>
>
___
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

[Ralph Giles]

On Mon, May 2, 2016 at 4:10 PM, Gregory Szorc  wrote:

> So this presumably means we can turn off automation running on 10.6-10.8 on
> mozilla-central? I believe that will drastically increase our OS X
> automation capacity...

Yes, please. We can't take advantage of any of the engineering
benefits until we stop gating builds on tests passing on 10.6.

> So where does that leave us on Universal OS X builds? IIRC our blocker is
> the need to support 32-bit Silverlight in the plugin container so various
> streaming services using it don't break. Where are we on that front?

Mac has EME-based support for DMCA-protected video starting in Firefox
47[1], so there's an alternative to Silverlight for those sites. There
are other uses of course, but we have previously announced an end to
native NPAPI plugins at the end of 2016[2] so I think that's the
timeframe for dropping 32-bit mac support. If we want to make progress
in the meantime we should start doing separate 64-bit only builds, and
use the update process to transition users on Mac > 10.6 who don't
have 32-bit plugins to the new 64-bit builds.

[1] 
https://blog.mozilla.org/futurereleases/2016/04/08/mozilla-to-test-widevine-cdm-in-firefox-nightly/
[2] https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Jeff Walden]

On 04/29/2016 08:30 AM, sn...@snorp.net wrote:
> The engineers in Platform consistently want to dismiss mobile-specific 
> issues, and this is a great example. If you really want to get ICU into 
> Fennec, find a way to do it without bloating the APK size instead of bullying 
> the Fennec folks.

Your point is taken, modulo quibbling (that some might characterize more 
strongly).  Not all size questions should be/are viewed alike by Platform or 
even by individual engineers.  For example, I heard about a recent 
few-hundred-K hit purely for quality of service, which seemed a bit much to me 
and you both.  (Deliberately not saying whodunit.)  But okay.

DOM features rarely die, so there's a limit to how much code we can remove.  
And web developers (and by extension end users visiting their sites) expect 
browsers to do increasingly many things, so we must continue adding code.  Intl 
isn't special; it's just one new feature of many (albeit one with fundamentally 
irreducible complexity, human communication being beyond the control even of 
web standards bodies, let alone us).  This story will never change with Gecko.

But we can't fully serve developers with the stagnating system-based engine.  
It'll be difficult to impossible to offer new layout/rendering features, new 
DOM features, hypothetical browser-integration improvements into existing 
features, new JS features that aren't standard library additions, or new JS 
standard library additions *that are optimally fast in JITs*.  It'll be 
functionally impossible to affect the development of standards having 
particular (or perhaps sole) importance on mobile, using an uncontrollable 
rendering engine.  Yet another browser shell does not promote "choice and 
innovation on the Internet", especially so on mobile where increasingly more 
browsing occurs now.

Gecko, like any big codebase, has flab.  I can't estimate how much.  But 
there's practically zero possibility it has flab matching the numbers suggested 
in , implicitly 
desiring a 50%+ size reduction, no matter how far Platform bends over backward, 
or how cooperative Platform engineers are.

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

Re: One Firefox repository to rule them all

[Gregory Szorc]

On Fri, Apr 15, 2016 at 7:16 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:

> This is really cool!
>
> Though I much prefer firefoxtree's namespace updating to keep track of
> remote heads over using bookmarks. I want a label that will always point
> to the last known head on the server, so e.g
> `hg update central && hg commit -m "Foo"` should not move 'central'.
> Using bookmarks to track the remote heads is also incompatible with my
> bookbinder extension which I've come to rely quite heavily on. This
> would be a personal blocker for me to make the switch.
>
> Maybe firefoxtree could be adapted to work with this new repo as well.
> Or maybe I could look into doing something with remotenames.
>

When pulling from these experimental repos with the latest version of
firefoxtree, the bookmarks on these repos will be converted to
firefoxtree's special namespace and local bookmarks matching what were
formally pulled from these repos will be deleted. i.e. it works just like
firefoxtree does with the canonical repos which don't have bookmarks.

You will need firefoxtree from version-control-tools as of about ~15
minutes ago to get this new feature.


>
>
>
>
> On 14/04/16 08:22 PM, Gregory Szorc wrote:
>
>> I'm pleased to announce the immediate availability of some *experimental*
>> read-only Mercurial repositories containing the combined, useful history
>> of
>> the various Firefox repositories, all in chronological order and stored in
>> a more efficient format that is faster to clone and pull from and results
>> in faster client operations.
>>
>> The repositories can be found at https://hg.mozilla.org/experimental. The
>> repository you likely want to clone is
>> https://hg.mozilla.org/experimental/firefox-unified. A visualization
>> showing the chronological history of the repo can be seen at
>> https://hg.mozilla.org/experimental/firefox-unified/graph.
>>
>> The primary goal of these repositories is to provide developers (and
>> eventually automation) with more efficient interaction with the Firefox
>> source repositories. There are several secondary and side-benefits,
>> including improving the scalability of Try and MozReview's repositories.
>>
>> More documentation about these repos is available at [1]. tl;dr
>>
>> * The repositories contain all the commits from the Firefox repositories
>> you use everyday (central, inbound, fx-team, aurora, beta, esr, etc).
>> * The repositories do not contain all the *_RELBRANCH branches (which
>> basically have no value to the average developer).
>> * Thes unified repositories are ~300MB *smaller* than mozilla-central
>> despite containing ~28,000 more commits. This was achieved through light
>> magic.
>> * Mercurial bookmarks are used to track the heads of the various Firefox
>> repos.
>> * The pushlog data is derived from the first known push of a changeset, so
>> it should match what's on e.g. central, inbound, etc.
>> * Sadly, git-cinnabar won't be able to talk to these repos just yet due to
>> git-cinnabar not supporting some modern Mercurial features. A GitHub issue
>> is on file at [2].
>>
>> If you use the "firefoxtree" extension to manage a unified repository
>> today, you should consider switching to one of these new unified
>> repositories instead: it should be faster and easier to reason about.
>>
>> The repositories have the "experimental" label attached so we can reserve
>> the right to make changes without people complaining too loudly about
>> backwards compatibility. (But I wouldn't worry too much about stability -
>> I'm committed to keeping these running and improving them.) The goal is to
>> flush out issues with these repositories then remove the "experimental"
>> label. After that, we can have automation start consuming these
>> repositories. After that, we can perhaps start thinking about
>> consolidating
>> around a single, canonical repository, including pushing. But that's a
>> topic for another day.
>>
>> I'm very anxious for feedback on these repositories. Please make noise in
>> dev-version-cont...@lists.mozilla.org, #vcs, the "Developer Services:
>> Mercurial: hg.mozilla.org" bug component, or in bug 1108729.
>>
>> [1]
>>
>> https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
>> [2] https://github.com/glandium/git-cinnabar/issues/64
>>
>>
>
___
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

[Gregory Szorc]

On Mon, May 2, 2016 at 3:51 PM, Lawrence Mandel  wrote:

> On Mon, May 2, 2016 at 2:28 PM, Ralph Giles  wrote:
>
> > On Fri, Apr 29, 2016 at 9:52 PM, Lawrence Mandel 
> > wrote:
> >
> > > I had planned to update the thread after the post went live so that I
> had
> > > the link. Thank you for posting it.
> >
> > The blog post just says "August 2016". Firefox 48 is scheduled for
> > release August 2. Can you confirm that means we can start removing
> > 10.6-10.8 support in mozilla-central now, which will be Firefox 49?
> >
>
> Yes. Confirmed.
>

\o/

So this presumably means we can turn off automation running on 10.6-10.8 on
mozilla-central? I believe that will drastically increase our OS X
automation capacity...

So where does that leave us on Universal OS X builds? IIRC our blocker is
the need to support 32-bit Silverlight in the plugin container so various
streaming services using it don't break. Where are we on that front?
(Reminder: killing Universal OS X packages will make automation builds
significantly faster and will reduce the DMG size by almost half.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Andrew McKay]

I agree, let's just leave its name as it is for now.

On Mon, May 2, 2016 at 3:54 PM, Matthew N.
 wrote:
> On Mon, May 2, 2016 at 3:43 PM, Emma Humphries  wrote:
>>
>> Andrew, can you do a pass over the bugs since Jan 1st and, and let's
>> rename this FFx::Add Ons Compatablity so that it's clear it's not plugins.
>
>
> Extensions and plugins are both types of add-ons so renaming makes it less
> clear as it then includes plugins and themes.
>
___
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

[Lawrence Mandel]

On Mon, May 2, 2016 at 2:28 PM, Ralph Giles  wrote:

> On Fri, Apr 29, 2016 at 9:52 PM, Lawrence Mandel 
> wrote:
>
> > I had planned to update the thread after the post went live so that I had
> > the link. Thank you for posting it.
>
> The blog post just says "August 2016". Firefox 48 is scheduled for
> release August 2. Can you confirm that means we can start removing
> 10.6-10.8 support in mozilla-central now, which will be Firefox 49?
>

Yes. Confirmed.

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

Re: Changes to bugzilla "plugins" product

[Emma Humphries]

Andrew, can you do a pass over the bugs since Jan 1st and, and let's rename
this FFx::Add Ons Compatablity so that it's clear it's not plugins.

On Mon, May 2, 2016 at 2:56 PM, Andrew McKay  wrote:

> Looks like that would fall on me. After a quick look at some of the
> bugs, its seems like its a holding pen for bugs that need to be passed
> on to other areas or back to the add-on developer themselves (which
> often means closing them).
>
> On Mon, May 2, 2016 at 2:01 PM, Emma Humphries  wrote:
> > Pasting what I mentioned in #fx-team
> >
> >
> > Regarding FFx::Extension Compatibility componen
> > t.
> > 702 bugs total, 282 of which are not marked against a particular version
> > . There are
> > 11 in FFx 44, 10 in FFx 45, 9 in FFx 46, 7 in FFx 47, 3 in FFx 48
> > ,
> > 1 tracking FFx 47
> > ,
> > and only 44 bugs since the first of the year
> >
> > I'd like to get those into the right component, and make a decision
> > on disposing
> > of
> > the rest?
> >
> > --
> > Emma
> >
> >
> >
> > On Mon, May 2, 2016 at 1:37 PM, Emma Humphries  wrote:
> >>
> >> Let me take a look at those.
> >>
> >> On Mon, May 2, 2016 at 1:01 PM, Justin Dolske 
> wrote:
> >>>
> >>> Will Firefox :: Extension Compatibility also be rolled into this new ::
> >>> Other component?
> >>>
> >>> (There are ~700 open bugs there still, most of which look pretty
> stale.)
> >>>
> >>> Justin
> >>>
> >>> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg
> >>>  wrote:
> 
>  There used to be a bugzilla.mozilla.org product called "Plugins".
> This
>  product has been renamed "External Software Affecting Firefox" and its
>  component structure has been greatly simplified.
> 
>  It is usually not helpful to track defects in 3rd-party software in
> the
>  Mozilla bug tracker. The only time we want to track those defects is
> when we
>  want to make explicit outreach efforts because those defects affect
> Firefox
>  users.
> 
>  There were previously almost a hundred different "components" for fine
>  classification of these bugs. This was not producing good results and
> caused
>  confusion for many people filing bugs. So I've asked for most of these
>  components to be retired, and now there will be just three components:
> 
>  "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
>  working with Adobe when necessary.
>  "OpenH264" - I believe Maire Reavy's team triages this component for
>  bugs that affect our deployment of OpenH264 with Cisco.
>  "Other" - For defects in basically all other 3rd-party software,
>  including other NPAPI and GMP plugins, Firefox extensions, and other
>  software such as antivirus tools, that may affect Firefox. I am
> triaging
>  these bugs as necessary.
> 
>  --BDS
> 
>  ___
>  firefox-dev mailing list
>  firefox-...@mozilla.org
>  https://mail.mozilla.org/listinfo/firefox-dev
> 
> >>>
> >>>
> >>> ___
> >>> firefox-dev mailing list
> >>> firefox-...@mozilla.org
> >>> https://mail.mozilla.org/listinfo/firefox-dev
> >>>
> >>
> >
> >
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Emma Humphries]

MattN mentioned there's also a "Tech Evangelism :: Addons" which is for
bugs from add-ons where we aren't going to change anything in the product
but we may contact the author or blog about the addon-compatablty change. I
need to see how busy that one is (I would imagine that it it's being used
for e10s related changes?)

-- Emma

On Mon, May 2, 2016 at 2:56 PM, Andrew McKay  wrote:

> Looks like that would fall on me. After a quick look at some of the
> bugs, its seems like its a holding pen for bugs that need to be passed
> on to other areas or back to the add-on developer themselves (which
> often means closing them).
>
> On Mon, May 2, 2016 at 2:01 PM, Emma Humphries  wrote:
> > Pasting what I mentioned in #fx-team
> >
> >
> > Regarding FFx::Extension Compatibility componen
> > t.
> > 702 bugs total, 282 of which are not marked against a particular version
> > . There are
> > 11 in FFx 44, 10 in FFx 45, 9 in FFx 46, 7 in FFx 47, 3 in FFx 48
> > ,
> > 1 tracking FFx 47
> > ,
> > and only 44 bugs since the first of the year
> >
> > I'd like to get those into the right component, and make a decision
> > on disposing
> > of
> > the rest?
> >
> > --
> > Emma
> >
> >
> >
> > On Mon, May 2, 2016 at 1:37 PM, Emma Humphries  wrote:
> >>
> >> Let me take a look at those.
> >>
> >> On Mon, May 2, 2016 at 1:01 PM, Justin Dolske 
> wrote:
> >>>
> >>> Will Firefox :: Extension Compatibility also be rolled into this new ::
> >>> Other component?
> >>>
> >>> (There are ~700 open bugs there still, most of which look pretty
> stale.)
> >>>
> >>> Justin
> >>>
> >>> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg
> >>>  wrote:
> 
>  There used to be a bugzilla.mozilla.org product called "Plugins".
> This
>  product has been renamed "External Software Affecting Firefox" and its
>  component structure has been greatly simplified.
> 
>  It is usually not helpful to track defects in 3rd-party software in
> the
>  Mozilla bug tracker. The only time we want to track those defects is
> when we
>  want to make explicit outreach efforts because those defects affect
> Firefox
>  users.
> 
>  There were previously almost a hundred different "components" for fine
>  classification of these bugs. This was not producing good results and
> caused
>  confusion for many people filing bugs. So I've asked for most of these
>  components to be retired, and now there will be just three components:
> 
>  "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
>  working with Adobe when necessary.
>  "OpenH264" - I believe Maire Reavy's team triages this component for
>  bugs that affect our deployment of OpenH264 with Cisco.
>  "Other" - For defects in basically all other 3rd-party software,
>  including other NPAPI and GMP plugins, Firefox extensions, and other
>  software such as antivirus tools, that may affect Firefox. I am
> triaging
>  these bugs as necessary.
> 
>  --BDS
> 
>  ___
>  firefox-dev mailing list
>  firefox-...@mozilla.org
>  https://mail.mozilla.org/listinfo/firefox-dev
> 
> >>>
> >>>
> >>> ___
> >>> firefox-dev mailing list
> >>> firefox-...@mozilla.org
> >>> https://mail.mozilla.org/listinfo/firefox-dev
> >>>
> >>
> >
> >
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Andrew McKay]

Looks like that would fall on me. After a quick look at some of the
bugs, its seems like its a holding pen for bugs that need to be passed
on to other areas or back to the add-on developer themselves (which
often means closing them).

On Mon, May 2, 2016 at 2:01 PM, Emma Humphries  wrote:
> Pasting what I mentioned in #fx-team
>
>
> Regarding FFx::Extension Compatibility componen
> t.
> 702 bugs total, 282 of which are not marked against a particular version
> . There are
> 11 in FFx 44, 10 in FFx 45, 9 in FFx 46, 7 in FFx 47, 3 in FFx 48
> ,
> 1 tracking FFx 47
> ,
> and only 44 bugs since the first of the year
>
> I'd like to get those into the right component, and make a decision
> on disposing
> of
> the rest?
>
> --
> Emma
>
>
>
> On Mon, May 2, 2016 at 1:37 PM, Emma Humphries  wrote:
>>
>> Let me take a look at those.
>>
>> On Mon, May 2, 2016 at 1:01 PM, Justin Dolske  wrote:
>>>
>>> Will Firefox :: Extension Compatibility also be rolled into this new ::
>>> Other component?
>>>
>>> (There are ~700 open bugs there still, most of which look pretty stale.)
>>>
>>> Justin
>>>
>>> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg
>>>  wrote:

 There used to be a bugzilla.mozilla.org product called "Plugins". This
 product has been renamed "External Software Affecting Firefox" and its
 component structure has been greatly simplified.

 It is usually not helpful to track defects in 3rd-party software in the
 Mozilla bug tracker. The only time we want to track those defects is when 
 we
 want to make explicit outreach efforts because those defects affect Firefox
 users.

 There were previously almost a hundred different "components" for fine
 classification of these bugs. This was not producing good results and 
 caused
 confusion for many people filing bugs. So I've asked for most of these
 components to be retired, and now there will be just three components:

 "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
 working with Adobe when necessary.
 "OpenH264" - I believe Maire Reavy's team triages this component for
 bugs that affect our deployment of OpenH264 with Cisco.
 "Other" - For defects in basically all other 3rd-party software,
 including other NPAPI and GMP plugins, Firefox extensions, and other
 software such as antivirus tools, that may affect Firefox. I am triaging
 these bugs as necessary.

 --BDS

 ___
 firefox-dev mailing list
 firefox-...@mozilla.org
 https://mail.mozilla.org/listinfo/firefox-dev

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

Re: Changes to bugzilla "plugins" product

[Emma Humphries]

​Pasting what I mentioned in #fx-team​


Regarding FFx::Extension Compatibility componen
​t.
​
702 bugs total, 282 of which are not marked against a particular version
​. There are ​
11 in FFx 44, 10 in FFx 45, 9 in FFx 46, 7 in FFx 47, 3 in FFx 48
​, ​
1 tracking FFx 47
​, ​
and only 44 bugs since the first of the year

I'd like to get those into the right component, and make a decision
​ on disposing ​
​of ​
the rest?

--
​ Emma​



On Mon, May 2, 2016 at 1:37 PM, Emma Humphries  wrote:

> Let me take a look at those.
>
> On Mon, May 2, 2016 at 1:01 PM, Justin Dolske  wrote:
>
>> Will Firefox :: Extension Compatibility also be rolled into this new ::
>> Other component?
>>
>> (There are ~700 open bugs there still, most of which look pretty stale.)
>>
>> Justin
>>
>> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg > > wrote:
>>
>>> There used to be a bugzilla.mozilla.org product called "Plugins". This
>>> product has been renamed "External Software Affecting Firefox" and its
>>> component structure has been greatly simplified.
>>>
>>> It is usually not helpful to track defects in 3rd-party software in the
>>> Mozilla bug tracker. The only time we want to track those defects is when
>>> we want to make explicit outreach efforts because those defects affect
>>> Firefox users.
>>>
>>> There were previously almost a hundred different "components" for fine
>>> classification of these bugs. This was not producing good results and
>>> caused confusion for many people filing bugs. So I've asked for most of
>>> these components to be retired, and now there will be just three components:
>>>
>>> "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
>>> working with Adobe when necessary.
>>> "OpenH264" - I believe Maire Reavy's team triages this component for
>>> bugs that affect our deployment of OpenH264 with Cisco.
>>> "Other" - For defects in basically all other 3rd-party software,
>>> including other NPAPI and GMP plugins, Firefox extensions, and other
>>> software such as antivirus tools, that may affect Firefox. I am triaging
>>> these bugs as necessary.
>>>
>>> --BDS
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Benjamin Smedberg]

As I understand it, Firefox: Extension Compatibility was a component where
we made Firefox product changes to support extension compat. But it's true
that most of the things that get filed there are "extension X broke in
Firefox version N".  I expect WebExtensions to make this better, but in the
meantime I'm not sure who should own this component or what is welcome or
unwelcome there.

Kev or Andy, do you have suggestions?

--BDS


On Mon, May 2, 2016 at 4:01 PM, Justin Dolske  wrote:

> Will Firefox :: Extension Compatibility also be rolled into this new ::
> Other component?
>
> (There are ~700 open bugs there still, most of which look pretty stale.)
>
> Justin
>
> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg 
> wrote:
>
>> There used to be a bugzilla.mozilla.org product called "Plugins". This
>> product has been renamed "External Software Affecting Firefox" and its
>> component structure has been greatly simplified.
>>
>> It is usually not helpful to track defects in 3rd-party software in the
>> Mozilla bug tracker. The only time we want to track those defects is when
>> we want to make explicit outreach efforts because those defects affect
>> Firefox users.
>>
>> There were previously almost a hundred different "components" for fine
>> classification of these bugs. This was not producing good results and
>> caused confusion for many people filing bugs. So I've asked for most of
>> these components to be retired, and now there will be just three components:
>>
>> "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
>> working with Adobe when necessary.
>> "OpenH264" - I believe Maire Reavy's team triages this component for bugs
>> that affect our deployment of OpenH264 with Cisco.
>> "Other" - For defects in basically all other 3rd-party software,
>> including other NPAPI and GMP plugins, Firefox extensions, and other
>> software such as antivirus tools, that may affect Firefox. I am triaging
>> these bugs as necessary.
>>
>> --BDS
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Emma Humphries]

Let me take a look at those.

On Mon, May 2, 2016 at 1:01 PM, Justin Dolske  wrote:

> Will Firefox :: Extension Compatibility also be rolled into this new ::
> Other component?
>
> (There are ~700 open bugs there still, most of which look pretty stale.)
>
> Justin
>
> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg 
> wrote:
>
>> There used to be a bugzilla.mozilla.org product called "Plugins". This
>> product has been renamed "External Software Affecting Firefox" and its
>> component structure has been greatly simplified.
>>
>> It is usually not helpful to track defects in 3rd-party software in the
>> Mozilla bug tracker. The only time we want to track those defects is when
>> we want to make explicit outreach efforts because those defects affect
>> Firefox users.
>>
>> There were previously almost a hundred different "components" for fine
>> classification of these bugs. This was not producing good results and
>> caused confusion for many people filing bugs. So I've asked for most of
>> these components to be retired, and now there will be just three components:
>>
>> "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
>> working with Adobe when necessary.
>> "OpenH264" - I believe Maire Reavy's team triages this component for bugs
>> that affect our deployment of OpenH264 with Cisco.
>> "Other" - For defects in basically all other 3rd-party software,
>> including other NPAPI and GMP plugins, Firefox extensions, and other
>> software such as antivirus tools, that may affect Firefox. I am triaging
>> these bugs as necessary.
>>
>> --BDS
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Static analysis for "use-after-move"?

[Jason Orendorff]

On Sun, May 1, 2016 at 7:39 PM, Gerald Squelart  wrote:

> Thinking of it, I suppose lots (all?) of these optimized content-stealing
> actions could be done through differently-named methods (e.g. 'Take()'), so
> they could not possibly be confused with C++ move semantics.
>

Yes. I think that will make for better code.

So I could live with a communal decision to forbid any use-after-move ever.
>

Good! Let's do it.

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

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Margaret Leibovic]

On Sun, May 1, 2016 at 6:54 AM, Henri Sivonen  wrote:

>
> What bothers me the most regarding size of what we ship is
>
>  * Failure to make the most out of compression (i.e. Zopfli) before
> objecting to the addition of new things stuff. I've brought this up
> before, but just now, I downloaded the (en-US API level 15) APK for
> Fennec 46 and ran ImageOptim (https://imageoptim.com/mac) on the PNG
> files included directly in the APK (i.e. not the one hidden inside
> omni.ja). ImageOptim says: "Saved 311KB out of 1.7MB. 28.6% per file
> on average (up to 94.3%)." (There wasn't a single already-optimal PNG
> there!) Additionally, the same exercise could be repeated for images
> in omni.ja.


We do optimize images before they land in the tree, although we usually use
pngcrush, and there may be some older assets that landed before we made
this common practice. However, Sebastian ran an analysis recently and found
that there's actually not much left to optimize (~35kb):
https://bugzilla.mozilla.org/show_bug.cgi?id=1266156

What you may actually be seeing is the fact that AAPT's optimization tool
may actually increase the size of optimized PNGs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1266156


> Then all the XML and JS could be Zopflified. The bundled
> .ttf files could be turned into Brotli-compressed WOFF2 files.


We recently landed a change to make fonts downloadable by default, so these
aren't even included in our APK anymore:
https://bugzilla.mozilla.org/show_bug.cgi?id=1194338

We also have a GSoC student this summer who's going to work on making more
parts of the APK downloadable at runtime.

On Mon, May 2, 2016 at 3:28 AM, Henri Sivonen  wrote:

> On Mon, May 2, 2016 at 2:37 AM, Jim Blandy  wrote:
> > What are the distributions of memory and flash sizes for the devices
> people
> > currently run Fennec on? It'll be almost impossible to have a good
> > discussion about Fennec size without those numbers. I seem to remember
> that
> > is data we felt was okay to collect.
>
> We should also be data-driven about understanding where the bytes go.
> In particular, I think functionality-neutral size reductions should be
> done before blocking new functionality from landing. In addition to
> unoptimally compressed PNGs, there's unminified JS in Fennec (i.e. the
> JS comments are shipped).
>

We landed a change a while back to minify JS, and we verified this morning
that all JS seems to be minified in components/chrome/toolkit:
https://bugzilla.mozilla.org/show_bug.cgi?id=1039902

I think the Firefox for Android APK size issue merits its own discussion,
outside the context of this ICU thread. I'd encourage anyone who's
interested in helping out to take a look at the meta bug where we've been
tracking our effort to reduce APK size:
https://bugzilla.mozilla.org/show_bug.cgi?id=942609

There are a lot of ideas in there, but we haven't had time to explore
fixing them all.

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

Re: Can MAX_REFLOW_DEPTH be increased?

[Ted Mielczarek]

On Mon, May 2, 2016, at 12:51 PM, L. David Baron wrote:
> Do you happen to know what the main thread stack size is on the
> platforms that we run on?

On Windows/x86 it's 1MB, Windows/x86-64 it's 2MB, on Linux and OS X it's
8MB (all reserved, not committed, AIUI).

> One risk of such a change:  I'm not sure how good breakpad is at
> reporting crashes that result from stack overflows.  At the very
> least, I've seen crashes on Android that look like stack overflows,
> but didn't actually have a stack in the crash report (bug 1269013).

On Windows and Mac this should be fine. You can see Windows reports
easily:
https://crash-stats.mozilla.com/search/?reason=~EXCEPTION_STACK_OVERFLOW&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

On Mac they are just reported as EXC_BAD_ACCESS  /
KERN_PROTECTION_FAILURE, I believe.

We fail to generate crash reports for stack overflows on Linux:
https://bugzilla.mozilla.org/show_bug.cgi?id=481781 . I've never quite
gotten around to investigating this, although upstream Breakpad seems to
handle them fine last I checked.

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

Re: Can MAX_REFLOW_DEPTH be increased?

[Boris Zbarsky]

On 5/2/16 2:30 PM, Aryeh Gregor wrote:

What's the problem with standardizing completely if we pick the limit
to be low enough that we have plenty of room?


Please define "Plenty of room"?

For a 900KB stack (what we have on Windows, per 
) 
512 DOM nodes deep corresponds to ~2KB per DOM node.  200 deep 
corresponds to 5KB.


Now quick, tell me how much stack space MSVC with PGO is using for the 
combination of ElementRestyler::Restyle and 
ElementRestyler::RestyleChildren and 
ElementRestyler::RestyleContentChildren (which is the unit of recursive 
work when recalculating styles down the tree).  How much stack space 
will it use with the next MSVC release?  How much stack space will it 
use if we change the ElementRestyler struct some (note that this goes on 
the stack before the Restyle() call on it)?


The answer at least for me is that I don't know.  But I bet it's quite 
specific to particular code paths and compilers


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

Re: Can MAX_REFLOW_DEPTH be increased?

[Boris Zbarsky]

On 5/2/16 2:15 PM, Aryeh Gregor wrote:

If the idea is to stop stack overflow, it doesn't make sense to me to
have the check in the parser at all.  It should be on the DOM level.
Otherwise, scripts could make an arbitrarily deep stack, like this:


Now we enter the discussion of threat models.

Scripts of the sort you describe are incredibly rare, not least because 
they're hard to write by accident.  So while you're right that such 
scripts can be created, and can trigger stack overflow in layout/DOM 
algorithms, in practice this has not been much of an issue.


On the other hand, broken HTML generators that forget to close all or 
some of their tags (e.g. by spitting out things like "" in HTML, 
or dumping mailbox files, complete with "" all over, out as 
"HTML") are common as dirt.  The parser mitigation is perfectly 
sufficient for the latter and was put in to deal with them.



Which outputs 1.  And indeed, removing the last line of the script
causes an immediate tab crash both in Firefox and Chrome.  So if this
is a security issue, we're vulnerable right now.


It's a DOS issue, not a security issue.  And accidental DOS in the 
common cases at that; see above.  At least assuming we crash.  If we 
attempt to not crash _that's_ when you can get security issues due to 
data structures being left in an inconsistent state.  So from a security 
point of view, crashing on stack overflow is vastly preferable to trying 
to recover from it.


Oh, and once you're talking about script, the DOS possibilities are of 
course quite varied.  I mean, you can simply OOM the process pretty easily!



If Firefox and Chrome
both have parser depth limits but not script-exposed depth limits,
probably that's because a non-negligible number of sites historically
hit the parser depth limits, but scripts haven't been much of an
issue.


Yes, see above.

-Boris

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

Changes to bugzilla "plugins" product

[Benjamin Smedberg]

There used to be a bugzilla.mozilla.org product called "Plugins". This
product has been renamed "External Software Affecting Firefox" and its
component structure has been greatly simplified.

It is usually not helpful to track defects in 3rd-party software in the
Mozilla bug tracker. The only time we want to track those defects is when
we want to make explicit outreach efforts because those defects affect
Firefox users.

There were previously almost a hundred different "components" for fine
classification of these bugs. This was not producing good results and
caused confusion for many people filing bugs. So I've asked for most of
these components to be retired, and now there will be just three components:

"Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
working with Adobe when necessary.
"OpenH264" - I believe Maire Reavy's team triages this component for bugs
that affect our deployment of OpenH264 with Cisco.
"Other" - For defects in basically all other 3rd-party software, including
other NPAPI and GMP plugins, Firefox extensions, and other software such as
antivirus tools, that may affect Firefox. I am triaging these bugs as
necessary.

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

Re: Can MAX_REFLOW_DEPTH be increased?

[Aryeh Gregor]

On Mon, May 2, 2016 at 9:19 PM, Steve Fink  wrote:
> It makes me nervous to try to make the overflow behavior the same across
> engines, because it could end up restricting implementation choices. But
> making things roughly the same without trying to make them too much the same
> seems reasonable. And it does sound like there are situations where we just
> outright fail where other browser render *something*, at least, and those
> seem worth improving.

What's the problem with standardizing completely if we pick the limit
to be low enough that we have plenty of room?  If 512 is too high for
us to commit to, we could ask Chrome to drop to 200.  We could also
always change behavior (and maybe the spec) later if it was really
causing a problem.
___
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

[Ralph Giles]

On Fri, Apr 29, 2016 at 9:52 PM, Lawrence Mandel  wrote:

> I had planned to update the thread after the post went live so that I had
> the link. Thank you for posting it.

The blog post just says "August 2016". Firefox 48 is scheduled for
release August 2. Can you confirm that means we can start removing
10.6-10.8 support in mozilla-central now, which will be Firefox 49?

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

Re: Can MAX_REFLOW_DEPTH be increased?

[Steve Fink]

It makes me nervous to try to make the overflow behavior the same across 
engines, because it could end up restricting implementation choices. But 
making things roughly the same without trying to make them too much the 
same seems reasonable. And it does sound like there are situations where 
we just outright fail where other browser render *something*, at least, 
and those seem worth improving.


On 05/02/2016 10:51 AM, L. David Baron wrote:

So I think ideally we should try to do as much of this as possible
in a standardizable way -- but we'll still probably want a backstop
dynamic stack depth check.  (Can stack overflow crashes be
security-sensitive, or do modern OSes reliably guarantee that
there's a chunk of unmapped memory past the end of the stack?  Then
again, I feel like I've seen description of exploits that relied on
that chunk of unmapped memory not being very large, and just jumping
across it with a function that had a large stack buffer.)


OSes can guarantee that you'll have a single unmapped page, no more. 
OSes differ on what guarantees they'll give you for the rest of the 
space up to the theoretical max stack size. It's messy. See bug 909094 



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

Re: Can MAX_REFLOW_DEPTH be increased?

[Aryeh Gregor]

On Mon, May 2, 2016 at 8:51 PM, L. David Baron  wrote:
> So, at the very
> least, limiting in the parser isn't effective anymore and we need
> checks at later stages, which hopefully could be done in a
> standardizable way.

Having dynamic fallback checks for anything not currently standardized
is of course perfectly sensible.  But we should standardize what we
can.

If the idea is to stop stack overflow, it doesn't make sense to me to
have the check in the parser at all.  It should be on the DOM level.
Otherwise, scripts could make an arbitrarily deep stack, like this:



var cur = document.body;
for (var i = 0; i < 1; i++) {
  var child = document.createElement("span");
  cur.appendChild(child);
  if (child.parentNode != cur) {
break;
  }
  cur = child;
}
document.body.textContent = i;


Which outputs 1.  And indeed, removing the last line of the script
causes an immediate tab crash both in Firefox and Chrome.  So if this
is a security issue, we're vulnerable right now.  If not, we should
probably just standardize the parser limit.  If Firefox and Chrome
both have parser depth limits but not script-exposed depth limits,
probably that's because a non-negligible number of sites historically
hit the parser depth limits, but scripts haven't been much of an
issue.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can MAX_REFLOW_DEPTH be increased?

[Jim Blandy]

Would it be feasible to rewrite the recursive code to be iterative, and
keep state in an explicit data structure? That would make it much easier to
keep the behavior predictable and consistent across platforms.


On Mon, May 2, 2016 at 10:34 AM, L. David Baron  wrote:

> On Monday 2016-05-02 10:07 -0700, Bobby Holley wrote:
> > This might be helpful:
> >
> http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#3440
> >
> > I can't vouch 100% for its accuracy, but it's probably pretty close.
> >
> > In general, dynamic stack checks (measuring the top of the stack at XPCOM
> > startup, and comparing it with the stack at the point of interest) seem
> > preferable to hard-coding number-of-recursive-calls, since it doesn't
> > depend on the size of stack frames, which may drift over time. We can't
> do
> > this for JS (see the comments surrounding the MXR link above), but I bet
> we
> > could for layout.
>
> We already have some code that could be improved to do stuff like
> this (see nsFrame::IsFrameTreeTooDeep and
> NS_FRAME_TOO_DEEP_IN_FRAME_TREE), but we'd need to add checks in
> other places (particularly frame construction, which is also
> recursive), and we'd also need to make sure that hitting these
> conditions kept things in a safe state and didn't cause security
> bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=619021 .
> This probably requires thorough testing of any such code.
>
> -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)
>
> ___
> 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: Can MAX_REFLOW_DEPTH be increased?

[L. David Baron]

On Monday 2016-05-02 20:31 +0300, Aryeh Gregor wrote:
> On Mon, May 2, 2016 at 8:07 PM, Bobby Holley  wrote:
> > In general, dynamic stack checks (measuring the top of the stack at XPCOM
> > startup, and comparing it with the stack at the point of interest) seem
> > preferable to hard-coding number-of-recursive-calls, since it doesn't
> > depend on the size of stack frames, which may drift over time. We can't do
> > this for JS (see the comments surrounding the MXR link above), but I bet we
> > could for layout.
> 
> I think we should aim to not make page rendering depend on things like
> the size of stack frames or the OS-provided stack size.  :)  We should
> pick a value that all UAs can commit to comfortably supporting and
> standardize it (as well as standardizing the behavior for how to
> process the non-conformant page).  Then if authors write weird pages,
> they'll break identically in all browsers.

In many cases I think you're right about this.

But I also think that the Web is adding a bunch of features (e.g.,
Shadow DOM) that make these tests harder to do.  For example, a
Shadow DOM created by a web component can make the effective DOM
observed by layout much deeper than the actual DOM.  So, at the very
least, limiting in the parser isn't effective anymore and we need
checks at later stages, which hopefully could be done in a
standardizable way.

So I think ideally we should try to do as much of this as possible
in a standardizable way -- but we'll still probably want a backstop
dynamic stack depth check.  (Can stack overflow crashes be
security-sensitive, or do modern OSes reliably guarantee that
there's a chunk of unmapped memory past the end of the stack?  Then
again, I feel like I've seen description of exploits that relied on
that chunk of unmapped memory not being very large, and just jumping
across it with a function that had a large stack buffer.)

(Whether trying to clean this up should be a current priority is
another question...)

-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: Can MAX_REFLOW_DEPTH be increased?

[L. David Baron]

On Monday 2016-05-02 10:07 -0700, Bobby Holley wrote:
> This might be helpful:
> http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#3440
> 
> I can't vouch 100% for its accuracy, but it's probably pretty close.
> 
> In general, dynamic stack checks (measuring the top of the stack at XPCOM
> startup, and comparing it with the stack at the point of interest) seem
> preferable to hard-coding number-of-recursive-calls, since it doesn't
> depend on the size of stack frames, which may drift over time. We can't do
> this for JS (see the comments surrounding the MXR link above), but I bet we
> could for layout.

We already have some code that could be improved to do stuff like
this (see nsFrame::IsFrameTreeTooDeep and
NS_FRAME_TOO_DEEP_IN_FRAME_TREE), but we'd need to add checks in
other places (particularly frame construction, which is also
recursive), and we'd also need to make sure that hitting these
conditions kept things in a safe state and didn't cause security
bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=619021 .
This probably requires thorough testing of any such code.

-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: Can MAX_REFLOW_DEPTH be increased?

[Aryeh Gregor]

On Mon, May 2, 2016 at 8:07 PM, Bobby Holley  wrote:
> In general, dynamic stack checks (measuring the top of the stack at XPCOM
> startup, and comparing it with the stack at the point of interest) seem
> preferable to hard-coding number-of-recursive-calls, since it doesn't
> depend on the size of stack frames, which may drift over time. We can't do
> this for JS (see the comments surrounding the MXR link above), but I bet we
> could for layout.

I think we should aim to not make page rendering depend on things like
the size of stack frames or the OS-provided stack size.  :)  We should
pick a value that all UAs can commit to comfortably supporting and
standardize it (as well as standardizing the behavior for how to
process the non-conformant page).  Then if authors write weird pages,
they'll break identically in all browsers.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can MAX_REFLOW_DEPTH be increased?

[Bobby Holley]

This might be helpful:
http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#3440

I can't vouch 100% for its accuracy, but it's probably pretty close.

In general, dynamic stack checks (measuring the top of the stack at XPCOM
startup, and comparing it with the stack at the point of interest) seem
preferable to hard-coding number-of-recursive-calls, since it doesn't
depend on the size of stack frames, which may drift over time. We can't do
this for JS (see the comments surrounding the MXR link above), but I bet we
could for layout.

bholley

On Mon, May 2, 2016 at 9:51 AM, L. David Baron  wrote:

> On Monday 2016-05-02 10:22 +0300, Henri Sivonen wrote:
> > In the days of Windows 95, recursive algorithms in layout used to
> > overrun the call stack on Windows unless the depth of the DOM tree was
> > limited. The HTML parser still enforces the limit, and people complain
> > about it from time to time. (Most of the time, the Web pages that hit
> > the limit are doing something wrong, but that's normal.)
> >
> > Does layout still use recursive algorithms that require a depth limit?
>
> Layout does still use recursive algorithms, but it's entirely
> possible the depth limit can be increased given our current OS
> support, and the current sizes of the structures on the stack during
> Reflow (e.g., nsHTMLReflowState, nsBlockReflowState).
>
> Do you happen to know what the main thread stack size is on the
> platforms that we run on?
>
> One risk of such a change:  I'm not sure how good breakpad is at
> reporting crashes that result from stack overflows.  At the very
> least, I've seen crashes on Android that look like stack overflows,
> but didn't actually have a stack in the crash report (bug 1269013).
>
> -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)
>
> ___
> 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: Can MAX_REFLOW_DEPTH be increased?

[L. David Baron]

On Monday 2016-05-02 10:22 +0300, Henri Sivonen wrote:
> In the days of Windows 95, recursive algorithms in layout used to
> overrun the call stack on Windows unless the depth of the DOM tree was
> limited. The HTML parser still enforces the limit, and people complain
> about it from time to time. (Most of the time, the Web pages that hit
> the limit are doing something wrong, but that's normal.)
> 
> Does layout still use recursive algorithms that require a depth limit?

Layout does still use recursive algorithms, but it's entirely
possible the depth limit can be increased given our current OS
support, and the current sizes of the structures on the stack during
Reflow (e.g., nsHTMLReflowState, nsBlockReflowState).

Do you happen to know what the main thread stack size is on the
platforms that we run on?

One risk of such a change:  I'm not sure how good breakpad is at
reporting crashes that result from stack overflows.  At the very
least, I've seen crashes on Android that look like stack overflows,
but didn't actually have a stack in the crash report (bug 1269013).

-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: ICU proposing to drop support for WinXP (and OS X 10.6)

[Justin Dolske]

On 4/30/16 1:26 PM, L. David Baron wrote:


So I think we should take option a': Drop XP and Snow Leopard support
on trunk and push ESR builds to the non-ESR update channel on XP and
Snow Leopard through the life of 45 ESR.


I think enough of our users are on Windows XP that decisions about
dropping Windows XP are not a purely engineering decision.  (Do we
still have more Windows XP users than we have on all non-Windows
platforms combined?)  Pushing those users to ESR without buy-in from
all parts of the organization will likely lead to worse engineering
problems than having to support XP (e.g., having to support 45ESR
substantially longer).


I know you and Henri know this, but because I've seen it come up in a 
number of other places...


Moving XP users to ESR is not, by itself, a solution. All moving users 
to ESR does is allow them to keep running a supported Firefox for a 
little bit longer than immediately dropping it. (Equivalently, it allows 
the dropping XP support in the code a bit earlier than the final EOL 
date in Firefox.)


Once an EOL decision on XP has been reached, we may (or may not!) opt to 
coordinate that with an ESR release. I'd note that we didn't do that 
with the recent OSX 10.6-10.8 desupport, and ISTR having not done that 
for some other platform in the past because it means maintaining 
build infrastructure for an extended period.


In other words, these are details of what to do with XP users after a 
product decision has been made to actually end support.


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

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Milan Sreckovic]

This.  Dropping the XP support is *completely* not an engineering decision.  It 
isn’t even a community decision.  It is completely, 100% MoCo driven Firefox 
product management decision, as long as the numbers of users are where they are.

It is good to have these conversations, about potential pros of removing the 
support for XP, as they will inform us in the future.  In the immediate term, 
it will be very frustrating for people to think that any technical information 
they provide would be enough to push us in the direction of dropping XP support.

—
- Milan



> On Apr 30, 2016, at 16:26 , L. David Baron  wrote:

> I think enough of our users are on Windows XP that decisions about
> dropping Windows XP are not a purely engineering decision.  (Do we
> still have more Windows XP users than we have on all non-Windows
> platforms combined?)  Pushing those users to ESR without buy-in from
> all parts of the organization will likely lead to worse engineering
> problems than having to support XP (e.g., having to support 45ESR
> substantially longer).
> 

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

Re: Can MAX_REFLOW_DEPTH be increased?

[Henri Sivonen]

On Mon, May 2, 2016 at 2:01 PM, Aryeh Gregor  wrote:
> On Mon, May 2, 2016 at 10:22 AM, Henri Sivonen  wrote:
>> If the depth limit is still needed, can now be increased?
>
> What do other UAs do?  This seems like it may as well be standardized,
> just so the odd corner-case page breaks the same in all UAs.

Whenever people complain about this, the pages render "correctly" in
at least Blink and WebKit. I don't recall checking Edge.

-- 
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: Can MAX_REFLOW_DEPTH be increased?

[Aryeh Gregor]

On Mon, May 2, 2016 at 10:22 AM, Henri Sivonen  wrote:
> If the depth limit is still needed, can now be increased?

What do other UAs do?  This seems like it may as well be standardized,
just so the odd corner-case page breaks the same in all UAs.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we remove nsIEntityConverter?

[Henri Sivonen]

On Mon, May 2, 2016 at 9:45 AM, Frédéric Wang  wrote:
> Le 01/05/2016 02:16, smaug a écrit :
>> What would source view for mathml look like if we removed
>> nsIEntityConverter?
>
> AFAIK, the only point is to replace things like "" with ""
> in order to make it more readable. However, with appropriate fonts
> installed I think reading "∑" is also fine.

Yes, and if someone wants to special-case  and
, special-casing two characters takes less space than
the entire entity tables.

As for the size question, the data tables take 2336 bytes in omni.ja
plus the zip directory overhead plus the C++ code that enables the use
of these tables.

> Le 30/04/2016 12:25, Henri Sivonen a écrit :
>>  In desktop Firefox, these data tables are used only for the
>> MathML View Source feature.
>
> Personally, I don't really use this feature, as I find the DOM inspector
> or the "MathML Copy" add-on (*) more convenient to check or copy a
> MathML formula.
>
> I guess we can move this feature from the Desktop front-end to a
> separate Add-on (that could potentially work on mobile too in the
> future). However, I can't speak for the users. Maybe we should write to
> the Math WG mailing list in order to get more feedback.
>
> (*) https://addons.mozilla.org/en-US/firefox/addon/mathml-copy/

Even if someone uses the current feature, special handling for
examining MathML seems like something that should be in an extension.

-- 
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: ICU proposing to drop support for WinXP (and OS X 10.6)

[Henri Sivonen]

On Mon, May 2, 2016 at 2:37 AM, Jim Blandy  wrote:
> What are the distributions of memory and flash sizes for the devices people
> currently run Fennec on? It'll be almost impossible to have a good
> discussion about Fennec size without those numbers. I seem to remember that
> is data we felt was okay to collect.

We should also be data-driven about understanding where the bytes go.
In particular, I think functionality-neutral size reductions should be
done before blocking new functionality from landing. In addition to
unoptimally compressed PNGs, there's unminified JS in Fennec (i.e. the
JS comments are shipped).

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

Can MAX_REFLOW_DEPTH be increased?

[Henri Sivonen]

In the days of Windows 95, recursive algorithms in layout used to
overrun the call stack on Windows unless the depth of the DOM tree was
limited. The HTML parser still enforces the limit, and people complain
about it from time to time. (Most of the time, the Web pages that hit
the limit are doing something wrong, but that's normal.)

Does layout still use recursive algorithms that require a depth limit?

If the depth limit is still needed, can now be increased?

(The limit is defined at
https://mxr.mozilla.org/mozilla-central/source/layout/generic/nsIFrame.h#16
)

-- 
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: Can we remove nsIEntityConverter?

[Frédéric Wang]

Le 01/05/2016 02:16, smaug a écrit :
> What would source view for mathml look like if we removed
> nsIEntityConverter?

AFAIK, the only point is to replace things like "" with ""
in order to make it more readable. However, with appropriate fonts
installed I think reading "∑" is also fine.

Le 30/04/2016 12:25, Henri Sivonen a écrit :
>  In desktop Firefox, these data tables are used only for the
> MathML View Source feature.

Personally, I don't really use this feature, as I find the DOM inspector
or the "MathML Copy" add-on (*) more convenient to check or copy a
MathML formula.

I guess we can move this feature from the Desktop front-end to a
separate Add-on (that could potentially work on mobile too in the
future). However, I can't speak for the users. Maybe we should write to
the Math WG mailing list in order to get more feedback.

(*) https://addons.mozilla.org/en-US/firefox/addon/mathml-copy/

-- 
Frédéric Wang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform