Re: Update on sheriff-assisted checkin-needed bugs
Ehsan Akhgari wrote: On 2014-05-21, 5:15 PM, Chris Peterson wrote: On 5/21/14, 1:51 PM, Mike Conley wrote: Or, alternatively, attempt to automate this with Autoland (https://bugzilla.mozilla.org/show_bug.cgi?id=657828). Is anyone actively working on Autoland? Rail had been working on Autoland, but when I spoke with him in 2013 Q4, I think he said he would not have time to work on it in 2014 Q1. For a tool as important and often requested as Autoland, we should get it on someone's schedule. :) I think Taras knows more details. I expect some exciting stuff in https://bugzilla.mozilla.org/show_bug.cgi?id=1005235 soon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSSOM-View scroll-behavior property
The ScrollBehavior DOM API would certainly be useful by itself and solve some of our immediate needs (paged B2G home page, for example). I also imagine that it would not preclude us from implementing the css property in the future if we implement it carefully. I would like to hear feedback regarding the motion of the scrolling itself... The spec describes the motion as The scrolling box is scrolled in a smooth fashion using a user-agent-defined timing function over a user-agent-defined period of time. User agents should follow platform convensions, if any.. Should we implement a separate model for any of the platforms we support, or is resolution independence and platform-specific tuning of the critically-damped-motion model I proposed sufficient? In the Bug 1010538 (https://bugzilla.mozilla.org/show_bug.cgi?id=1010538) I am proposing that this movement model would inherit the velocity of the scroll resulting from fling gestures or prior smooth scroll operations that are interrupted. This would be needed to implement scroll snapping like behaviors for carousels and paged navigation that allow manual dragging (Including the B2G home page). The W3C scroll-behavior spec does not require this behavior, but also does not preclude it. My greatest concern is that as platform conventions change, this behavior could (or should) be updated to match. Web developers that depend on particular acceleration / deceleration curves or time to completion may see their web applications behave differently in the future. If they treat it as a black-box; however, their applications may continue to feel modern, as opposed to movement implemented within their own Javascript. Does this raise any concerns or need for further dialogue before implementation? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
sandboxbroker.dll will soon build by default on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To build Firefox with support for process sandboxing, you currently pass the --enable-content-sandbox flag. On Windows, using the --enable-content-sandbox flag causes an extra DLL to be built - sandboxbroker.dll - which is responsible for providing all of our process sandboxing functionality. In bug 985252 [1] and friends, we're working on implementing process sandboxing for processes other than content processes (in this case, GMP plugin processes specifically). This means that we're de-coupling --enable-content-sandbox from the building of sandboxbroker.dll; the DLL will be built in all Windows Firefox builds regardless of whether --enable-content-sandbox is specified, and it will be included in the Firefox installer. This change should only affect Windows builds and it looks like the installer size increase is about 61K or 0.18%. Let me know if there are concerns regarding this change. Thanks! Tim [1] https://bugzilla.mozilla.org/show_bug.cgi?id=985252 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThOTzAAoJENMT71e+7HCHrkkP/1qR4wJyz/08FyGN0YFJXOer OTHbsm//IrSHuAV39VdA4mVhY2IF0AmUyslwjYxq+LvTpfIMOB9QCqsSVaW0MvCH lAlb/AJw1SZobysb8SHb8qgfkVHxcbbVCGfv6s3lGpoCtmf5ShoDNTGyXpN0d4w7 L6qCGdBt8nh3PtwqpPd2iBZHf90kxjTH08DXWrRkROH38mha05aWUgJvKSgRz1f4 SxiuaPNzB+TzUWAGVzF/d9CUSd//aE4hIFml4sJak2sHDlnk27Lp/QNDHMBE7OBc hZ+wCnRyfv4r46UoXL3ybByPN5AvL5Hj8Wx03EJ3ilZoasV7LkxCu8WToVAyYFc5 4jRhmIHYKPcdrUH6aO9Ru5Nj1MRGPxCgxmWsHex8hPFZhkt7PuRLrPtaFqOE1irH gyRJrUI1DGbJJCh434yfW9CCMiYvCngiJM94dEWcgirWei/8CvtMpUyDmPuDrhlg Y0qumSLQ5XQEM6eDAI3TN/tqFGt4nHs2HpN68fwYr9Evhk+wlAkw6gOErMHC/1+d M7UIRfTzTQY3Vk033et0wE3vq42d+S/AVrT2wcbh3IpQKhdaVfsm8cpClsXsFHt6 L4Y4qWgtO9uQIIUIMQ5JEy3poSUoiWadahOXUZaRBh5cxpxveWuBMY/vbpzAnZTY 62TmAj5Scn/hFU8vEk9H =BcVL -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Today, 27 May 2014 at 4:00pm PDT
Today's MemShrink meeting will be brought to you by image urls and sizes in about:memory: https://bugzilla.mozilla.org/show_bug.cgi?id=1009097 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 27 May, 4:00 PM PDT * http://arewemeetingyet.com/Los%20Angeles/2014-05-27/16:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSSOM-View scroll-behavior property
On Wed, May 28, 2014 at 5:36 AM, Kearwood Gilbert kearwood.gilb...@gmail.com wrote: My greatest concern is that as platform conventions change, this behavior could (or should) be updated to match. Web developers that depend on particular acceleration / deceleration curves or time to completion may see their web applications behave differently in the future. If they treat it as a black-box; however, their applications may continue to feel modern, as opposed to movement implemented within their own Javascript. Does this raise any concerns or need for further dialogue before implementation? I believe we don't currently make any attempt to match platform smooth scrolling behavior, and I don't think we need to start now. I do think it's a good idea to retain the option of matching platform behavior in the future. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSSOM-View scroll-behavior property
On Wed, May 28, 2014 at 6:14 AM, kgilb...@mozilla.com wrote: Is this behavior acceptable or would it be more desirable to always return the actual scroll position in DOM methods? All DOM methods that depend on the scroll position (not just scrollLeft/scrollTop but getBoundingClientRect etc too) should always use the most up-to-date value of the actual scroll position that the main thread has. That's how our existing smooth scrolling behaves. I.e., we don't lie :-). I'm pretty sure the CSSOM spec requires that for the ScrollBehavior smooth value, too. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Implement: Encrypted Media Extensions
Summary: Encrypted Media Extensions specifies a JavaScript interface for interacting with plugins that can be used to facilitate playback of DRM protected media content. We will also be implementing the plugin interface itself. We will be working in partnership with Adobe who are developing a compatible DRM plugin; the Adobe Access CDM. For more details: https://hsivonen.fi/eme/ https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/ https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/ Bug: Main tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1015800 Link to standard: https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html This spec is being implemented in IE, Safari, and Chrome. MS and Google are actively participating in the W3C working group; public-html-media. Blink's Intent To Implement: http://bit.ly/1mnELkX Platform coverage: Firefox on desktop. Estimated or target release: Firefox 36. Preference behind which this will be implemented: media.eme.enabled ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Policing dead/zombie code in m-c
Sorry, I only now discovered this thread. Below are replies to many of the issues raised with regards to the work I did adding ICU and the ECMAScript Internationalization API early last year. A lot of background information is in this document (no longer fully up to date): http://lindenbergsoftware.com/mozilla/implementation.html and in Jeff’s more current one: https://wiki.mozilla.org/User:Waldo/Internationalization_API On Apr 24, 2014, at 5:31 , Henri Sivonen hsivo...@hsivonen.fi wrote: * Are we building and shipping dead code in ICU on B2G? B2G doesn’t have ICU and the internationalization API yet: https://bugzilla.mozilla.org/show_bug.cgi?id=866301 …but of course that’s only a short-term fix. On Apr 24, 2014, at 11:31 , ISHIKAWA,chiaki ishik...@yk.rim.or.jp wrote: There is at least some code in ICU that is - used by FF, but - not used by TB. As far as I know, the ECMAScript Internationalization API is so far only enabled for desktop Firefox. On Apr 24, 2014, at 5:49 , Till Schneidereit t...@tillschneidereit.net wrote: One idea was to slim down the ICU build and get rid of some things not needed for Intl. I might very well be mistaken, but I'm not aware of this having happened. It did happen. ICU has a number of build flags that can be used to reduce code and data size. I used the applicable subset to shrink the binary size to less than half of the size of a full ICU build. Mozilla doesn’t even have the full set of ICU source files – the import script drops the sources for encoding mappings, break iterators, language names and much else. http://mxr.mozilla.org/mozilla-central/source/build/autoconf/icu.m4#145 http://mxr.mozilla.org/mozilla-central/source/build/autoconf/icu.m4#213 http://mxr.mozilla.org/mozilla-central/source/intl/update-icu.sh#32 On Apr 24, 2014, at 16:03 , Ehsan Akhgari ehsan.akhg...@gmail.com wrote: ... We build and ship *all* of ICU, and presumably ship a tiny portion of it. We don’t – see above. This is at least in part due to bug 915735, you can go and read the bug to see that I did the best I could there, given the constraints that I had (not understanding how the magic of the interaction of ICU and our build system worked, not understanding which parts of ICU we actually want to use, the performance and code quality limitations of MSVC's PGO compiler, the fact that increasing the amount of time we allow our builds to progress is rocket science, etc. I don’t have numbers for this change specifically, but during my investigation I found that on Mac statically linking ICU into libmozjs reduced the binary size by almost 600KB, compared to building ICU as a separate DLL. On Apr 25, 2014, at 0:31 , Henri Sivonen hsivo...@hsivonen.fi wrote: Therefore, it looks like we should turn off (if we haven't already): * The ICU LayoutEngine. * Ustdio * ICU encoding converters and their mapping tables. * ICU break iterators and their data. * ICU transliterators and their data. All done, except for a few remaining encoding converters: However, that flag is misdesigned in the sense that it considers US-ASCII, ISO-8859-1, UTF-7, UTF-32, CESU-8, SCSU and BOCU-1 as non-legacy, even though, frankly, those are legacy, too. (UTF-16 is legacy also, but it's legacy we need, since both ICU and Gecko are UTF-16 legacy code bases!) http://mxr.mozilla.org/mozilla-central/source/intl/icu/source/common/unicode/uconfig.h#267 UTF-16 may be legacy from the point of view of encoding HTML pages, but otherwise it’s an essential part of most of today’s computing environments – and the alternative in many cases would be UTF-32. But at least four of the above are clearly obsolete. Also, If the ICU build system is an configurable enough, I think we should consider identifying what parts of ICU we can delete even though the build system doesn't let us to and then automate the deletion as a script so that it can be repeated with future imports of ICU. That seems worth investigating, but getting the build system to strip out as much as possible might be more effective – see the next item. On Apr 25, 2014, at 8:12 , Trevor Saunders trev.saund...@gmail.com wrote: Well, it really depends how you approach the problem of finding code thats dead. One way is to decide code really should be dead by reading it and knowing what it accomplishes doesn't matter. Another is to prove to your self that code is unreachable and so can be removed without effecting anything. Both of these require a pretty good bit of knowledge and skill. On the other hand the below question prompts another approach. Is there a way to give the linker a list of functions that you want to have as public entry points of a dynamically linked library, and have it strip out everything that can’t be reached from these functions? That’s essentially what happens when you statically link a library into another, and the list of ICU functions that Mozilla code calls wouldn’t be
