Re: treating B2G device tests as tier 1
This has irked me before too. An obvious compromise would that the backout proceeds, but it must include a test that would have failed on CI when the patch was landed. This puts the onus on the owners of the broken functionality to make sure that this supposedly-critical functionality has basic smoketest coverage, and gives the developer of the backed-out patch a way to verify that their code is correct on CI. Backouts should require tests. On Thu, Oct 16, 2014 at 4:33 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-15, 10:19 PM, Karl Tomlinson wrote: Jonas Sicking writes: But any type of regression is cause for backout. While I agree regressions are bad, this isn't the usual process. If it were, then I wouldn't bother filing bugs, but merely back out the offending change. There is some kind test for whether the regression costs more than the improvements made, but it comes down to a judgement call from the module owner AIUI. Regressions that sit in the tree make it dramatically much harder to write and test other patches. It's generally much better to back the offending patch out to allow everyone else to go at full speed. Perhaps it is, but this would be quite a change in process. Some kind of policy or guidelines would be helpful, or it could well get out of control. Backouts usually cause regressions too. In my experience, regressions that break something in a way that makes dogfooding difficult are open to a backout without questions asked policy (but often times in practice we'd try to reach out to the author and the folks who know the area of the code). For other regressions we typically file follow-up bugs. Note that the definition of what makes dogfooding difficult is has not been entirely consistent all the time. Cheers, Ehsan ___ 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: Moratorium on new XUL features
On 15/10/14 14:24, Boris Zbarsky wrote: I haven't thought much about #3; it's somewhat in its own little world and has no web tech equivalent. Although glazou did propose one a decade ago: http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
Boris Zbarsky wrote: The situation is that we have a bunch of unmaintained code that complicates layout. Out of interest, what does it do that complicates layout? You mentioned the box model of course, but what else is there? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
HTMLOverlays (was Re: Moratorium on new XUL features)
Which actually looks pretty good to me and should perhaps be (re)discussed. I wonder if something like HTMLoverlays (certainly extended with a mechanism to help with unloading) could be made part of the Add-on SDK. Cheers, David On 16/10/14 04:53, Gervase Markham wrote: Although glazou did propose one a decade ago: http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On Thu 16 Oct 2014 14:32, Nicholas Nethercote n.netherc...@gmail.com writes: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... The LegacyCompExprTransplanter. https://hg.mozilla.org/integration/mozilla-inbound/file/ce796ac8901b/js/src/frontend/Parser.cpp#l6110 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On 10/16/2014 02:32 PM, Nicholas Nethercote wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... Simple, any file named configure.in in the code base, because deprecated tools, and because this is the thing that I always have to run when a build-directory. “configure does not scale—never!—” [1] [1] http://hubble.gforge.inria.fr/parallel-builds.html -- Nicolas B. Pierron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On 2014-10-16 8:32 AM, Nicholas Nethercote wrote: Hi, I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... Currently or ever? I mean, if you find somebody in their office today curled up in a ball, rocking back and forth and muttering mork, mork, mork over and over again, that person's having a bad flashback. Call for help, stay with them. Tell them we've got sqlite now and it's going to be OK. Don't mention Thunderbird. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 10/16/14, 5:30 AM, Neil wrote: Out of interest, what does it do that complicates layout? You mentioned the box model of course, but what else is there? There's a bunch of listbox-related frame constructor complexity (and for a while it was a quite lively source of security bugs, too). But for the most part the layout complications come from the box model, yes. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On 10/16/2014 03:08 PM, Nicolas B. Pierron wrote: On 10/16/2014 02:32 PM, Nicholas Nethercote wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... Simple, any file named configure.in in the code base, because (1) deprecated tools, and because this is the thing that I always have to run when a (2) build-directory. (1) we use deprecated tools (2) always have to run it when we make a new build-directory. “configure does not scale—never!—” [1] [1] http://hubble.gforge.inria.fr/parallel-builds.html -- Nicolas B. Pierron One day I would have to figure out why thunderbird crash when it fails to save drafts of mailing list replies. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On 10/16/2014 7:32 AM, Nicholas Nethercote wrote: Hi, I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... http://dxr.mozilla.org/comm-central/source/mailnews/mime/src/mimedrft.cpp. C code masquerading as C++ that use XPCOM classes directly. Manual memory allocation up the wazoo. Cleans temporary files on error but not success. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On Thu 16 Oct 2014 15:24, Joshua Cranmer pidgeo...@gmail.com writes: http://dxr.mozilla.org/comm-central/source/mailnews/mime/src/mimedrft.cpp. C code masquerading as C++ that use XPCOM classes directly. Manual memory allocation up the wazoo. Cleans temporary files on error but not success. Hahaha CreateCompositionFields has 15 char* arguments, one after the other, and one of them isn't const. Good times :) Andy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTMLOverlays (was Re: Moratorium on new XUL features)
On 2014-10-16, 7:02 AM, David Rajchenbach-Teller wrote: Which actually looks pretty good to me and should perhaps be (re)discussed. It can be implemented in JS, right? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: treating B2G device tests as tier 1
On 2014-10-16, 2:51 AM, Bobby Holley wrote: This has irked me before too. An obvious compromise would that the backout proceeds, but it must include a test that would have failed on CI when the patch was landed. This puts the onus on the owners of the broken functionality to make sure that this supposedly-critical functionality has basic smoketest coverage, and gives the developer of the backed-out patch a way to verify that their code is correct on CI. Backouts should require tests. I don't think it's reasonable to assume that the person doing the backout has the time or the expertise to add a test for the broken functionality. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTMLOverlays (was Re: Moratorium on new XUL features)
On 16/10/14 12:54, Ehsan Akhgari wrote: It can be implemented in JS, right? Indeed. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: treating B2G device tests as tier 1
On Thu, Oct 16, 2014 at 10:04 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-16, 2:51 AM, Bobby Holley wrote: This has irked me before too. An obvious compromise would that the backout proceeds, but it must include a test that would have failed on CI when the patch was landed. This puts the onus on the owners of the broken functionality to make sure that this supposedly-critical functionality has basic smoketest coverage, and gives the developer of the backed-out patch a way to verify that their code is correct on CI. Backouts should require tests. I don't think it's reasonable to assume that the person doing the backout has the time or the expertise to add a test for the broken functionality. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform I don't think that's what bholley is asking for. The onus should be on the developers of the relevant app/feature/whatever to write a test that catches the regression. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Font problem in FF34a2 with CSS and fallback
Hi,
I analyzed some private pages because of a font problem with FF34a2.
It was a problem with the font Verdana.
Seems the font was crashed in my Win7 64bit.
See:
http://answers.microsoft.com/en-us/windows/forum/windows_7-desktop/verdana-ttf-font-missing-from-windows-7/33da1d97-8ebd-489c-83c5-c8359f9d3511
http://superuser.com/questions/234566/how-do-i-find-and-activate-missing-fonts-in-windows-7
But I hadn't the change to restart and test it, because I tested a
Anti-Virus-Scanner and the scan was running till now ... :D
The problem appeared e.g. when the font was specified in a CSS-File like this:
body, form, th, td {
font-family: Verdana,Arial,Helvetica,sans-serif;
And also the fall-back to the font Arial didn't worked!
But in this example (with the font in the HTML-File) it worked !!!
http://de.selfhtml.org/css/eigenschaften/anzeige/font_family.htm
(And there is no fall-back!)
So my first questions were:
- Why I had no problems with the second font ???
- Is it possible to check if the font really works or if it is just wrong
registered in the system ???
- And - because it seems there are more problems with Verdana - is it possible
to ship a own Verdana with FF ???
I found e.g. this about the problems:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=Verdanalist_id=11382200
http://forums.mozillazine.org/viewtopic.php?f=38t=298766
But today I got even more confused, because I updated to FF35a2 and now the
fall-back seems to work ... ???
Greets, Tobias (BesTo).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: treating B2G device tests as tier 1
On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: I don't think it's reasonable to assume that the person doing the backout has the time or the expertise to add a test for the broken functionality. Not the sheriff certainly, but I think if the regression is severe enough to warrant this action, the product owners (who are generally the ones who request the backout) can find the resources to make that happen. There will be situations where this is unrealistically difficult for one reason or another. But I'd rather put the onus on the product owners to ask for that exception, and presumably offer human resources to help the developer update and test their patch. If a team pulls this card, they should have a responsibility to help get the patch relanded in a timely manner. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: treating B2G device tests as tier 1
On 2014-10-16, 1:52 PM, Bobby Holley wrote: On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: I don't think it's reasonable to assume that the person doing the backout has the time or the expertise to add a test for the broken functionality. Not the sheriff certainly, but I think if the regression is severe enough to warrant this action, the product owners (who are generally the ones who request the backout) can find the resources to make that happen. Who are the product owners exactly? Usually what happens in these cases is some discussion on IRC, followed by trying to ping the author/reviewer, followed by a backout either by a sheriff or another individual such as myself. There will be situations where this is unrealistically difficult for one reason or another. But I'd rather put the onus on the product owners to ask for that exception, and presumably offer human resources to help the developer update and test their patch. Again, I'm not sure who specifically you're referring to as the bearer of this responsibility. If a team pulls this card, they should have a responsibility to help get the patch relanded in a timely manner. I disagree. If someone breaks Nightly on desktop for example to an extent where it cannot be used for dogfooding, and I back them out to help out our Nightly users and keep the testing product usable so that other regressions can be caught with it, why should I feel responsible for relanding their patch in a timely manner? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTMLOverlays (was Re: Moratorium on new XUL features)
On 2014-10-16, 1:44 PM, David Rajchenbach-Teller wrote: On 16/10/14 12:54, Ehsan Akhgari wrote: It can be implemented in JS, right? Indeed. I meant, as a JS library by web developers who feel like it's needed, not by us. :-) FWIW I think that XUL overlays are a terrible way of extending the UI so I'm not in a rush for something like that to happen for HTML. Their biggest issue is that they completely ignore the problem of how to handle two different overlays being applied to the same element. They also effectively make your DOM structure a public API which is barely maintainable, as we have learned the hard way. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Compiler version expectations
After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... Probably not the worst, but always deserves a mention: http://dxr.mozilla.org/mozilla-central/source/layout/xul/nsSprocketLayout.cpp#632 // That's it! If you made it this far without having a nervous breakdown, // congratulations! Go get yourself a beer. ... which ties into the XUL thread :-) Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
only code? Long time ago I found a PSD file in the Netscape source. About 1MB with a few layers. m On Thu, Oct 16, 2014 at 4:52 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... Probably not the worst, but always deserves a mention: http://dxr.mozilla.org/mozilla-central/source/layout/xul/nsSprocketLayout.cpp#632 // That's it! If you made it this far without having a nervous breakdown, // congratulations! Go get yourself a beer. ... which ties into the XUL thread :-) Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- www.telasocial.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: treating B2G device tests as tier 1
On 16 October 2014 20:55, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-16, 1:52 PM, Bobby Holley wrote: On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: I don't think it's reasonable to assume that the person doing the backout has the time or the expertise to add a test for the broken functionality. Not the sheriff certainly, but I think if the regression is severe enough to warrant this action, the product owners (who are generally the ones who request the backout) can find the resources to make that happen. Who are the product owners exactly? Usually what happens in these cases is some discussion on IRC, followed by trying to ping the author/reviewer, followed by a backout either by a sheriff or another individual such as myself. There will be situations where this is unrealistically difficult for one reason or another. But I'd rather put the onus on the product owners to ask for that exception, and presumably offer human resources to help the developer update and test their patch. Again, I'm not sure who specifically you're referring to as the bearer of this responsibility. If a team pulls this card, they should have a responsibility to help get the patch relanded in a timely manner. I disagree. If someone breaks Nightly on desktop for example to an extent where it cannot be used for dogfooding, and I back them out to help out our Nightly users and keep the testing product usable so that other regressions can be caught with it, why should I feel responsible for relanding their patch in a timely manner? The someone is the person that wrote the feature that was broken but no tests caught it I believe the general idea is that as a peer / module owner / product owner, I have the responsibility to write tests that ensure my feature works, and if it is broken by upstream changes that landed because automation didnt find anything wrong with it, then its my responsibility to ensure that tests are written so it doesnt get regressed in the same way again and automation can catch it. Otherwise with no visibility I am putting the reponsibility onto every other upstream developer to hopefully not break my code without any context for them to even know when they have done so. This is summed up in the meme: http://mozillamemes.tumblr.com/post/26210699924/you-reap-what-you-sow ___ 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: Compiler version expectations
On 2014-10-16, 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. GCC is https://bugzilla.mozilla.org/show_bug.cgi?id=1077549. No specific bug or plans for MSVC2010, but I'd be open to killing support for it on the next release train. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? What C++11 features specifically? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: treating B2G device tests as tier 1
On 2014-10-16, 3:56 PM, Dale Harvey wrote: On 16 October 2014 20:55, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On 2014-10-16, 1:52 PM, Bobby Holley wrote: On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com mailto:ehsan.akhgari@gmail.__com mailto:ehsan.akhg...@gmail.com wrote: I don't think it's reasonable to assume that the person doing the backout has the time or the expertise to add a test for the broken functionality. Not the sheriff certainly, but I think if the regression is severe enough to warrant this action, the product owners (who are generally the ones who request the backout) can find the resources to make that happen. Who are the product owners exactly? Usually what happens in these cases is some discussion on IRC, followed by trying to ping the author/reviewer, followed by a backout either by a sheriff or another individual such as myself. There will be situations where this is unrealistically difficult for one reason or another. But I'd rather put the onus on the product owners to ask for that exception, and presumably offer human resources to help the developer update and test their patch. Again, I'm not sure who specifically you're referring to as the bearer of this responsibility. If a team pulls this card, they should have a responsibility to help get the patch relanded in a timely manner. I disagree. If someone breaks Nightly on desktop for example to an extent where it cannot be used for dogfooding, and I back them out to help out our Nightly users and keep the testing product usable so that other regressions can be caught with it, why should I feel responsible for relanding their patch in a timely manner? The someone is the person that wrote the feature that was broken but no tests caught it No, the someone is the person who wrote a patch which survived tests on our infra but broke a product in a way that made it undogfood-able. The specific functionality that they broke may be their own area, someone else's or some ancient piece of code that nobody really owns. I believe the general idea is that as a peer / module owner / product owner, I have the responsibility to write tests that ensure my feature works, and if it is broken by upstream changes that landed because automation didnt find anything wrong with it, then its my responsibility to ensure that tests are written so it doesnt get regressed in the same way again and automation can catch it. Otherwise with no visibility I am putting the reponsibility onto every other upstream developer to hopefully not break my code without any context for them to even know when they have done so. This is summed up in the meme: http://mozillamemes.tumblr.com/post/26210699924/you-reap-what-you-sow Sure. But you're just describing why tests are useful and an absolute necessity. :-) I think what Bobby was asking for is a much stronger ask that is not really attainable. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
On Oct 16, 2014, at 3:57 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-16, 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. GCC is https://bugzilla.mozilla.org/show_bug.cgi?id=1077549. No specific bug or plans for MSVC2010, but I'd be open to killing support for it on the next release train. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? What C++11 features specifically? This set: http://chromium-cpp.appspot.com/ -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: treating B2G device tests as tier 1
On Thu, Oct 16, 2014 at 1:01 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-16, 3:56 PM, Dale Harvey wrote: On 16 October 2014 20:55, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On 2014-10-16, 1:52 PM, Bobby Holley wrote: On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com mailto:ehsan.akhgari@gmail.__com mailto:ehsan.akhg...@gmail.com wrote: I don't think it's reasonable to assume that the person doing the backout has the time or the expertise to add a test for the broken functionality. Not the sheriff certainly, but I think if the regression is severe enough to warrant this action, the product owners (who are generally the ones who request the backout) can find the resources to make that happen. Who are the product owners exactly? Usually what happens in these cases is some discussion on IRC, followed by trying to ping the author/reviewer, followed by a backout either by a sheriff or another individual such as myself. There will be situations where this is unrealistically difficult for one reason or another. But I'd rather put the onus on the product owners to ask for that exception, and presumably offer human resources to help the developer update and test their patch. Again, I'm not sure who specifically you're referring to as the bearer of this responsibility. If a team pulls this card, they should have a responsibility to help get the patch relanded in a timely manner. I disagree. If someone breaks Nightly on desktop for example to an extent where it cannot be used for dogfooding, and I back them out to help out our Nightly users and keep the testing product usable so that other regressions can be caught with it, why should I feel responsible for relanding their patch in a timely manner? The someone is the person that wrote the feature that was broken but no tests caught it No, the someone is the person who wrote a patch which survived tests on our infra but broke a product in a way that made it undogfood-able. The specific functionality that they broke may be their own area, someone else's or some ancient piece of code that nobody really owns. You're making this about something it's not. This is about undertested b2g apps. Nothing more, nothing less. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: treating B2G device tests as tier 1
On 10/16/14, 4:01 PM, Ehsan Akhgari wrote: Sure. But you're just describing why tests are useful and an absolute necessity. :-) I think what Bobby was asking for is a much stronger ask that is not really attainable. I think what Bobby was actually asking for is this: If a patch lands and is green in continuous integration but then we have some other tests somewhere (hidden, run manually, whatever) that start failing because of this patch, and we deem those failures sufficiently dire to back out the patch, then the owners of these secret-but-critical tests should share some responsibility for enabling the patch to reland. Not least because otherwise it's not clear how to proceed. Certainly that's what _I_ want. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
I was thinking it would be nice to support VS2010 as long as any of our main channels use it -- meaning we could drop it on the first day of 39. But I have no practical justification for that. If it causes a burden on Skia work then it might be reasonable to switch sooner. This set: http://chromium-cpp.appspot.com/ What MS compiler does that list require? There's a number of people building with VS2012, would that still be supported? David - Original Message - From: Jeff Muizelaar jmuizel...@mozilla.com To: Ehsan Akhgari ehsan.akhg...@gmail.com Cc: dev-platform@lists.mozilla.org list dev-platform@lists.mozilla.org Sent: Friday, October 17, 2014 9:14:19 AM Subject: Re: Compiler version expectations On Oct 16, 2014, at 3:57 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-16, 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. GCC is https://bugzilla.mozilla.org/show_bug.cgi?id=1077549. No specific bug or plans for MSVC2010, but I'd be open to killing support for it on the next release train. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? What C++11 features specifically? This set: http://chromium-cpp.appspot.com/ -Jeff ___ 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: Moratorium on new XUL features
On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch gijskruitbo...@gmail.com wrote: There are also interesting height computation issues that I'm pretty sure HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a function of the box model, considering it's not an issue with flexbox... Yeah. XUL layout (all layouts, not just flexbox) compute intrinsic width *and* height bottom up before doing actual layout. This is incompatible with CSS and really just broken, and the friction between that model and CSS is painful. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
On 10/16/2014 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? I can't speak to the GCC issue, but we intend to continue support for MSVC2010 at least through the 36 train, in case a regression is found which is serious enough to cause us to revert. If there are no serious issues found, I think it is reasonable to require MSVC2013 in six weeks. If we do that, I'd want somebody to actually make 2010 fail early in configure. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
On Oct 16, 2014, at 14:49, Jeff Muizelaar jmuizel...@mozilla.com wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? -Jeff Does MSVC 2013 run on Windows XP? We still support Win XP for the browser; do we support building on it? Syd Polk sp...@mozilla.com +1-512-905-9904 irc: sydpolk ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
On Thu, Oct 16, 2014 at 2:03 PM, Syd Polk sp...@mozilla.com wrote: On Oct 16, 2014, at 14:49, Jeff Muizelaar jmuizel...@mozilla.com wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? -Jeff Does MSVC 2013 run on Windows XP? We still support Win XP for the browser; do we support building on it? Syd Polk sp...@mozilla.com +1-512-905-9904 irc: sydpolk ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform There's no reason to continue supporting compiling on XP. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
On 10/16/14 12:49 PM, Jeff Muizelaar wrote: Are there reasons we can’t drop support for these compilers in the 37-38 time frame? Firefox 38 will become the next ESR. I don't know if that means we should drop old compilers *before* the ESR or after, but it should probably inform the decision. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Using __declspec(thread) on Windows
It would be cool to use fast TLS via __declspec(thread) on Windows (and __thread on gcc/clang). Due to WinXP bustage that only works for variables in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in our shipped Windows builds mozglue.dll is statically linked to firefox.exe so we could put __declspec(thread) variables there. However, that would break if someone tried to dynamically load libxul on WinXP in the context of a .EXE which did not statically link mozglue.dll. Does anyone know if that's a problem? I assume no-one's finding the Firefox libxul.dll and loading it from their own .EXE, but maybe they're building their own? Do we care? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
On 2014-10-16, 5:01 PM, Chris Peterson wrote: On 10/16/14 12:49 PM, Jeff Muizelaar wrote: Are there reasons we can’t drop support for these compilers in the 37-38 time frame? Firefox 38 will become the next ESR. I don't know if that means we should drop old compilers *before* the ESR or after, but it should probably inform the decision. Why? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
On 2014-10-16, 5:02 PM, Benjamin Smedberg wrote: On 10/16/2014 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? I can't speak to the GCC issue, but we intend to continue support for MSVC2010 at least through the 36 train, in case a regression is found which is serious enough to cause us to revert. If there are no serious issues found, I think it is reasonable to require MSVC2013 in six weeks. If we do that, I'd want somebody to actually make 2010 fail early in configure. I'd happily do that: https://bugzilla.mozilla.org/show_bug.cgi?id=1084056 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On 10/16/14 5:32 AM, Nicholas Nethercote wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... It's gone now, but I always held a special hate for nsIDialogParamBlock. http://mxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/public/nsIDialogParamBlock.idl It was a horrid XPCOM thing to pass strings around for creating a prompt, by way of magic numbers. Want to set the title? Set string #12! Or maybe it was #3. They're listed in the completely separate nsPIPromptService.idl, but they're confusing (#12 is eDialogTitle, #3 is eTitleMessage), and IIRC some are complete lies. Most of the other original prompting code was similarly bad. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
Can you please ask them to not use variadic templates too? That also seems to require MSVC 2013. On 2014-10-16, 4:33 PM, Jeff Muizelaar wrote: Type aliasing requires 2013, but we can probably keep them from using that for now. I don’t think asking them to support VS2012 will be too much of a burden. -Jeff On Oct 16, 2014, at 4:29 PM, David Major dma...@mozilla.com wrote: I was thinking it would be nice to support VS2010 as long as any of our main channels use it -- meaning we could drop it on the first day of 39. But I have no practical justification for that. If it causes a burden on Skia work then it might be reasonable to switch sooner. This set: http://chromium-cpp.appspot.com/ What MS compiler does that list require? There's a number of people building with VS2012, would that still be supported? David - Original Message - From: Jeff Muizelaar jmuizel...@mozilla.com To: Ehsan Akhgari ehsan.akhg...@gmail.com Cc: dev-platform@lists.mozilla.org list dev-platform@lists.mozilla.org Sent: Friday, October 17, 2014 9:14:19 AM Subject: Re: Compiler version expectations On Oct 16, 2014, at 3:57 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-16, 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. GCC is https://bugzilla.mozilla.org/show_bug.cgi?id=1077549. No specific bug or plans for MSVC2010, but I'd be open to killing support for it on the next release train. This is important to us because Skia is planing on using more C++11 features in the near term and we’d like to continue updating from upstream. Are there reasons we can’t drop support for these compilers in the 37-38 time frame? What C++11 features specifically? This set: http://chromium-cpp.appspot.com/ -Jeff ___ 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: The worst piece of Mozilla code
roc said: Probably not the worst, but always deserves a mention: http://dxr.mozilla.org/mozilla-central/source/layout/xul/nsSprocketLayout.cpp#632 That's relatively short. This is 800 lines, complete with several layers of goto: http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c?from=ssl3_HandleClientHellocase=true#7618 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: treating B2G device tests as tier 1
On 2014-10-16, 4:20 PM, Boris Zbarsky wrote: On 10/16/14, 4:01 PM, Ehsan Akhgari wrote: Sure. But you're just describing why tests are useful and an absolute necessity. :-) I think what Bobby was asking for is a much stronger ask that is not really attainable. I think what Bobby was actually asking for is this: If a patch lands and is green in continuous integration but then we have some other tests somewhere (hidden, run manually, whatever) that start failing because of this patch, and we deem those failures sufficiently dire to back out the patch, then the owners of these secret-but-critical tests should share some responsibility for enabling the patch to reland. Not least because otherwise it's not clear how to proceed. Certainly that's what _I_ want. I wholeheartedly agree, but I couldn't read between the lines of Bobby's email well enough, apparently! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... Probably not the worst, but always deserves a mention: http://dxr.mozilla.org/mozilla-central/source/layout/xul/nsSprocketLayout.cpp#632 // That's it! If you made it this far without having a nervous // breakdown, congratulations! Go get yourself a beer. ... which ties into the XUL thread :-) Reminds me of the total rewrite I did of the table-layout code for SpyGlass eons ago, to actually work correctly (I think I even had it handle bug 10212 correct - height 100% when nesting tables). Quite brain-warping, especially how changes can ripple through multiple times. -- Randell Jesup, Mozilla Corp remove news for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using __declspec(thread) on Windows
in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in our shipped Windows builds mozglue.dll is statically linked to firefox.exe so we could put __declspec(thread) variables there. What does 'statically linked' mean in this context? Mozglue.dll is still a DLL, but yes it's a load-time link in version 33. Starting in version 34 it's a delay-load due to some WinXP sorcery. - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: dev-platform@lists.mozilla.org Sent: Friday, October 17, 2014 10:10:57 AM Subject: Using __declspec(thread) on Windows It would be cool to use fast TLS via __declspec(thread) on Windows (and __thread on gcc/clang). Due to WinXP bustage that only works for variables in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in our shipped Windows builds mozglue.dll is statically linked to firefox.exe so we could put __declspec(thread) variables there. However, that would break if someone tried to dynamically load libxul on WinXP in the context of a .EXE which did not statically link mozglue.dll. Does anyone know if that's a problem? I assume no-one's finding the Firefox libxul.dll and loading it from their own .EXE, but maybe they're building their own? Do we care? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ 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: The worst piece of Mozilla code
On Thursday 2014-10-16 05:32 -0700, Nicholas Nethercote wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... I'd probably pick the table and row height computation code in the table layout code. There's row height code in nsTableRowGroupFrame::ReflowChildren, nsTableRowGroupFrame::CalculateRowHeights, nsTableRowGroupFrame::GetHeightBasis, and nsTableRowFrame::CalculateCellActualHeight, which then has interesting interactions with table/cell height code via things like the mPercentHeightObserver member of nsHTMLReflowState and nsTableCellFrame::NotifyPercentHeight, and the SpecialHeightReflow concept in nsTableFrame. (The worst bit is that we could have massively simplified it and sped it up by matching IE6's much cleaner model, but now it's probably too late for that since other browsers have copied us.) -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: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
On 10/16/14 2:27 PM, Ehsan Akhgari wrote: On 2014-10-16, 5:01 PM, Chris Peterson wrote: On 10/16/14 12:49 PM, Jeff Muizelaar wrote: Are there reasons we can’t drop support for these compilers in the 37-38 time frame? Firefox 38 will become the next ESR. I don't know if that means we should drop old compilers *before* the ESR or after, but it should probably inform the decision. Why? Would dropping older compiler support include ESR alongside mozilla-central? I assumed dropping an older compiler after ESR forks meant Rel Eng would need to maintain an extra toolchain for another year. And, though unlikely, fixes uplifted to ESR couldn't use any newer C++ features not supported by the old compilers. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On Thu, Oct 16, 2014 at 11:32 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... Thanks for the replies so far! I deliberately left this question vague to see what kind of responses people would give. But mostly I'm interested in code whose awfulness impacts users in a serious way. Ones where refactoring/rewriting efforts would be valuable. That excludes code that no longer exists :) With this in mind, a function that is hideous but non-buggy and doesn't cause maintenance problems (e.g. because the hideousness doesn't leak too far) wouldn't qualify as bad. In comparison, a sub-system with frequent subtle correctness issues would be very bad. So I'd be interested in suggestions along these lines. Feel free to email me privately if you prefer. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On Fri, Oct 17, 2014 at 8:55 AM, Andreas Gal andr...@mozilla.com wrote: I would like to nominate image/src/* and in particular its class hierarchy which completely doesn’t make any sense what so ever. imgRequest, imgIRequest, we got it all. Does this cause correctness problems, or is it just hard to read and thus modify? Is there a path that could be taken to gradually improve it? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using __declspec(thread) on Windows
On Fri, Oct 17, 2014 at 10:45 AM, David Major dma...@mozilla.com wrote: in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in our shipped Windows builds mozglue.dll is statically linked to firefox.exe so we could put __declspec(thread) variables there. What does 'statically linked' mean in this context? Mozglue.dll is still a DLL, but yes it's a load-time link in version 33. Starting in version 34 it's a delay-load due to some WinXP sorcery. Ah OK. I think that won't work in 34 then. Ho hum. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using __declspec(thread) on Windows
On Fri, Oct 17, 2014 at 10:10:57AM +1300, Robert O'Callahan wrote: It would be cool to use fast TLS via __declspec(thread) on Windows (and __thread on gcc/clang). Due to WinXP bustage that only works for variables in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in our shipped Windows builds mozglue.dll is statically linked to firefox.exe so we could put __declspec(thread) variables there. However, that would break if someone tried to dynamically load libxul on WinXP in the context of a .EXE which did not statically link mozglue.dll. Does anyone know if that's a problem? I assume no-one's finding the Firefox libxul.dll and loading it from their own .EXE, but maybe they're building their own? Do we care? Firefox.exe is unfortunately not the only executable we're actively using and that load xul.dll. There's at least webapprt.exe and plugin-container.exe, and I know for a fact that the former doesn't statically link mozglue.dll. IOW, you'd break webapps. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
The code is really bizarre, needlessly complex and impossible to understand and maintain. We could use a lot of improvements in this area to better decide what images to load when and how and when to retain or purge them. There is a lot of state machinery and multi-threading at work. I wouldn’t be surprised if we find a couple nasty correctness bugs if we ever decide to clean up this mess. bholley is the expert for this code I think. He can give you a better overview (full disclosure: this code used to be much worse before he went to town on it). Andreas On Oct 16, 2014, at 7:33 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Fri, Oct 17, 2014 at 8:55 AM, Andreas Gal andr...@mozilla.com wrote: I would like to nominate image/src/* and in particular its class hierarchy which completely doesn’t make any sense what so ever. imgRequest, imgIRequest, we got it all. Does this cause correctness problems, or is it just hard to read and thus modify? Is there a path that could be taken to gradually improve it? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On Thursday 2014-10-16 19:45 -0300, Andreas Gal wrote: The code is really bizarre, needlessly complex and impossible to understand and maintain. We could use a lot of improvements in this area to better decide what images to load when and how and when to retain or purge them. Seth has been doing a lot of work on cleaning up the image code lately, most recently on rewriting the caching behavior (including adding the ability to store more than one decoded form of an image, which enables things like downscale-on-decode), which is currently in-progress. -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: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
I'm not certain that the image/src/ code is as bad as you make out any more. bholley certainly is no longer the expert there; I took over a bunch of his work to clean it up a year or two ago, and Seth is the benevolent dictator now and has done some good cleanup work on it as well. Cheers, Josh On 2014-10-16 6:45 PM, Andreas Gal wrote: The code is really bizarre, needlessly complex and impossible to understand and maintain. We could use a lot of improvements in this area to better decide what images to load when and how and when to retain or purge them. There is a lot of state machinery and multi-threading at work. I wouldn’t be surprised if we find a couple nasty correctness bugs if we ever decide to clean up this mess. bholley is the expert for this code I think. He can give you a better overview (full disclosure: this code used to be much worse before he went to town on it). Andreas On Oct 16, 2014, at 7:33 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Fri, Oct 17, 2014 at 8:55 AM, Andreas Gal andr...@mozilla.com wrote: I would like to nominate image/src/* and in particular its class hierarchy which completely doesn’t make any sense what so ever. imgRequest, imgIRequest, we got it all. Does this cause correctness problems, or is it just hard to read and thus modify? Is there a path that could be taken to gradually improve it? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
I am glad to hear there is so much activity happening there. Kind of makes my point though: that code needed it :) Andreas On Oct 16, 2014, at 8:03 PM, Josh Matthews j...@joshmatthews.net wrote: I'm not certain that the image/src/ code is as bad as you make out any more. bholley certainly is no longer the expert there; I took over a bunch of his work to clean it up a year or two ago, and Seth is the benevolent dictator now and has done some good cleanup work on it as well. Cheers, Josh On 2014-10-16 6:45 PM, Andreas Gal wrote: The code is really bizarre, needlessly complex and impossible to understand and maintain. We could use a lot of improvements in this area to better decide what images to load when and how and when to retain or purge them. There is a lot of state machinery and multi-threading at work. I wouldn’t be surprised if we find a couple nasty correctness bugs if we ever decide to clean up this mess. bholley is the expert for this code I think. He can give you a better overview (full disclosure: this code used to be much worse before he went to town on it). Andreas On Oct 16, 2014, at 7:33 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Fri, Oct 17, 2014 at 8:55 AM, Andreas Gal andr...@mozilla.com wrote: I would like to nominate image/src/* and in particular its class hierarchy which completely doesn’t make any sense what so ever. imgRequest, imgIRequest, we got it all. Does this cause correctness problems, or is it just hard to read and thus modify? Is there a path that could be taken to gradually improve it? 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: The worst piece of Mozilla code
On Fri, Oct 17, 2014 at 09:32:20AM +1100, Nicholas Nethercote wrote: On Thu, Oct 16, 2014 at 11:32 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... Thanks for the replies so far! I deliberately left this question vague to see what kind of responses people would give. But mostly I'm interested in code whose awfulness impacts users in a serious way. Ones where refactoring/rewriting efforts would be valuable. That excludes code that no longer exists :) With this in mind, a function that is hideous but non-buggy and doesn't cause maintenance problems (e.g. because the hideousness doesn't leak too far) wouldn't qualify as bad. In comparison, a sub-system with frequent subtle correctness issues would be very bad. For that I'd tend to agree with ehsan editor/ and the selection bits in layout/. RDF is more terrible, but probably less important and its more a problem of removal than of refactoring. Trev So I'd be interested in suggestions along these lines. Feel free to email me privately if you prefer. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: TV Manager API
Will this be restricted to certified or privileged apps? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: TV Manager API
Yes, It'll only be available to certified apps. Sean - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Sean Lin se...@mozilla.com Cc: dev-platform@lists.mozilla.org Sent: Friday, October 17, 2014 11:18:30 AM Subject: Re: Intent to implement: TV Manager API Will this be restricted to certified or privileged apps? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
