133112 2014-05-20 01:54:04 -0700 Touch-action css property support 2019-10-03 09:33:58 -0700 1 1 1 Unclassified WebKit UI Events 528+ (Nightly build) Unspecified Unspecified RESOLVED CONFIGURATION CHANGED https://bugs.webkit.org/show_bug.cgi?id=175869 https://bugs.webkit.org/show_bug.cgi?id=193447 FromImplementor, InRadar P2 Normal --- 149854 1 j.tangelder graouts 50167214 andrew benjamin contact dino eoconnor froodian graouts gtjrossi huijing jouni jrossi j.tangelder marco.lazzeri marsjaninzmarsa michael.herzog mjs orzage plummer.andrew rbyers redux rich.g.cook shmdhussain12 simon.fraser tobi webkit-bug-importer webkit webkit wenson_hsieh oldest_to_newest 1010432 0 j.tangelder 2014-05-20 01:54:04 -0700 What about supporting the touch-action property of the pointer events specification? IE, Blink already support this, and Mozilla is busy implementing it. https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-touch-action-css-property Even when pointer events are not implemented, this css property would really improve the support for touch gestures in webpages. Now we're stuck with only calling preventDefault, and often makes elements blocking the scrolling of a page when not needed... (copied from https://bugs.webkit.org/show_bug.cgi?id=105463#c35) 1010443 1 redux 2014-05-20 02:53:32 -0700 hah, seems Jorik beat me to it. feel free to de-dup between this and https://bugs.webkit.org/show_bug.cgi?id=133114 1010485 2 rbyers 2014-05-20 07:21:05 -0700 FYI there are several reasons we decided to add touch-action to blink. Eg. from https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/sc5lHnlcLvM/ntJWuKKHUqYJ: 1. Provides precise control over the dreaded 300ms click delay on mobile 2. Reliably enables side-swipe UIs (frees libraries from having to predict when exactly scrolling may start on different browsers) 3. Enables high-fidelity polyfills of pointer events (eg. as in Polymer) 4. Provides a declarative signal to blink (and potentially the compositor) about the developers intent wrt. touch input - eg. providing a potential solution the touchstart ACK timeout problem 5. Reducing confusion around the highly-overloaded response to preventDefault on touch events 6. A prerequisite for future optimizations to enable scrolling and zooming that never block on the main thread It's #5 that seems to resonate most with typical web developers. In particular I continue to see developers struggle with implementing side-swipe UIs (#2), and I believe mobile safari requires them to reverse-engineer a magic distance threshold number (which then imposes a compat burden on the web no to change that magic value). 1010532 3 benjamin 2014-05-20 09:59:24 -0700 *** Bug 133114 has been marked as a duplicate of this bug. *** 1010552 4 redux 2014-05-20 10:28:42 -0700 Adding this from https://bugs.webkit.org/show_bug.cgi?id=133114 here: Although there seems to be no immediate desire to implement the full Pointer Events specification (see https://bugs.webkit.org/show_bug.cgi?id=105463), it may be worth considering at least supporting the touch-action:manipulation CSS property/value. This recent addition (the "manipulation" value) to the Pointer Events specification is used - in essence - to allow developers to suppress the classic 300ms delay present on touchscreen devices that by default allows for "double-tap to zoom", while retaining other abilities such as scrolling and pinch-to-zoom. It offers a compromise to the often drastic preventDefault() commonly used in touch-optimised applications (which does remove the 300ms delay, but also kills any other default interactions). touch-action:manipulation is on track to be rolled out in both Firefox and Chrome - see "Bug 979345 - Implement "touch-action: manipulation" CSS value for Pointer Events" https://bugzilla.mozilla.org/show_bug.cgi?id=979345 "Issue 349016: Add support for touch-action: manipulation" https://code.google.com/p/chromium/issues/detail?id=349016 1010607 5 benjamin 2014-05-20 13:20:21 -0700 Some context: I do not have time to experiment with touch-action at the moment. If someone is interested in contributing patches to WebKit, I would be happy to provide guidance and reviews. Rick: some questions about the spec: -At the moment, pan-x and pan-y are pretty much useless for every use case we have. We would need the touch action to have the direction, eg. pan-positive-y/pan-negative-y or pan-y-downard/pan-y-upward. Is there anything like that in the work? -Is it specified in what coordinates system are the x/y for pan-x/pan-y? Is it in the block coordinates? Its containing block? The whole frame? The main frame? Patrick: touch-action:manipulation is basically just as bad as preventDefault() for the click delay. Touch events have raw position, mouse/click events are adjusted based on the device DPI, scale factor, finger surface, etc. For tap/click, the right thing to expose is the adjusted value, not the raw touch. The problem is touch-action:manipulation defines touch behavior, not synthetic events. The synthetic mouse events are superior to touch events for tap/click. I still welcome a real proposal to that issue (IIRC, you had opened a bug for that?). 1010617 6 redux 2014-05-20 13:43:13 -0700 "Patrick: touch-action:manipulation is basically just as bad as preventDefault() for the click delay. Touch events have raw position, mouse/click events are adjusted based on the device DPI, scale factor, finger surface, etc. For tap/click, the right thing to expose is the adjusted value, not the raw touch. The problem is touch-action:manipulation defines touch behavior, not synthetic events." Unless I'm missing something, all that touch-action:manipulation in the context of touch events would do (and I believe that's what Chrome and Mozilla are implementing/have implemented so far) is a rather fancy way of saying "don't wait 300ms for the second tap of a double-tap action". Nothing about affecting raw vs adjusted position values as far as I know. 1010618 7 redux 2014-05-20 13:51:02 -0700 "The synthetic mouse events are superior to touch events for tap/click. I still welcome a real proposal to that issue (IIRC, you had opened a bug for that?)" Yes, it's https://bugs.webkit.org/show_bug.cgi?id=122212 (where we got a bit sidetracked by the fantastic hidden feature is iOS that not even power users know about that is double-tap-to-scroll ;) ) 1010649 8 gtjrossi 2014-05-20 16:50:50 -0700 Just a couple additional thoughts/responses: Definitely agree that "synthetic" events (esp. click) are far superior for activation behaviors. Other goodness here too like better accessibility. * Note that IE11 now uses the PointerEvent interface for click and will even fire it for multi-touch provided you aren't zooming. So we don't really consider it a "synthetic" event in this regard. Like Patrick says, touch-action doesn't affect whether you a browser alters coordinate accuracy (in fact, such adjustment is out of scope for our working group) touch-action: manipulation is about restricting touch behaviors to "scrolling and continuous zooming" aka, disabling features like double-tap-to-zoom * This in turn enables browsers to optimize out the 300ms delay for synthetic events like click, but isn't technically a required feature of the API pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc. * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon. 1010659 9 benjamin 2014-05-20 17:17:09 -0700 (In reply to comment #8) > Just a couple additional thoughts/responses: Thanks for participating. > touch-action: manipulation is about restricting touch behaviors to "scrolling and continuous zooming" aka, disabling features like double-tap-to-zoom > * This in turn enables browsers to optimize out the 300ms delay for synthetic events like click, but isn't technically a required feature of the API I disagree, but that's a completely different problem. Please have a look at https://bugs.webkit.org/show_bug.cgi?id=133112. > pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc. > * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon. On OS X or iOS, we fully support scrollview-inside-scrollview. 1010672 10 gtjrossi 2014-05-20 18:29:24 -0700 >> pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc. >> * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon. >On OS X or iOS, we fully support scrollview-inside-scrollview. Not sure I follow how that relates to touch-action. IE (and Chrome/Firefox I think) supports this too. Can you explain further? 1010674 11 benjamin 2014-05-20 18:50:11 -0700 (In reply to comment #10) > >> pan-x/pan-y work well for many common "native" experiences like carousel photo galleries, swiping pagination, etc. > >> * The working group has discussed additional values like pan-positive-y/pan-negative-y. It's not in the spec or implementations, but we'd love to have you participate in the WG discussion and discuss use cases we should be solving. I'm thinking we'll tackle this in Pointer Events V2, which is on the near horizon. > > >On OS X or iOS, we fully support scrollview-inside-scrollview. > > Not sure I follow how that relates to touch-action. IE (and Chrome/Firefox I think) supports this too. Can you explain further? Let's say we would want to change all the carousels to touchAction instead of gesture recognition from touch events. Let's say the carousel start in the middle. -In that first state, only pan-y is enabled, pan-x is handled through the touch events. -You pan to the right edge. -You rubberband or stop at the edge, but either way, the last position is maxX. -Now we have two cases: -If you continue panning to the right, the superview should take the gesture and track it from there. -If you start panning in the other direction, then view takes the touch events and tracks the input. If you can specify the direction, you change change the touch-action based on the internal state of the carousel. 1010811 12 gtjrossi 2014-05-21 12:36:53 -0700 Ah, makes sense. When I use "carousel" I usually mean the ones that wrap around like the kids' ride. They're usually moving things from the beginning to the end of the scroller or vice-versa to create the illusion of a full carousel loop. So you never hit this issue and pan-x/pan-y work just fine. But, not all work this way and I agree the positive/negative values would improve the experience. Though I like a solution like CSS Scroll Snap Points to enable this to be built with native scrolling instead. "Pull to refresh" was another scenario we had in mind for positive/negative pan values (so you could enable touch events when pulling down at the top of a scroller, to animate the refresh icon or something; but then still have native scrolling for the rest of the scroller). Though I understand there may be some complicated issues for Apple to work through to join, it'd really be great if we could continue the positive/negative discussion over in the working group (I don't think we really want to design the API here in the webkit bug). 1010834 13 benjamin 2014-05-21 14:32:54 -0700 (In reply to comment #12) > Ah, makes sense. When I use "carousel" I usually mean the ones that wrap around like the kids' ride. They're usually moving things from the beginning to the end of the scroller or vice-versa to create the illusion of a full carousel loop. So you never hit this issue and pan-x/pan-y work just fine. > > But, not all work this way and I agree the positive/negative values would improve the experience. Though I like a solution like CSS Scroll Snap Points to enable this to be built with native scrolling instead. Snap points is a good idea to investigate regardless. There will still be cases when people want full control with JavaScript. With iOS, we try to give as much power as possible to the web page. Generic solutions to provide a near native experience for a large variety of use cases are very useful to have. I can see touch-action being useful there. > "Pull to refresh" was another scenario we had in mind for positive/negative pan values (so you could enable touch events when pulling down at the top of a scroller, to animate the refresh icon or something; but then still have native scrolling for the rest of the scroller). > > Though I understand there may be some complicated issues for Apple to work through to join, it'd really be great if we could continue the positive/negative discussion over in the working group (I don't think we really want to design the API here in the webkit bug). I really doubt that is gonna happen. I don't think I will have useful comments before prototyping anyway. 1131154 14 webkit 2015-10-06 16:20:38 -0700 This bug depends on https://bugs.webkit.org/show_bug.cgi?id=149854 1149588 15 50167214 2015-12-16 04:17:06 -0800 Implement touch-action: manipulation; for iOS https://bugs.webkit.org/show_bug.cgi?id=149854 1150115 16 jrossi 2015-12-17 15:53:07 -0800 This tracks support for the auto and manipulation values: https://bugs.webkit.org/show_bug.cgi?id=149854 Are there plans to implement none as well? Besides the performance optimizations this could enable, support for parsing none will help libraries like: https://github.com/jquery/PEP/issues/250 1291898 17 rbyers 2017-03-28 07:51:43 -0700 Note: some discussion of the need for more touch-action values (like pan-y) in order to be able to opt-in to passive event listeners: https://github.com/WICG/EventListenerOptions/issues/56 1291984 18 webkit-bug-importer 2017-03-28 11:32:08 -0700 <rdar://problem/31302639> 1294837 19 huijing 2017-04-06 02:47:34 -0700 What is the status of touch-action on Desktop Safari 10 onwards? According to caniuse.com, auto and manipulation are supported but using feature queries as the test yields a negative result (i.e. none of the touch-action values are supported). Tested on Safari 10.1 and Safari TP 27. Link to test page: https://www.chenhuijing.com/touch-action 1302003 20 contact 2017-04-27 02:41:18 -0700 `touch-action: none` would enable a very elegant solution to the diabolical situation of trying to manage pop-ups with scrolling areas on iOS. See: https://benfrain.com/preventing-body-scroll-for-modals-in-ios/ for examples. The solution outside of iOS/Safari is to use `touch-action: none`; simple and effective. There seems no clean solution to the issue on iOS outside of WebKit implementing `touch-action: none` but I would welcome any evidence to the contrary? 1353104 21 rich.g.cook 2017-09-27 07:45:46 -0700 It would appear that pointer-events: none doesn't work in iOS 11.0.0 – anyone else having this issue? 1353106 22 redux 2017-09-27 07:49:35 -0700 (In reply to Richard Cook from comment #21) > It would appear that pointer-events: none doesn't work in iOS 11.0.0 – > anyone else having this issue? assuming you mean touch-action:none, that never worked in iOS. touch-action:manipulation does, however. see https://patrickhlauke.github.io/touch/tests/results/#suppressing-300ms-delay 1353107 23 rich.g.cook 2017-09-27 07:52:53 -0700 (In reply to Patrick H. Lauke from comment #22) > (In reply to Richard Cook from comment #21) > > It would appear that pointer-events: none doesn't work in iOS 11.0.0 – > > anyone else having this issue? > > assuming you mean touch-action:none, that never worked in iOS. > touch-action:manipulation does, however. see > https://patrickhlauke.github.io/touch/tests/results/#suppressing-300ms-delay I have only just realised this but it worked in iOS 10 to prevent the clicking of an element that was set on a higher z-index but opacity: 0 and pointer-events: none. But in iOS 11... nope. 1353108 24 redux 2017-09-27 07:59:44 -0700 (In reply to Richard Cook from comment #23) > I have only just realised this but it worked in iOS 10 to prevent the > clicking of an element that was set on a higher z-index but opacity: 0 and > pointer-events: none. But in iOS 11... nope. I'd suggest opening a new bug then, as this bug is about touch-action, not pointer-events 1443509 25 michael.herzog 2018-07-19 14:35:11 -0700 Any updates on this issue? According to "Can I use" (https://caniuse.com/#feat=css-touch-action) Safari still does not support the CSS touch-action property. I'm working on the three.js project and it would be really great for 3D controls development to have this feature available in all major browsers. 1457289 26 andrew 2018-09-06 15:21:20 -0700 Any plans to add touch-action: none? 1480396 27 plummer.andrew 2018-11-19 23:13:13 -0800 Would love to see this implemented as well... 1495020 28 shmdhussain12 2019-01-15 23:09:46 -0800 touch-action: none, will prevent the body scrolling when the Modal div is open? >>> that is when the fixed pos modal div is open, I will set the touch-action: none to the <body> element and will add the touch-action: automatic to the modal <div> in that case i will prevent the touch action on body so that i will stop scrolling the body when the user comes to the end of the modal window. Like to have the touch-action:none in IOS Safari. 1495022 29 shmdhussain12 2019-01-15 23:10:28 -0800 (In reply to Mohamed Hussain S H from comment #28) > touch-action: none, will prevent the body scrolling when the Modal div is > open? > > >>> that is when the fixed pos modal div is open, I will set the touch-action: none to the <body> element and will add the touch-action: automatic to the modal <div> in that case i will prevent the touch action on body so that i will stop scrolling the body when the user comes to the end of the modal window. > > Like to have the touch-action:none in IOS Safari. Reference : https://benfrain.com/preventing-body-scroll-for-modals-in-ios/ 1499478 30 jouni 2019-01-29 01:40:17 -0800 Having some easy method of preventing unwanted scrolling of the body element would be great, when implementing custom modal dialogs/overlays. Either this, or then overscroll-behavior would be very much appreciated! 1506083 31 graouts 2019-02-13 23:53:13 -0800 An implementation of touch-action when in r240579 for https://bugs.webkit.org/show_bug.cgi?id=193447. I'll be working on a macOS implementation in the next couple of months as well. 1506114 32 michael.herzog 2019-02-14 02:41:37 -0800 Sounds great! Please notify us when it's possible to test this with build. 1509353 33 graouts 2019-02-23 03:40:18 -0800 For macOS all we need to do is decide whether to expose the property since it's effectively only relevant with a touch-capable display. Chrome and Firefox on macOS expose the property, but I'm not sure it's right to expose it. Anyone here have thoughts on the topic? 1509366 34 redux 2019-02-23 06:58:19 -0800 any particular reason NOT to expose it? are there similar situations where a property is only exposed when particular hardware/environment is present? (thinking ahead, would like to avoid naive "test for the presence of this property to determine if it's a touch device" type detects, as they're not recommended/are usually abused) 1510385 35 mjs 2019-02-26 22:57:32 -0800 (In reply to Patrick H. Lauke from comment #34) > any particular reason NOT to expose it? are there similar situations where a > property is only exposed when particular hardware/environment is present? > (thinking ahead, would like to avoid naive "test for the presence of this > property to determine if it's a touch device" type detects, as they're not > recommended/are usually abused) I agree with this. We should always expose the property, even if it may have no effect on some devices. It's what other browsers do and it seems consistent with other "hint" type properties. 1510400 36 graouts 2019-02-27 00:09:40 -0800 OK, the touch-action property will be exposed on macOS. 1510881 37 363213 graouts 2019-02-28 02:01:03 -0800 Created attachment 363213 Patch 1511014 38 363213 simon.fraser 2019-02-28 11:20:33 -0800 Comment on attachment 363213 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=363213&action=review > LayoutTests/ChangeLog:3 > + Touch-action css property support You need a title that is specific to this commit, which seems to be about enabling tests. 1511127 39 363213 dino 2019-02-28 14:35:38 -0800 Comment on attachment 363213 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=363213&action=review >> LayoutTests/ChangeLog:3 >> + Touch-action css property support > > You need a title that is specific to this commit, which seems to be about enabling tests. Agreed. 1511319 40 graouts 2019-02-28 23:36:19 -0800 The final step to enable the WPT tests is tracked by 195204. This is all done. 1576404 41 tobi 2019-10-03 07:56:25 -0700 Will touch-action: pan-y be supported? (by mobile Safari) 1576408 42 graouts 2019-10-03 08:01:51 -0700 (In reply to Tobi Reif from comment #41) > Will touch-action: pan-y be supported? (by mobile Safari) `touch-action: pan-y` is supported in Safari on iOS 13. If you find a situation where it does not work as expected, please file a bug. 1576444 43 tobi 2019-10-03 09:29:57 -0700 > `touch-action: pan-y` is supported in Safari on iOS 13. > If you find a situation where it does not work as expected, > please file a bug. It's a bit complicated, and I unfortunately don't have the time to provide a reduced test-case. The issue is this: When I load https://tobireif.com/posts/layout_fun_with_css_grid/ eg on a Galaxy phone (eg in Chrome), and drag the "resize"-bar (below "Another demo"), and over-drag, the handle stops moving. So I add touch-action: pan-y – now when I over-drag, the handle follows. And when I drag the grid demo itself, I get normal y-axis scrolling of the page. When I load this in the iPhone simulator app (iOS 13 iPhone 8), and over-drag the resize-bar, it (sometimes) doesn't follow. For example: drag-resize the in-page demo to narrow, over-drag, then go back all the way. Do this once or eg twice -> the drag-handle stops following. So I added this hack: (function() { isMobileSafari = /iP(ad|hone|od)/i.test(navigator.userAgent); if (isMobileSafari) { demo.style.touchAction = "none"; } })(); Now there's no issue with the drag-handle (it always follows), but I don't get any scrolling (the page doesn't move when I try to drag the demo itself up/down). But page-scrolling is very important :/ I hope that you can reproduce all this (probably by toggling stuff via the dev-tools), and that the issue(s) can get fixed soon. Then I can remove the iPhone hack. In Chrome (eg on a Galaxy phone) everything works beautifully. 1576446 44 tobi 2019-10-03 09:33:58 -0700 Reported (as requested) as a separate bug: https://bugs.webkit.org/show_bug.cgi?id=202531 363213 2019-02-28 02:01:03 -0800 2019-02-28 23:35:50 -0800 Patch bug-133112-20190228110102.patch text/plain 7166 graouts U3VidmVyc2lvbiBSZXZpc2lvbjogMjQyMTk1CmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9DaGFu Z2VMb2cgYi9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKaW5kZXggNzcyNDMzMTE0NjQ1N2E4MmRlMDEw OGIxODVmMGUxNGEwY2Q4NmVkNy4uNTUyNDY2NWVhNWY5OWI5ZjY4ZjIzNWMyNGE3ZTQ5MDQ1MDIw YzVlMiAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCisrKyBiL0xheW91dFRlc3Rz L0NoYW5nZUxvZwpAQCAtMSwzICsxLDE2IEBACisyMDE5LTAyLTI4ICBBbnRvaW5lIFF1aW50ICA8 Z3Jhb3V0c0BhcHBsZS5jb20+CisKKyAgICAgICAgVG91Y2gtYWN0aW9uIGNzcyBwcm9wZXJ0eSBz dXBwb3J0CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0x MzMxMTIKKyAgICAgICAgPHJkYXI6Ly9wcm9ibGVtLzMxMzAyNjM5PgorCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFRoZSB0b3VjaC1hY3Rpb24gcHJvcGVy dHkgaGFzIGJlZW4gZW5hYmxlZCBhcyBwYXJ0IG9mIHRoZSB3b3JrIG9uIHdlYmtpdC5vcmcvYi8x OTUwMDggYnV0IHRoZSBXUFQgdGVzdHMKKyAgICAgICAgaGFkIG5vdCBiZWVuIGVuYWJsZWQgeWV0 LgorCisgICAgICAgICogcGxhdGZvcm0vbWFjL1Rlc3RFeHBlY3RhdGlvbnM6CisKIDIwMTktMDIt MjcgIFNpbW9uIEZyYXNlciAgPHNpbW9uLmZyYXNlckBhcHBsZS5jb20+CiAKICAgICAgICAgZmFz dC9zY3JvbGxpbmcvaW9zL2hpdC10ZXN0aW5nLWlmcmFtZS0wMDIuaHRtbCBhbHdheXMgZmFpbHMK ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2ltcG9ydGVkL3czYy9DaGFuZ2VMb2cgYi9MYXlvdXRU ZXN0cy9pbXBvcnRlZC93M2MvQ2hhbmdlTG9nCmluZGV4IGZlNDU1NjA1YjZkMmNmMjhjYWI2NTBj Yjk1OWZiM2Q3ZjAxOGRiN2YuLjFkNmE5NGU3ZTliYzE5NzQzY2QyM2I0NjI5NTg0OTJkNTYyZjk1 MDEgMTAwNjQ0Ci0tLSBhL0xheW91dFRlc3RzL2ltcG9ydGVkL3czYy9DaGFuZ2VMb2cKKysrIGIv TGF5b3V0VGVzdHMvaW1wb3J0ZWQvdzNjL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDE5 LTAyLTI4ICBBbnRvaW5lIFF1aW50ICA8Z3Jhb3V0c0BhcHBsZS5jb20+CisKKyAgICAgICAgVG91 Y2gtYWN0aW9uIGNzcyBwcm9wZXJ0eSBzdXBwb3J0CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJr aXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xMzMxMTIKKyAgICAgICAgPHJkYXI6Ly9wcm9ibGVtLzMx MzAyNjM5PgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IFRoZSB0b3VjaC1hY3Rpb24gcHJvcGVydHkgaGFzIGJlZW4gZW5hYmxlZCBhcyBwYXJ0IG9mIHRo ZSB3b3JrIG9uIHdlYmtpdC5vcmcvYi8xOTUwMDggYnV0IHRoZSBXUFQgdGVzdHMKKyAgICAgICAg aGFkIG5vdCBiZWVuIGVuYWJsZWQgeWV0LCBzbyB3ZSdyZSBub3cgYWRkaW5nIHRoZSBwcm9ncmVz c2lvbnMgbWFkZS4KKworICAgICAgICAqIHdlYi1wbGF0Zm9ybS10ZXN0cy9wb2ludGVyZXZlbnRz L2V4dGVuc2lvbi9wb2ludGVyZXZlbnRfdG91Y2gtYWN0aW9uLXZlcmlmaWNhdGlvbi1leHBlY3Rl ZC50eHQ6CisgICAgICAgICogd2ViLXBsYXRmb3JtLXRlc3RzL3BvaW50ZXJldmVudHMvcG9pbnRl cmV2ZW50X3RvdWNoLWFjdGlvbi12ZXJpZmljYXRpb24tZXhwZWN0ZWQudHh0OgorCiAyMDE5LTAy LTI2ICBZb3Vlbm4gRmFibGV0ICA8eW91ZW5uQGFwcGxlLmNvbT4KIAogICAgICAgICBNb3ZlIHNl cnZpY2Ugd29ya2VyIHJlc3BvbnNlIHZhbGlkYXRpb24gZnJvbSB0aGUgc2VydmljZSB3b3JrZXIg Y2xpZW50IHRvIHRoZSBzZXJ2aWNlIHdvcmtlciBpdHNlbGYKZGlmZiAtLWdpdCBhL0xheW91dFRl c3RzL2ltcG9ydGVkL3czYy93ZWItcGxhdGZvcm0tdGVzdHMvcG9pbnRlcmV2ZW50cy9leHRlbnNp b24vcG9pbnRlcmV2ZW50X3RvdWNoLWFjdGlvbi12ZXJpZmljYXRpb24tZXhwZWN0ZWQudHh0IGIv TGF5b3V0VGVzdHMvaW1wb3J0ZWQvdzNjL3dlYi1wbGF0Zm9ybS10ZXN0cy9wb2ludGVyZXZlbnRz L2V4dGVuc2lvbi9wb2ludGVyZXZlbnRfdG91Y2gtYWN0aW9uLXZlcmlmaWNhdGlvbi1leHBlY3Rl ZC50eHQKaW5kZXggYjA0Mzk4Yzk4ZTNjYWNjOTc1NDk2YTBmNWQ1MTZlYzkwNjVkMTI4Mi4uNzVi ZTg3YWYxYjVjZGMyOTRlODE2ZjVjYWMzOTA2YWI0NzFjOWU3ZCAxMDA2NDQKLS0tIGEvTGF5b3V0 VGVzdHMvaW1wb3J0ZWQvdzNjL3dlYi1wbGF0Zm9ybS10ZXN0cy9wb2ludGVyZXZlbnRzL2V4dGVu c2lvbi9wb2ludGVyZXZlbnRfdG91Y2gtYWN0aW9uLXZlcmlmaWNhdGlvbi1leHBlY3RlZC50eHQK KysrIGIvTGF5b3V0VGVzdHMvaW1wb3J0ZWQvdzNjL3dlYi1wbGF0Zm9ybS10ZXN0cy9wb2ludGVy ZXZlbnRzL2V4dGVuc2lvbi9wb2ludGVyZXZlbnRfdG91Y2gtYWN0aW9uLXZlcmlmaWNhdGlvbi1l eHBlY3RlZC50eHQKQEAgLTgsMTcgKzgsMTcgQEAgVGhlIGZvbGxvd2luZyBwb2ludGVyIHR5cGVz IHdlcmUgZGV0ZWN0ZWQ6IC4KIAogCiBQQVNTIGRlZmF1bHQgCi1GQUlMIHN0eWxlc2hlZXQtbm9u ZSBhc3NlcnRfZXF1YWxzOiBleHBlY3RlZCAiYXV0byIgYnV0IGdvdCAibm9uZSIKK1BBU1Mgc3R5 bGVzaGVldC1ub25lIAogUEFTUyBleHBsaWNpdC1hdXRvIAotRkFJTCBleHBsaWNpdC1wYW4teCBh c3NlcnRfZXF1YWxzOiBleHBlY3RlZCAiYXV0byIgYnV0IGdvdCAicGFuLXgiCitQQVNTIGV4cGxp Y2l0LXBhbi14IAogRkFJTCBleHBsaWNpdC1wYW4tbGVmdCBhc3NlcnRfZXF1YWxzOiBleHBlY3Rl ZCAiYXV0byIgYnV0IGdvdCAicGFuLWxlZnQiCiBGQUlMIGV4cGxpY2l0LXBhbi1yaWdodCBhc3Nl cnRfZXF1YWxzOiBleHBlY3RlZCAiYXV0byIgYnV0IGdvdCAicGFuLXJpZ2h0IgotRkFJTCBleHBs aWNpdC1wYW4teSBhc3NlcnRfZXF1YWxzOiBleHBlY3RlZCAiYXV0byIgYnV0IGdvdCAicGFuLXki CitQQVNTIGV4cGxpY2l0LXBhbi15IAogRkFJTCBleHBsaWNpdC1wYW4tdXAgYXNzZXJ0X2VxdWFs czogZXhwZWN0ZWQgImF1dG8iIGJ1dCBnb3QgInBhbi11cCIKIEZBSUwgZXhwbGljaXQtcGFuLWRv d24gYXNzZXJ0X2VxdWFsczogZXhwZWN0ZWQgImF1dG8iIGJ1dCBnb3QgInBhbi1kb3duIgotRkFJ TCBleHBsaWNpdC1waW5jaC16b29tIGFzc2VydF9lcXVhbHM6IGV4cGVjdGVkICJhdXRvIiBidXQg Z290ICJwaW5jaC16b29tIgotRkFJTCBleHBsaWNpdC1wYW4teC1wYW4teSBhc3NlcnRfZXF1YWxz OiBleHBlY3RlZCAiYXV0byIgYnV0IGdvdCAicGFuLXggcGFuLXkiCi1GQUlMIGV4cGxpY2l0LXBh bi15LXBhbi14IGFzc2VydF9lcXVhbHM6IGV4cGVjdGVkICJhdXRvIiBidXQgZ290ICJwYW4teCBw YW4teSIKK1BBU1MgZXhwbGljaXQtcGluY2gtem9vbSAKK1BBU1MgZXhwbGljaXQtcGFuLXgtcGFu LXkgCitQQVNTIGV4cGxpY2l0LXBhbi15LXBhbi14IAogRkFJTCBleHBsaWNpdC1wYW4tbGVmdC1w YW4tdXAgYXNzZXJ0X2VxdWFsczogZXhwZWN0ZWQgImF1dG8iIGJ1dCBnb3QgInBhbi1sZWZ0IHBh bi11cCIKIEZBSUwgZXhwbGljaXQtcGFuLWxlZnQtcGFuLWRvd24gYXNzZXJ0X2VxdWFsczogZXhw ZWN0ZWQgImF1dG8iIGJ1dCBnb3QgInBhbi1sZWZ0IHBhbi1kb3duIgogRkFJTCBleHBsaWNpdC1w YW4tcmlnaHQtcGFuLXVwIGFzc2VydF9lcXVhbHM6IGV4cGVjdGVkICJhdXRvIiBidXQgZ290ICJw YW4tcmlnaHQgcGFuLXVwIgpAQCAtMjgsMTEgKzI4LDExIEBAIEZBSUwgZXhwbGljaXQtcGFuLXVw LXBhbi1yaWdodCBhc3NlcnRfZXF1YWxzOiBleHBlY3RlZCAiYXV0byIgYnV0IGdvdCAicGFuLXJp Z2h0CiBGQUlMIGV4cGxpY2l0LXBhbi1kb3duLXBhbi1sZWZ0IGFzc2VydF9lcXVhbHM6IGV4cGVj dGVkICJhdXRvIiBidXQgZ290ICJwYW4tbGVmdCBwYW4tZG93biIKIEZBSUwgZXhwbGljaXQtcGFu LWRvd24tcGFuLXJpZ2h0IGFzc2VydF9lcXVhbHM6IGV4cGVjdGVkICJhdXRvIiBidXQgZ290ICJw YW4tcmlnaHQgcGFuLWRvd24iCiBGQUlMIGV4cGxpY2l0LXBpbmNoLXpvb20tcGFuLXgtcGFuLXVw IGFzc2VydF9lcXVhbHM6IGV4cGVjdGVkICJhdXRvIiBidXQgZ290ICJwYW4teCBwYW4tdXAgcGlu Y2gtem9vbSIKLUZBSUwgZXhwbGljaXQtcGluY2gtem9vbS1wYW4teC1wYW4teSBhc3NlcnRfZXF1 YWxzOiBleHBlY3RlZCAiYXV0byIgYnV0IGdvdCAibWFuaXB1bGF0aW9uIgorRkFJTCBleHBsaWNp dC1waW5jaC16b29tLXBhbi14LXBhbi15IGFzc2VydF9lcXVhbHM6IGV4cGVjdGVkICJwYW4teCBw YW4teSBwaW5jaC16b29tIiBidXQgZ290ICJtYW5pcHVsYXRpb24iCiBQQVNTIGV4cGxpY2l0LW1h bmlwdWxhdGlvbiAKLUZBSUwgZXhwbGljaXQtbm9uZSBhc3NlcnRfZXF1YWxzOiBleHBlY3RlZCAi YXV0byIgYnV0IGdvdCAibm9uZSIKK1BBU1MgZXhwbGljaXQtbm9uZSAKIFBBU1MgZXhwbGljaXQt aW52YWxpZC0xIAotRkFJTCBleHBsaWNpdC1pbnZhbGlkLTIgYXNzZXJ0X2VxdWFsczogZXhwZWN0 ZWQgImF1dG8iIGJ1dCBnb3QgIm5vbmUiCitQQVNTIGV4cGxpY2l0LWludmFsaWQtMiAKIFBBU1Mg ZXhwbGljaXQtaW52YWxpZC0zIAogUEFTUyBleHBsaWNpdC1pbnZhbGlkLTQgCiBQQVNTIGV4cGxp Y2l0LWludmFsaWQtNSAKQEAgLTQ2LDYgKzQ2LDYgQEAgUEFTUyBleHBsaWNpdC1pbnZhbGlkLTEy CiBQQVNTIGV4cGxpY2l0LWludmFsaWQtMTMgCiBQQVNTIGV4cGxpY2l0LWludmFsaWQtMTQgCiBQ QVNTIG5vdC1pbmhlcml0ZWQgCi1GQUlMIGluaGVyaXQgYXNzZXJ0X2VxdWFsczogZXhwZWN0ZWQg ImF1dG8iIGJ1dCBnb3QgIm5vbmUiCitQQVNTIGluaGVyaXQgCiBQQVNTIGluaXRpYWwgCiAKZGlm ZiAtLWdpdCBhL0xheW91dFRlc3RzL2ltcG9ydGVkL3czYy93ZWItcGxhdGZvcm0tdGVzdHMvcG9p bnRlcmV2ZW50cy9wb2ludGVyZXZlbnRfdG91Y2gtYWN0aW9uLXZlcmlmaWNhdGlvbi1leHBlY3Rl ZC50eHQgYi9MYXlvdXRUZXN0cy9pbXBvcnRlZC93M2Mvd2ViLXBsYXRmb3JtLXRlc3RzL3BvaW50 ZXJldmVudHMvcG9pbnRlcmV2ZW50X3RvdWNoLWFjdGlvbi12ZXJpZmljYXRpb24tZXhwZWN0ZWQu dHh0CmluZGV4IDEyM2Y5M2VhNGI3NWU1NDA0YWZlZDIxZjI4ZDNkODVjMDdlNGY1MzguLjcwMjQw MGI0ZTI4NjBiNjk2YjVkOTgzMDdhYzBjZGEwZGFjYzA3MmEgMTAwNjQ0Ci0tLSBhL0xheW91dFRl c3RzL2ltcG9ydGVkL3czYy93ZWItcGxhdGZvcm0tdGVzdHMvcG9pbnRlcmV2ZW50cy9wb2ludGVy ZXZlbnRfdG91Y2gtYWN0aW9uLXZlcmlmaWNhdGlvbi1leHBlY3RlZC50eHQKKysrIGIvTGF5b3V0 VGVzdHMvaW1wb3J0ZWQvdzNjL3dlYi1wbGF0Zm9ybS10ZXN0cy9wb2ludGVyZXZlbnRzL3BvaW50 ZXJldmVudF90b3VjaC1hY3Rpb24tdmVyaWZpY2F0aW9uLWV4cGVjdGVkLnR4dApAQCAtNiwxNiAr NiwxNiBAQCB0b3VjaC1hY3Rpb246IGJhc2ljIHZlcmlmaWNhdGlvbgogCiAKIFBBU1MgZGVmYXVs dCAKLUZBSUwgc3R5bGVzaGVldC1ub25lIGFzc2VydF9lcXVhbHM6IGV4cGVjdGVkICJhdXRvIiBi dXQgZ290ICJub25lIgorUEFTUyBzdHlsZXNoZWV0LW5vbmUgCiBQQVNTIGV4cGxpY2l0LWF1dG8g Ci1GQUlMIGV4cGxpY2l0LXBhbi14IGFzc2VydF9lcXVhbHM6IGV4cGVjdGVkICJhdXRvIiBidXQg Z290ICJwYW4teCIKLUZBSUwgZXhwbGljaXQtcGFuLXkgYXNzZXJ0X2VxdWFsczogZXhwZWN0ZWQg ImF1dG8iIGJ1dCBnb3QgInBhbi15IgotRkFJTCBleHBsaWNpdC1wYW4teC1wYW4teSBhc3NlcnRf ZXF1YWxzOiBleHBlY3RlZCAiYXV0byIgYnV0IGdvdCAicGFuLXggcGFuLXkiCi1GQUlMIGV4cGxp Y2l0LXBhbi15LXBhbi14IGFzc2VydF9lcXVhbHM6IGV4cGVjdGVkICJhdXRvIiBidXQgZ290ICJw YW4teCBwYW4teSIKK1BBU1MgZXhwbGljaXQtcGFuLXggCitQQVNTIGV4cGxpY2l0LXBhbi15IAor UEFTUyBleHBsaWNpdC1wYW4teC1wYW4teSAKK1BBU1MgZXhwbGljaXQtcGFuLXktcGFuLXggCiBQ QVNTIGV4cGxpY2l0LW1hbmlwdWxhdGlvbiAKLUZBSUwgZXhwbGljaXQtbm9uZSBhc3NlcnRfZXF1 YWxzOiBleHBlY3RlZCAiYXV0byIgYnV0IGdvdCAibm9uZSIKK1BBU1MgZXhwbGljaXQtbm9uZSAK IFBBU1MgZXhwbGljaXQtaW52YWxpZC0xIAotRkFJTCBleHBsaWNpdC1pbnZhbGlkLTIgYXNzZXJ0 X2VxdWFsczogZXhwZWN0ZWQgImF1dG8iIGJ1dCBnb3QgIm5vbmUiCitQQVNTIGV4cGxpY2l0LWlu dmFsaWQtMiAKIFBBU1MgZXhwbGljaXQtaW52YWxpZC0zIAogUEFTUyBleHBsaWNpdC1pbnZhbGlk LTQgCiBQQVNTIGV4cGxpY2l0LWludmFsaWQtNSAKQEAgLTI4LDYgKzI4LDYgQEAgUEFTUyBleHBs aWNpdC1pbnZhbGlkLTExCiBQQVNTIGV4cGxpY2l0LWludmFsaWQtMTIgCiBQQVNTIGV4cGxpY2l0 LWludmFsaWQtMTMgCiBQQVNTIG5vdC1pbmhlcml0ZWQgCi1GQUlMIGluaGVyaXQgYXNzZXJ0X2Vx dWFsczogZXhwZWN0ZWQgImF1dG8iIGJ1dCBnb3QgIm5vbmUiCitQQVNTIGluaGVyaXQgCiBQQVNT IGluaXRpYWwgCiAKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL3BsYXRmb3JtL21hYy9UZXN0RXhw ZWN0YXRpb25zIGIvTGF5b3V0VGVzdHMvcGxhdGZvcm0vbWFjL1Rlc3RFeHBlY3RhdGlvbnMKaW5k ZXggN2E5Yzg3OGRlMGUzMDIyNTZhMjllMmY5ZTIwMjU0OGQyZDRjZTVkYS4uNjhhNWRkY2E0ODY4 MTE5ZWM3YzZhZTRkNTQ0ZGNjYjM3OTY3YmUyZiAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvcGxh dGZvcm0vbWFjL1Rlc3RFeHBlY3RhdGlvbnMKKysrIGIvTGF5b3V0VGVzdHMvcGxhdGZvcm0vbWFj L1Rlc3RFeHBlY3RhdGlvbnMKQEAgLTQwLDYgKzQwLDcgQEAgZmFzdC90ZXh0L21hYyBbIFBhc3Mg XQogd2Via2l0Lm9yZy9iLzE4MTk2NCBmYXN0L3RleHQvbWFjL3NlbGVjdC1jaGFyYWN0ZXItYmVm b3JlLXplcm8td2lkdGgtam9pbmVyLmh0bWwgWyBJbWFnZU9ubHlGYWlsdXJlIF0KIAogcG9pbnRl cmV2ZW50cy9tb3VzZSBbIFBhc3MgXQoraW1wb3J0ZWQvdzNjL3dlYi1wbGF0Zm9ybS10ZXN0cy9w b2ludGVyZXZlbnRzIFsgUGFzcyBdCiAKICMvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8KICMgRW5kIHBsYXRmb3JtLXNwZWNpZmljIGRpcmVjdG9yaWVzLgo=