Re: Using a pre-processing flag to auto-disable features in later Beta versions
On Fri 19 Apr 2013 04:27:22 PM PDT, Asa Dotzler wrote: > On 4/19/2013 4:04 PM, Robert O'Callahan wrote: >> On Sat, Apr 20, 2013 at 10:34 AM, Asa Dotzler wrote: >> >>> That would be great -- if we had a significantly larger Aurora >>> population.. >>> Right now, the only way to get anything close to decent "did we >>> break the >>> web" testing is on our Beta channel. >>> >> >> I think Daniel was concerned about user-visible features (and I agree >> with >> that concern). >> >> If we're only going to use this flag for "does this break the Web" >> tests, >> where we expect/hope users will not notice, that sounds fine to me, >> as long >> as we stick to that rule. >> >> Rob > > I don't think it's that black and white. PDF.js and our new Cookie > policy are both user facing features and web compat concerns that need > a crap ton of compat testing. Shumway will be the same. So may some > security features like mixed content blocking, plug-in click-to-play, > etc. I've though about this some due to some experimental features I've landed and wanted auto-disabled in beta (but mine were fine being disabled at the beta boundary.) Is there really a group of things that should all share the exact same timing? I could imagine some of them wanting a single day on beta, others at least a week or three. Explicitly backing them out of beta is already possible and brings the most flexibility, but (1) is a bit of a pain and sometimes hard to remember to do at the right moment, and (2) is under the control of devs more than release drivers. Has it been decided that #2 is desired for these sorts of things? That seems totally plausible to me; they're probably the right people to make these decisions. I'm still skeptical that all these features want to be disabled at the same time. If the desire is to put things under release driver control, you could still do a per-feature #ifdef that releng can toggle in the mozconfigs or something. Anyway, I don't have a robot chicken in this fight. Just wanted to share my thoughts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using a pre-processing flag to auto-disable features in later Beta versions
On Sat, Apr 20, 2013 at 11:27 AM, Asa Dotzler wrote: > I don't think it's that black and white. PDF.js and our new Cookie policy > are both user facing features and web compat concerns that need a crap ton > of compat testing. Hmm, PDF.js yes, maybe click to play too. But for cookie policy, Shumway, and mixed content blocking, the goal is to minimize user impact. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q" ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using a pre-processing flag to auto-disable features in later Beta versions
On 4/19/2013 4:04 PM, Robert O'Callahan wrote: On Sat, Apr 20, 2013 at 10:34 AM, Asa Dotzler wrote: That would be great -- if we had a significantly larger Aurora population.. Right now, the only way to get anything close to decent "did we break the web" testing is on our Beta channel. I think Daniel was concerned about user-visible features (and I agree with that concern). If we're only going to use this flag for "does this break the Web" tests, where we expect/hope users will not notice, that sounds fine to me, as long as we stick to that rule. Rob I don't think it's that black and white. PDF.js and our new Cookie policy are both user facing features and web compat concerns that need a crap ton of compat testing. Shumway will be the same. So may some security features like mixed content blocking, plug-in click-to-play, etc. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using a pre-processing flag to auto-disable features in later Beta versions
On Sat, Apr 20, 2013 at 10:34 AM, Asa Dotzler wrote: > That would be great -- if we had a significantly larger Aurora population. > Right now, the only way to get anything close to decent "did we break the > web" testing is on our Beta channel. > I think Daniel was concerned about user-visible features (and I agree with that concern). If we're only going to use this flag for "does this break the Web" tests, where we expect/hope users will not notice, that sounds fine to me, as long as we stick to that rule. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q" ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using a pre-processing flag to auto-disable features in later Beta versions
On 4/19/2013 3:17 PM, Daniel Holbert wrote: Would this mean that Beta-channel users would see some features appear on release-day, and then disappear a couple weeks later, and then those same features (plus maybe some new ones) would suddenly reappear on the next release day, and then potentially disappear again? (etc) This seems like it could be a bit unsettling & frustrating for those users, unless I'm misunderstanding. If we're planning up-front to switch something off before it hits release, I think it's saner to do it at a channel-boundary (as we did in e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=814530 ). That way, a user on a given channel will have a consistent experience. ~Daniel That would be great -- if we had a significantly larger Aurora population. Right now, the only way to get anything close to decent "did we break the web" testing is on our Beta channel. - A On 04/18/2013 01:03 PM, Lukas Blakk wrote: Hello, I'm following up on an action from our Firefox 20 Post-Mortem where it was discussed that it would be helpful to have a way to pref on a set of features that want to be in early Beta builds to garner feedback and audience reach but should not ship since they are not ready for public consumption. Briefly reaching out on #developers identified that we could use a pre-processing flag in mozconfigs for early betas, something like #ifdef EARLY_BETA_ONLY_FEATURE in which case it seems to me the actions needed would be: * Create and publicize to engineering & product teams the location for listing feature prefs that need enabling in early beta, but should not ship * Create the EARLY_BETA_ONLY_FEATURE flag and make sure it enables those prefs accordingly until we no longer include them in later beta mozconfigs * Releng automation to switch/edit mozconfigs for earlier betas to check for this flag Thoughts? Feedback? People willing to take on any of these items? I'll file bugs on them soon once we've hashed out the best way to do this. Cheers, Lukas *-*-*-*-*-* Release Manager, Mozillian mozillians.org/lsblakk ___ 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: Using a pre-processing flag to auto-disable features in later Beta versions
Would this mean that Beta-channel users would see some features appear on release-day, and then disappear a couple weeks later, and then those same features (plus maybe some new ones) would suddenly reappear on the next release day, and then potentially disappear again? (etc) This seems like it could be a bit unsettling & frustrating for those users, unless I'm misunderstanding. If we're planning up-front to switch something off before it hits release, I think it's saner to do it at a channel-boundary (as we did in e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=814530 ). That way, a user on a given channel will have a consistent experience. ~Daniel On 04/18/2013 01:03 PM, Lukas Blakk wrote: > Hello, > > I'm following up on an action from our Firefox 20 Post-Mortem where it was > discussed that it would be helpful to have a way to pref on a set of features > that want to be in early Beta builds to garner feedback and audience reach > but should not ship since they are not ready for public consumption. > > Briefly reaching out on #developers identified that we could use a > pre-processing flag in mozconfigs for early betas, something like #ifdef > EARLY_BETA_ONLY_FEATURE in which case it seems to me the actions needed would > be: > > * Create and publicize to engineering & product teams the location for > listing feature prefs that need enabling in early beta, but should not ship > * Create the EARLY_BETA_ONLY_FEATURE flag and make sure it enables those > prefs accordingly until we no longer include them in later beta mozconfigs > * Releng automation to switch/edit mozconfigs for earlier betas to check for > this flag > > Thoughts? Feedback? People willing to take on any of these items? I'll > file bugs on them soon once we've hashed out the best way to do this. > > Cheers, > Lukas > *-*-*-*-*-* > Release Manager, Mozillian > mozillians.org/lsblakk > > > > > > > ___ > 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: Rendering meeting, Monday at 2:30 PM US/Pacific
Reminder: rendering meeting this coming Monday! See below. 2013/4/13 Benoit Jacob > Hello, > > The next Rendering meeting will take place *not* this Monday, but on > Monday April 22 at 2:30 PM US/Pacific time. That could be Tuesday in your > timezone. > > The Rendering meeting is about all things Gfx, Image, Layout, and Media. > It is expected to take place every second Monday. This week is a little > exception. > > Please first add your agenda items there: > > https://wiki.mozilla.org/Platform/GFX/2013-April-22 > > * Every second Monday at 2:30 PM Pacific Time > * +1 650 903 0800 x92 Conf# 99366 > * +1 416 848 3114 x92 Conf# 99366 > * +1 800 707 2533 (pin 369) Conf# 99366 (toll free, Skype) > * Video (Vidyo) link: > https://v.mozilla.com/flex.html?roomdirect.html&key=vu1FKlkBlT29 > * Vidyo room 9366 (if you have LDAP and can log in at > https://v.mozilla.com) > > See you, > Benoit > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revamping touch input on Windows
On 04/18/2013 03:50 PM, Jim Mathies wrote: We have quite a few issues with touch enabled sites on Windows. [1] Our support for touch stretches back to when we first implemented MozTouch events which over time has morphed into a weird combination of W3C touch / simple gestures support. It is rather messy to fix, but I'd like to get this cleaned up now such that we are producing a reliable stream of events on all Windows platforms we support touch on. (This includes Win7 and Win8, and Metro.) We are constrained by limitations in the way Windows handles touch input on desktop and our own implementation. For the desktop browser, there are two different Windows event sets we can work with which are implemented in Windows such that they are mutually exclusive - we can receive one type or the other, but not both. The two event sets are Gesture and Touch. The switch we use to decide which to process is based on a call to nsIWidget's RegisterTouchWindow. If RegisterTouchWindow has not been called we consume only Windows Gesture events which generate nsIDOMSimpleGestureEvents (rotate, magnify, swipe) and pixel scroll events. s/pixel scroll/wheel/ these days, right? For the specific case of panning content widget queries event state manager's DecideGestureEvent to see if the underlying element wants pixel scroll / pan feedback. [2] Based on the returned panDirection we request certain Gesture events from Windows and send pixel scroll accordingly. If the underlying element can't be panned in the direction the input is in, we opt out of receiving Gesture events and fall back on sending simple mouse input. (This is why you'll commonly get selection when dragging your finger horizontally across a page.) On the flip side, if the DOM communicates the window supports touch input through RegisterTouchWindow, we bypass all Gesture events and instead request Touch events from Windows. In this case we do not fire nsIDOMSimpleGestureEvents, mouse, or pixel scroll events and instead fire W3C compliant touch input. We do not call DecideGestureEvent, and we do not generate pan feedback on the window. You can see this behavior using a good W3C touch demo. [3] One of the concerns here is that since we do not differentiate the metro and desktop browsers via UA, the two should emulate each other closely. The browser would appear completely broken to content if the same UA sent two different event streams. So we need to take into account how metrofx works as well. With metrofx we can differentiate between mouse and touch input when we receive input, so we split the two up and fire appropriate events for each. When receiving mouse input, we fire standard mouse events. When receiving touch input, we fire W3C touch input and nsIDOMSimpleGestureEvents. We also fire mouse down/mouse up (click) events from touch so taps on the screen emulate clicking the mouse. Metrofx ignores RegisterTouchWindow, never queries DecideGestureEvent, and does not fire pixel scroll events. Panning of web pages is currently handled in the front end via js in response to W3C touch events, which I might note is not as performant as desktop's pixel scroll handling. In time this front end handling will hopefully be replaced by async pan zoom which lives down in the layers backend. Note that the metrofx front end makes very little use of nsIDOMSimpleGestureEvents, the only events we use are left/right swipe events for navigation. If we chose we could ignore these and not generate nsIDOMSimpleGestureEvents at all. [4] To clean this up, I'd like to propose the following: 1) abandon generating nsIDOMSimpleGestureEvents on Windows for both backends when processing touch input from touch input displays.* This would mean that if the desktop front end wants to do something with pinch or zoom, it would have to process W3C touch events instead. Note that we could still fire simple gestures from devices like track pads. But for touch input displays, we would not support these events. Sounds ok to me. SimpleGestureEvents were originally for (OSX) touchpad case only anyway. * There's one exception to this in metro, we would continue to fire MozEdgeUIGesture. [5] We should perhaps then call it something else than SimpleGestureEvent 2) Rework how we process touch events in Windows widget such that: * Both backends respect RegisterTouchWindow and only fire W3C events when it is set. * If RegisterTouchWindow has been called: ** Send touchstart and the first touchmove and look at the return results. ** If either of these returns eConsumeNoDefault, continue sending W3C events only. No mouse or pixel scroll events would be sent. ** If both of these events do not return eConsumeNoDefault: *** Abandon sending W3C touch events. *** Generate pixel scroll events in the appropriate direction based on DecideGestureEvent, or simple mouse events if DecideGestureEvent indicates scrolling isn't possible. Feedback welcome on this approach.
Re: Using a pre-processing flag to auto-disable features in later Beta versions
Johnathan and I also spoke about this last week, and we were going to sync up with Gavin to work out details and find an owner for channel-specific preference enables/disables. We'd only discussed having Nightly-only, up to Aurora, and up to Beta. Up to early beta is a good addition. Let me set up a meeting now (I'll include you and gps as well, given his interest :) -Alex On Apr 18, 2013, at 10:03 PM, Lukas Blakk wrote: > Hello, > > I'm following up on an action from our Firefox 20 Post-Mortem where it was > discussed that it would be helpful to have a way to pref on a set of features > that want to be in early Beta builds to garner feedback and audience reach > but should not ship since they are not ready for public consumption. > > Briefly reaching out on #developers identified that we could use a > pre-processing flag in mozconfigs for early betas, something like #ifdef > EARLY_BETA_ONLY_FEATURE in which case it seems to me the actions needed would > be: > > * Create and publicize to engineering & product teams the location for > listing feature prefs that need enabling in early beta, but should not ship > * Create the EARLY_BETA_ONLY_FEATURE flag and make sure it enables those > prefs accordingly until we no longer include them in later beta mozconfigs > * Releng automation to switch/edit mozconfigs for earlier betas to check for > this flag > > Thoughts? Feedback? People willing to take on any of these items? I'll > file bugs on them soon once we've hashed out the best way to do this. > > Cheers, > Lukas > *-*-*-*-*-* > Release Manager, Mozillian > mozillians.org/lsblakk > > > > > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
