Re: Monitoring software being installed on performance test machines
Looking forward to this. We've had bimodal results for a while now (bug 90), which we think might be CPU throttling due to heat. Such tooling could help confirm or reject this hypothesis. -avih ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Debugging armv6 test failures
Is armv6 a tier 1 platform? Who can help with debugging test failures that only happen on armv6? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
nsGUIEvent.h related stuff has been sorted out
Hello. I'd like to share the information about new event related stuff in Gecko. nsGUIEvent.h defined and implemented all events (except nsMutationEvent). Additionally, it's included by a lot of files including some headers. So, this caused changes in the header needing to waste long time for rebuilding Gecko. For fixing this issues, now, nsGUIEvent.h is separated to following files and nsGUIEvent.h has been removed. * widget/BasicEvents.h * widget/ContentEvents.h * widget/MiscEvents.h * widget/MouseEvents. * widget/TextEvents.h * widget/TextRange.h * widget/TouchEvents.h And content/events/public/nsMutationEvent.h is renamed to: * content/events/public/MutationEvent.h These files are exported under mozilla. So, when you need to include some of them, you should write #include like: #include mozilla/BasicEvents.h FYI: BasicEvent.h is included by the other header files. So, you don't need to include if directly if you've already included one of the others. If you need forward declaration of event class or related stuff, you should *not* do it yourself. Instead of that you should add: #include mozilla/EventForwards.h Actual file of it is widget/EventForwards.h which has all event classes' forward declaration and related structs' forward declaration. Additionally, it defines nsEventStatus, mozilla::Modifiers and mozilla::KeyNameIndex. Please don't include mozilla/*Events.h files from header file directly as far as possible! Additionally, the event names have been completely sorted out. See following list for the detail: BasicEvents.h * nsEvent - mozilla::WidgetEvent * nsGUIEvent - mozilla::WidgetGUIEvent * nsInputEvent - mozilla::WidgetInputEvent * nsUIEvent - mozilla::InternalUIEvent ContentEvents.h * nsScriptErrorEvent - mozilla::InternalScriptErrorEvent * nsScrollPortEvent - mozilla::InternalScrollPortEvent * nsScrollAreaEvent - mozilla::InternalScrollAreaEvent * nsFormEvent - mozilla::InternalFormEvent * nsClipboardEvent - mozilla::InternalClipboardEvent * nsFocusEvent - mozilla::InternalFocusEvent * nsTransitionEvent - mozilla::InternalTransitionEvent * nsAnimationEvent - mozilla::InternalAnimationEvent MiscEvents.h * nsContentCommandEvent - mozilla::WidgetContentCommandEvent * nsCommandEvent - mozilla::WidgetCommandEvent * nsPluginEvent - mozilla::WidgetPluginEvent MouseEvents.h * nsMouseEvent_base - mozilla::WidgetMouseEventBase * nsMouseEvent - mozilla::WidgetMouseEvent * nsDragEvent - mozilla::WidgetDragEvent * nsMouseScrollEvent - mozilla::WidgetMouseScrollEvent * mozilla::widget::WheelEvent - mozilla::WidgetWheelEvent TextEvents.h * nsAlternativeCharCode - mozilla::AlternativeCharCode * nsKeyEvent - mozilla::WidgetKeyboardEvent * nsCompositionEvent - mozilla::WidgetCompositionEvent * nsQueryContentEvent - mozilla::WidgetQueryContentEvent * nsSelectionEvent - mozilla::WidgetSelectionEvent TextRange.h * nsTextRangeStyle - mozilla::TextRangeStyle * nsTextRange - mozilla::TextRange * nsTextRangeArray - mozilla::TextRangeArray TouchEvents.h * nsGestureNotifyEvent - mozilla::WidgetGestureNotifyEvent * nsSimpleGestureEvent - mozilla::WidgetSimpleGestureEvent * nsTouchEvent - mozilla::WidgetTouchEvent MutationEvent.h * nsMutationEvent - mozilla::InternalMutationEvent The naming rules of them are: 1. Defined in mozilla namespace. 2. Use prefix Widget or Internal. If the event is dispatched from widget/, use Widget. Otherwise, i.e., generated by content/, layout/ or something others, use Internal. Next, event classes now have vtable. I.e., they have virtual destructor. Therefore, even if you create an instance and stores it in a pointer of its superclass, you don't mind to cast the pointer type to the actual class. For example, WidgetEvent* event = new WidgetKeyboardEvent(...); delete event; is now safe. Finally, the root class, WidgetEvent, has As*Event class. The * doesn't include the prefix. I.e., for WidgetMouseEvent, the method name is WidgetEvent::AsMouseEvent(). This returns the pointer of the instance only when the instance is the class or its derived class. Otherwise, returns nullptr. E.g., WidgetDragEvent is defines as: WidgetEvent +- WidgetGUIEvent +- WidgetInputEvent +- WidgetMouseEventBase +- WidgetMouseEvent +- WidgetDragEvent If an instance is WidgetDragEvent, AsGUIEvent(), AsInputEvent(), AsMouseEventBase(), AsMouseEvent() and AsDragEvent() returns its pointer. The other As*Event() methods return nullptr. You should not use static_cast for Widget*Event and Internal*Event anymore because it may cause wrong casting bug with some mistakes (actually, there was such bug!). I hope this change makes you happy! -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
Mike Hommey wrote: On Tue, Oct 22, 2013 at 10:06:13AM +0100, Neil wrote: David Rajchenbach-Teller wrote: Wouldn't it be interesting to also have a ./mach build frontend that repackages XUL and js code? Does ./mach build chrome work? make chrome/mach build chrome doesn't do everything that is not code, sadly. I guess it depends on which js code; from the mention of XUL I was assuming anything with a chrome: URL. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Debugging armv6 test failures
On 10/23/2013 3:11 AM, Kyle Huey wrote: Is armv6 a tier 1 platform? Who can help with debugging test failures that only happen on armv6? Yes, AIUI. Note that we're not running armv6 tests on armv6 hardware, so you should be able to reproduce test failures by running the armv6 builds on whatever Android hardware you have lying around. (If that doesn't work, you can always request a loaner pandaboard from RelEng.) -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
At the moment, there is no good way to do what you need. The only solution I can think of would be to configure your popup to be in private browsing mode. Would that work for you? On 10/23/13 2:33 AM, Ehsan Akhgari wrote: On 2013-10-22 12:52 PM, Matthew Gertner wrote: I am trying to close a popup browser.xul window during Firefox shutdown so that it won't get loaded on restart by the session saver. I close the window before the browser shuts down (e.g. on quit-application-requested) but it is still opened when I start the browser again. After trawling through SessionStore.jsm, it looks like the problem is that the session store freezes the session on quit-application-requested so that it doesn't accidently lose windows that are closed as a normal part of the shutdown process. It wasn't immediately obvious to me how to circumvent this behavior. The only idea I have is to grab the state with SessionStore.getBrowserState(), remove my window manually and then set it back with SessionStore.setBrowserState(). Is there an easier way to do this? That won't work well, since it will close all but one of the windows and tabs and reopen them all again. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
On Wednesday, October 23, 2013 2:36:12 PM UTC+2, David Rajchenbach-Teller wrote: At the moment, there is no good way to do what you need. The only solution I can think of would be to configure your popup to be in private browsing mode. Would that work for you? That might be a good solution. The side effects (not adding the page to history, etc.) are probably things we want anyway. Should I file a bug about this? It seems to me that it should be possible to close a window during shutdown without it being restored on restart. The most flexible option might be an API to cause a window to opt out of session saving completely. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: how long are we continuing 32-bit OS X support?
Releng note: if we stop it, we could also get much better test capacity on tbpl as we could re-purpose our 10.6 test infrastructure. cheers, Armen On 2013-10-21 1:14 PM, Ehsan Akhgari wrote: Note that we also use this to support 32-bit plugins, so our target audience is not just 10.6 users. Cheers, Ehsan On 2013-10-21 11:24 AM, Nathan Froyd wrote: [Not sure if this is strictly dev-platform material; dev-planning might have been more appropriate in some respects.] Our Firefox builds for OS X currently build a 32-bit version, a 64-bit version, and then squash those together to produce a universal binary that runs on 32-bit or 64-bit systems, as appropriate. This method of building is somewhat wasteful, as we're building a decent chunk of stuff (chrome JS, etc.) that is architecture independent. When targeting OS X, native or cross, clang supports compiling for multiple architectures in a single pass. Being able to use this capability would likely speed up our TBPL OS X builds somewhat. (Slowdown in actual compilation would likely be compensated for by not having to build chrome jars twice, install headers twice, etc. etc.) However, a variety of issues block being able to do this, mostly related to a number of places the code where decisions are made based on whether configure thought we're compiling for a 32-bit or 64-bit architecture. I've started poking at some of these issues (bug 925167 and dependents if you're interested). But various people have pointed out that it only makes sense to devote resources to this if we're going to be keeping 32-bit OS X support alive for some time to come. Otherwise, we can just wait a short amount of time for 32-bit support to be dropped and these issues go away. How long do we intend to continue shipping a 32-bit Firefox binary on OS X? As I understand it, we're doing this solely for our OS X 10.6 users, as they are the only ones potentially running OS X on non-64-bit capable machines. -Nathan ___ 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: C++ Standards Committee meeting next week
There is a Reflection Study Group (a sub-group of the Committee which focuses on a particular area) which is tasked with investigating language and library extensions for compile-time and runtime reflection. The majority of the interest so far has been for compile-time reflection, but I believe some of the infrastructure for compile-time reflection will enable runtime reflection as well. The Reflection Study Group met in Chicago last week, and talked about a rough outline of the sorts of things C++ programmers would like to be able to do with reflection, from straightforward things like iterating over the members of a class at compile-time for purposes such as serialization and equality comparison, to more sophisticated things like synthesizing new types by transforming existing types. I believe the plan is to issue a call for proposals, with some guidance about the general direction that is desired, derived from that outline. The Study Group will then look at the proposals at future meetings and provide feedback, with the aim of converging towards a cohesive set of proposals to present to the Committee at large. Since this is a very broad area to explore, I believe the Study Group is initially interested particularly in proposals that provide infrastructure that compile-time reflection features can be built on top of. This should become more clear when the call for proposals is issued. The call for proposals has now been posted. It can be found here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3814.html It states that all reflection-related proposals will be considered, but the focus is on compile-time reflection, and gives a list of focus areas and representative use cases. Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
Yes, please do. There's a component Session Restore. Cheers, David On 10/23/13 2:39 PM, Matthew Gertner wrote: On Wednesday, October 23, 2013 2:36:12 PM UTC+2, David Rajchenbach-Teller wrote: At the moment, there is no good way to do what you need. The only solution I can think of would be to configure your popup to be in private browsing mode. Would that work for you? That might be a good solution. The side effects (not adding the page to history, etc.) are probably things we want anyway. Should I file a bug about this? It seems to me that it should be possible to close a window during shutdown without it being restored on restart. The most flexible option might be an API to cause a window to opt out of session saving completely. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsGUIEvent.h related stuff has been sorted out
On 2013-10-23 3:18 AM, Masayuki Nakano wrote: I hope this change makes you happy! Thanks for doing this! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsGUIEvent.h related stuff has been sorted out
On 23/10/2013 09:18, Masayuki Nakano wrote: I hope this change makes you happy! It does - this is great stuff! Thank you for all your work on this! -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
Matthew Gertner wrote: The most flexible option might be an API to cause a window to opt out of session saving completely. Probably not relevant to you but on SeaMonkey the secret sauce to opting out of session saving is to remove the windowtype attribute very early on (onload handler is early enough I think). -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
W3C Proposed Recommendation: CSS Style Attributes
CSS Style Attributes is a W3C proposed recommendation: http://www.w3.org/TR/css-style-attr This means the W3C membership (including Mozilla) has the chance to vote on its advancement to Recommendation. I currently intend to vote in support, without comments. If there are any comments or objections you think Mozilla should make, please bring them up in this thread. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing a window from the session store
On 2013-10-23 8:39 AM, Matthew Gertner wrote: On Wednesday, October 23, 2013 2:36:12 PM UTC+2, David Rajchenbach-Teller wrote: At the moment, there is no good way to do what you need. The only solution I can think of would be to configure your popup to be in private browsing mode. Would that work for you? That might be a good solution. The side effects (not adding the page to history, etc.) are probably things we want anyway. That's not really gonna work well if you actually want the tab to be in private mode, since there are some parts of our code which cannot correctly handle private tabs in non-private windows. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
