Re: One Firefox repository to rule them all

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

Re: One Firefox repository to rule them all

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:

Re: One Firefox repository to rule them all

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 >

Re: Intent to deprecate: MacOS 10.6-10.8 support

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

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

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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

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

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.

Re: One Firefox repository to rule them all

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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

Re: Changes to bugzilla "plugins" product

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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

Re: Changes to bugzilla "plugins" product

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,

Re: Changes to bugzilla "plugins" product

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

Re: Changes to bugzilla "plugins" product

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

Re: Changes to bugzilla "plugins" product

​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

Re: Changes to bugzilla "plugins" product

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

Re: Changes to bugzilla "plugins" product

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,

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

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

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

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

Re: Can MAX_REFLOW_DEPTH be increased?

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:

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Can MAX_REFLOW_DEPTH be increased?

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.

Changes to bugzilla "plugins" product

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

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Can MAX_REFLOW_DEPTH be increased?

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.

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

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

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

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

Re: Can MAX_REFLOW_DEPTH be increased?

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

Re: Can MAX_REFLOW_DEPTH be increased?

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.

Re: Can we remove nsIEntityConverter?

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.

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

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 >

Can MAX_REFLOW_DEPTH be increased?

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

Re: Can we remove nsIEntityConverter?

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