Re: B2G emulator issues
On Tuesday, April 8, 2014 11:45:15 PM UTC+8, Mike Habicher wrote: In my experience running tests locally, a single mochitest run on the ARM emulator (hardware: Thinkpad X220, 16GB RAM, SSD) where everything was built with 'B2G_DEBUG=0 B2G_NOOPT=0' will run in 2 to 3 minutes. The same test, run with 'B2G_DEBUG=1 B2G_NOOPT=0' will take 7 to 10 minutes. --m. It could be the same problem as Bug 1012516. test_media_selection.html can take up to 1025454ms on B2G ICS Emulator Debug. MediaManager will GC after finishing each token and this test has 90 tokens. It takes 10s * 90 = 900s in GC. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OMTC on Windows
Hi all, for a couple of days on Nightly, I am seeing an increasing number of WM_GETOBJECT message response failures, causing in intermittent accessibility failures. I know for a fact that nothing in our code changed recently that could cause this, so I was wondering if OMTC could be responsible? Marco On 22.05.2014 22:22, Girish Sharma wrote: On Fri, May 23, 2014 at 1:51 AM, Bas Schouten bschou...@mozilla.com mailto:bschou...@mozilla.com wrote: bug 1012213 Yup, looks like that only. Thanks for the bug. -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur ___ release-drivers mailing list release-driv...@mozilla.org https://mail.mozilla.org/listinfo/release-drivers ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OMTC on Windows
For reference -- if this is applicable --, these failures are tracked in bug 1014673: https://bugzilla.mozilla.org/show_bug.cgi?id=1014673 Marco On 23.05.2014 09:10, Marco Zehe wrote: Hi all, for a couple of days on Nightly, I am seeing an increasing number of WM_GETOBJECT message response failures, causing in intermittent accessibility failures. I know for a fact that nothing in our code changed recently that could cause this, so I was wondering if OMTC could be responsible? Marco On 22.05.2014 22:22, Girish Sharma wrote: On Fri, May 23, 2014 at 1:51 AM, Bas Schouten bschou...@mozilla.com mailto:bschou...@mozilla.com wrote: bug 1012213 Yup, looks like that only. Thanks for the bug. -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur ___ release-drivers mailing list release-driv...@mozilla.org https://mail.mozilla.org/listinfo/release-drivers ___ release-drivers mailing list release-driv...@mozilla.org https://mail.mozilla.org/listinfo/release-drivers ___ 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 Thu, May 22, 2014 at 1:50 PM, Kip Gilbert kgilb...@mozilla.com wrote: Link to standard: http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property How will scroll-behavior: instant work on platforms that use APZ? I worry about authors expect it to enable them to do a bunch of DOM mutations and then set the scroll position and allow them to be sure that rendering can't happen of the new DOM but at the old scroll position (or the old DOM but at the new scroll position). Can we promise that when using APZ? One use case that has come up for us in FirefoxOS is the ability to add a few elements to the top of a page, shifting down the contents of the page, but then make that transparent to the user by adjusting the scroll position accordingly. That isn't possible with APZ since the user might be actively scrolling and so if we just do something like div.scrollTop += hightOfNewContent; then the newly set scroll position will be based off of an old value which has already changed on the compositing thread. Basically we need an API like div.addToScrollPosition(hightOfNewContent); This would allow the browser to send this delta to the compositing thread along with the newly updated painting of the DOM. I wonder if we need something similar for smooth-scrolling. So rather than a CSS property, have something like something like: div.smoothScrollTo(pos, n); // does a smooth scroll over n ms. div.setScrollPosition(pos); // ensures that the next time we paint, we paint at scroll position pos div.immediatelyScrollTo(pos); // sends a signal immediately to the composition thread to jump to pos, possibly before any painting has happened. I'm not sure if this one has use cases. / Jonas ___ 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 5/23/2014 6:12 AM, Jonas Sicking wrote: That isn't possible with APZ since the user might be actively scrolling and so if we just do something like div.scrollTop += hightOfNewContent; then the newly set scroll position will be based off of an old value which has already changed on the compositing thread. Basically we need an API like div.addToScrollPosition(hightOfNewContent); This would allow the browser to send this delta to the compositing thread along with the newly updated painting of the DOM. Would this allow us to avoid the sync reflow currently required with the scrollTop approach as well? It would seem the platform would not need to calculate an exact position in order to apply a delta like this. Ben ___ 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 Fri, May 23, 2014 at 10:12 PM, Jonas Sicking jo...@sicking.cc wrote: How will scroll-behavior: instant work on platforms that use APZ? I worry about authors expect it to enable them to do a bunch of DOM mutations and then set the scroll position and allow them to be sure that rendering can't happen of the new DOM but at the old scroll position (or the old DOM but at the new scroll position). Can we promise that when using APZ? Yes. Of course, the user can scroll in such a way that the content is never visible at the new scroll position, but we can ensure that the DOM changes and the scroll position change happen atomically. Note that instant is our current behavior for all scripted scroll position changes. One use case that has come up for us in FirefoxOS is the ability to add a few elements to the top of a page, shifting down the contents of the page, but then make that transparent to the user by adjusting the scroll position accordingly. That isn't possible with APZ since the user might be actively scrolling and so if we just do something like div.scrollTop += hightOfNewContent; then the newly set scroll position will be based off of an old value which has already changed on the compositing thread. Basically we need an API like div.addToScrollPosition(hightOfNewContent); On the viewport, we have scrollBy. CSSOM doesn't define that on elements but it should. I guess they should both take an optional ScrollOptions parameter. div.smoothScrollTo(pos, n); // does a smooth scroll over n ms. Better to not take a duration parameter if there isn't a clear use-case. (Or is there?) div.setScrollPosition(pos); // ensures that the next time we paint, we paint at scroll position pos scrollLeft/scrollTop do this. Though I think elements should have the same scrollTo method that Window does, as well. div.immediatelyScrollTo(pos); // sends a signal immediately to the composition thread to jump to pos, possibly before any painting has happened. I'm not sure if this one has use cases. Then let's not add it :-) 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
Will we ever get element queries in browsers?
I was just thinking about element queries[1] again, recalling all the discussion on it from some time ago. Has thinking on this advanced at all in more recent times? Do you think we’ll ever see element queries native in browsers? Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills [1] http://www.smashingmagazine.com/2013/06/25/media-queries-are-not-the-answer-element-query-polyfill/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Will we ever get element queries in browsers?
On 23/05/2014 15:23 , Chris Mills wrote: I was just thinking about element queries[1] again, recalling all the discussion on it from some time ago. Has thinking on this advanced at all in more recent times? Do you think we’ll ever see element queries native in browsers? There clearly is demand and people are thinking about the problem, so if it's solvable in an acceptable way I don't why it wouldn't eventually work out. http://discourse.specifiction.org/t/element-queries/26 -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Follow up on clang-format
I tried using clang-format on entire files and I noticed two things (there might be others, I didn't look too closely): 1) When it reformats comments to fit in the line length, it just inserts linebreaks rather than rewrapping the text. So you end up with text like this, where the last couple of words get wrapped onto the next line. 2) It didn't handle things like MOZ_BEGIN_NESTED_ENUM_CLASS properly. I was just using -style=Mozilla and maybe that's not the right thing to use? I also don't know how much leeway we have to modify what it does for cases like these. kats On 22/5/2014, 21:29, Anthony Jones wrote: Some of you may remember the discussion on clang-format and the `mach clang-format` command. What we have in place right now is very temporary but it is functional enough to give it a try. I have not put the effort into upstreaming my changes. Depending on the feedback I receive I will either: * Finish my existing changes and upstream them * Remove the `mach clang-format` command altogether * Do nothing I have personally found it useful. However I would like to hear from other people who have tried it to help me decide what to do next. Anthony ___ 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 23/5/2014, 6:12, Jonas Sicking wrote: Basically we need an API like div.addToScrollPosition(hightOfNewContent); This would allow the browser to send this delta to the compositing thread along with the newly updated painting of the DOM. This is certainly a valid use case, and it has come up before. We have bug 959793 on file for tracking this issue. However I tend to think it is a separate problem from what this spec is trying to address (i.e. scroll to a specific scroll offset, but smoothly). kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
