160953 2016-08-17 21:58:55 -0700 WebKit incorrectly clips position:fixed element, inside of its "position:relative; overflow: hidden" parent, IF that parent has "z-index" set 2026-01-27 12:34:33 -0800 1 1 1 Unclassified WebKit Layout and Rendering Safari 9 Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=160886 https://bugs.webkit.org/show_bug.cgi?id=212419 BrowserCompat, InRadar P2 Normal --- 1 dholbert webkit-unassigned ae ahmad.saleem792 alanmirth brkemper diachedelic haysmathieu hello ilyakonrad.drums jc.dafko jonlee karlcow kokovtsev kufu91 matthew.rust miguelc1221 mstange patrickufer18 raul seiz simon.fraser splaktar webkit-bug-importer oldest_to_newest 1221050 0 dholbert 2016-08-17 21:58:55 -0700 STR: 1. Load this testcase: https://jsfiddle.net/bo4q2hbh/ EXPECTED RESULTS: Teal div should not be clipped at orange border. (The teal div is a fixed-position element, and it should use the viewport as its containing block, rather than using its orange-bordered relpos ancestor.) ACTUAL RESULTS: Teal div is clipped at orange border! (in Safari) I get EXPECTED RESULTS in Firefox 48, Edge 14, and Chrome 54. I get ACTUAL RESULTS in Safari 9.1 (on Mac OS El Capitan) The bug only happens if the relatively-positioned ancestor has "z-index" set. In my above-linked jsfiddle, that element has "z-index: 0". If I remove that line, the bug goes away and I end up with EXPECTED RESULTS. Note: Chrome has a similar bug, but their bug is more restricted (it only happens if there's also 3d-transformed descendant). https://bugs.chromium.org/p/chromium/issues/detail?id=638780 1221051 1 dholbert 2016-08-17 22:00:58 -0700 Here's a reference case where I've removed "z-index: 0" from the parent: https://jsfiddle.net/bo4q2hbh/1/ This gives me EXPECTED RESULTS in Safari. There's no reason for that to have an effect on the rendering -- but it does, revealing that there's a bug here (in the rendering of the original testcase). 1221053 2 simon.fraser 2016-08-17 22:03:13 -0700 Yeah, we don't clip position:fixed properly in some cases. See also bug 160886 which may be a dup. 1221054 3 dholbert 2016-08-17 22:07:30 -0700 (In reply to comment #2) > Yeah, we don't clip position:fixed properly in some cases. See also bug > 160886 which may be a dup. Thanks. This is causing at least one known interop issue, FWIW (a site accidentally depending on this incorrect clipping, and looking broken in Firefox & Edge as a result). See https://github.com/webcompat/web-bugs/issues/3028 for details. 1294095 4 matthew.rust 2017-04-04 11:53:27 -0700 Bug is still present in Version 10.1 One thing I noticed is it seems to be a painting issue. Buttons contained in the fixed element are still clickable. Also, inspecting the area where the fixed element should be works correctly. https://codepen.io/anon/pen/rybaeZ 1294651 5 webkit-bug-importer 2017-04-05 14:36:10 -0700 <rdar://problem/31463206> 1300957 6 haysmathieu 2017-04-25 03:33:05 -0700 Hi, I've got a similar issue when the element being clipped is contained within another element having position:fixed and overflow:hidden. Testcase: https://codepen.io/mathieuhays/pen/oWYvvm Expected Result: The child element (with green background) should be visible on the right hand side. Actual Result: The child element is not visible. The above works on IE, Chrome, Firefox, Opera but not on Safari including the latest webkit nightly build. I've also tested the latest Safari on iPhone and the issue is reproducible there too. 1359572 7 323520 seiz 2017-10-12 03:46:29 -0700 Created attachment 323520 Testcase I have the same issue, even in Safari 11.0 (high sierra) as well as in Safari Technology preview. In my testcase, you see a fullscreen image (background) with position fixed gets clipped by overflow hidden. If you view the testcase in Chrome, you'll see the image cover the whole browser window. 1401867 8 ae 2018-02-24 06:25:36 -0800 Very problematic, Chrome renders this correctly... adding CC. 1404414 9 raul 2018-03-07 11:06:42 -0800 I am still having this problem on Safari 11.0.3. It seems to be working fine in every other browser. Also, as Matt Rust pointed, the buttons are still functional even though they are hidden. I'm trying to figure out a proper workaround for this (without changing the whole layout) until the bug gets fixed. Did anyone solve this issue somehow? 1451649 10 brkemper 2018-08-20 11:38:46 -0700 This happens in iPhone Safari too, even without setting a z-index. 1657499 11 splaktar 2020-05-29 16:22:34 -0700 I'm seeing this in Safari 13.1 (15609.1.20.111.8) on macOS Catalina 10.15.4 (19E287). Reproduction: https://stackblitz.com/edit/angular-material2-sidenav-issue-1dn1s1?file=src%2Fapp%2Fapp.component.html This same example works correctly in Edge (Chromium), Chrome, and Firefox. 1715928 12 alanmirth 2020-12-19 17:56:42 -0800 Did anyone find a workaround for this? 1718751 13 miguelc1221 2021-01-11 11:28:17 -0800 Ran into this issue in 2021, One way around this is to increase the height of the child where it is clipping on. I added a minHeight: '-webkit-fill-available' which seems to work well enough for now. 1718879 14 alanmirth 2021-01-11 18:26:10 -0800 I found a simple solution that works: https://stackoverflow.com/a/59656203/10600250 1718921 15 seiz 2021-01-12 01:07:00 -0800 It's great that Workarounds exist, i'd prefer this gets fixed though and am wondering if it's not about time. 1727440 16 diachedelic 2021-02-09 23:27:02 -0800 The test cases above are resolved for me on the iOS 14.3 simulator, however I have a variant which still exhibits the issue: https://codepen.io/diachedelic/pen/ExNgvYw 1902609 17 ahmad.saleem792 2022-10-01 06:45:14 -0700 I am able to reproduce this bug in Safari 16 and Safari Technology Preview 154 and the background does not expand end to end and is containerised compared to Firefox Nightly 108 and Chrome Canary 107. I know there are some z-index fixes in Webkit ToT so I will check with STP 155 and STP 156 again in future. Thanks! 1969036 18 kufu91 2023-08-01 08:30:02 -0700 Can still reproduce test case in Safari Version 16.5.2 (18615.2.9.11.10), removing the z-index on the fixed position child made the test case render correctly. Separately found an instance of this occurring without any z-indexes, will try and put together a minimal test case. 1995805 19 karlcow 2023-11-29 20:19:22 -0800 Maybe related to Bug 239418 2004092 20 ilyakonrad.drums 2024-01-10 07:38:47 -0800 I can still reproduce it in a setup where an ancestor (A) has "overflow: hidden auto" (or "overflow-y: auto") with "position: relative", its deep descendant (B) has "position: absolute" with "z-index" and its deep descendant (C) has "position: fixed". The "fixed" child block is clipped by the ancestor A for no reason, atrociously breaking the layout. If I remove "position: relative" or the overflow rule from A - it works ok. The same is true if I remove "z-index" from B. However, obviously, I need all of them. I checked a lot of provided examples of similar issues on real iPhone 13 (using Chrome, Safari and Firefox) and on Mac (using Safari and Chrome through Browserstack). It seems to be an issue with all iOS devices and with Safari on Mac. However only the example provided by Stefan (https://bugs.webkit.org/attachment.cgi?id=323520) has the same consistently broken behavior on different systems as my app. Other examples (jsfiddles, codepens, etc.) work ok through Browserstack. Although maybe it's a Browserstack issue :/ Seems really critical, I'm surprised to see so few reports over all these years. Is there a workaround? Is the bug being worked on? What can I do to help? 2017488 21 ilyakonrad.drums 2024-02-28 09:16:43 -0800 I found a workaround. I leverage the new `:has()` selector to undo the CSS rules that trigger this bug when the cut off elements appear. To only apply this madness in Webkit, I also added class `.webkit` using this condition `window.GestureEvent || window.navigator.userAgent.match(/iP(ad|od|hone)/i)`. Here's my SCSS: .webkit { // Fixes floating elements being cut-off by the sidebar when opened from a "position: absolute + z-index" element. main > .ns-dashboard { &:has(.requires-webkit-hack):has(app-overlay, app-popup, app-modal) { overflow: unset; } } .ns-page-header { // Fixes "add sub-groups" popup being cut-off by the sidebar. &:has(app-popup) { z-index: unset; } // Fixes group selector dropdown being cut-off by the sidebar on small screen. // This media query should match the query that adds `position: fixed` to `.ns-group-selector`. @media (max-width: variables.$screen-sm) { &:has(.ns-group-selector) { z-index: unset; } } } } Hope it helps someone to stay sane. 2040452 22 jc.dafko 2024-06-07 17:41:03 -0700 We encountered this issue in our components and created an additional test case to demonstrate it: https://codepen.io/jcfranco/pen/rNgzLeL?editors=1010 Some suggested workarounds are not feasible for us due to the use of shadow DOM and external components. 2048614 23 kokovtsev 2024-07-26 07:39:14 -0700 The original testcase is not reproducible (i.e. works as EXPECTED) in Safari 17.5, however a slight modification where an intermediate statically position child is added between the relpos and the teal div: .posrel > .static > .fixed https://jsfiddle.net/z81ahequ/10/ After playing around a bit, it turns out that the bug is reproducible when the parent div has overflowing content, that is when the parent is actually scrollable. In the sandbox above, applying smaller width and height to .static "fixes" the bug. Changing `overflow: auto` to `overflow: hidden` also "fixes" the problem. According to the Inspector, the .relpos becomes a separate layer because "Element has "-webkit-overflow-scrolling: touch" style", which apparently is added implicitly when the element can be scrolled. More observations: .relpos { z-index: 0; } + overflowing content => teal div clipped (BUG) .relpos { /* no z-index */ } + overflowing content => teal div overflows (CORRECT) .relpos { will-change: transform; /*and no z-index*/ } => teal div clipped even if there is no scroll in .relpos, however this seems CORRECT according to the spec as the .relpos becomes a containing block for the fixed element 2160620 24 patrickufer18 2025-11-21 10:15:21 -0800 As a followup to @kokovtsev@gmail.com callout above: the issue can be isolated to the presence of the `-webkit-overflow-scrolling: touch;` on the `overflow: auto` div. Check this out on iOS Safari: https://codepen.io/patrickufer/pen/GgZMBEb From the Safari 13 release notes (https://developer.apple.com/documentation/safari-release-notes/safari-13-release-notes#Layout-and-Rendering): > Added support for one-finger accelerated scrolling to all frames and overflow:scroll elements eliminating the need to set -webkit-overflow-scrolling: touch. So if you're running into this on iOS only, I'd recommend removing `-webkit-overflow-scrolling: touch;`. 2175514 25 hello 2026-01-27 12:34:33 -0800 I came across this bug after considerable confusion about why some buttons were 'invisible' in Safari (still secretly clickable if you know where they are) but fine in the other browsers. As others have said, I think at least some of the test cases (e.g. the original teal box version) seem to have been resolved and display as expected, but we have still run into what I assume are some remaining edge cases. All of the observations made are using Safari 18.6 (20621.3.11.11.3) as well as the Tech preview build Release 235 (WebKit 20624.1.7) - they both appear to behave the same way as far as I can tell at least. I've put together an example of the particular scenario we were seeing: https://codepen.io/bluefantail/pen/YPWrEmQ Specifically, when the parent context is a position: fixed element and also has overflow: auto AND the scrollable overflow actually 'triggers' e.g. there is specifically enough content in the parent container to trigger a scroll bar - then the problem arises for child position: fixed descendants which become clipped by the parent. Try deleting paragraphs until the scrollbar is removed and at that point the display starts working correctly. As others have mentioned, one solution is to split the fixed position and overflow properties across two parent containers which does work but with the catch that if any container element in the tree between those and the fixed position child as any of the other offending properties on it e.g. z-index, position: sticky or overflow: auto etc - then it breaks again. So the solution for us was to try and place the overflow: auto property as 'far down' in the DOM order as possible to avoid this. Not ideal but it has worked ok. Here's a demo of that fix: https://codepen.io/bluefantail/pen/zxBPEGw I also tried a few other things in the hopes of finding another workaround including trying to make use of the new <dialog> element and popover attributes to see if they might have any slightly different behaviour in terms of how they get put on the top 'layer' - but sadly they seem to be bound to the same set of rules here 😞. 323520 2017-10-12 03:46:29 -0700 2017-10-12 03:46:29 -0700 Testcase testcase-seiz.html text/html 4156 seiz PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImRlIj4KPGhlYWQ+Cgk8bWV0YSBjaGFyc2V0PSJ1 dGYtOCIgLz4KCTx0aXRsZT5TYWZhcmkgei1pbmRleC9vdmVyZmxvdyBidWcgdGVzdGNhc2U8L3Rp dGxlPgoJPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJCQkVkaXQgMTEuNiIgLz4KCgk8 c3R5bGU+CgkJYm9keXsKCQkJZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7CgkJCWJhY2tncm91bmQt Y29sb3I6ICNmZmZmZmY7CgkJCW1hcmdpbjogMDsKCQkJcGFkZGluZzogMDsKCQl9CgkJI2NvbnRl bnR7CgkJCW92ZXJmbG93OiBoaWRkZW47CgkJCW1heC13aWR0aDogNzB2dzsKCQkJbWFyZ2luOiAw IGF1dG87CgkJCXBhZGRpbmc6IDIwcHg7CgkJfQoJCS5iZ2ltYWdlewoJCQlwb3NpdGlvbjogcmVs YXRpdmU7CgkJCXotaW5kZXg6IC0xOwoJCX0KCQkKCQkuYmdpbWFnZSBpbWd7CgkJCWRpc3BsYXk6 IGJsb2NrOwoJCQlwb3NpdGlvbjogZml4ZWQ7CgkJCXRvcDogMDsKCQkJbGVmdDogMDsKCQkJd2lk dGg6IDEwMHZ3OwoJCQloZWlnaHQ6IDEwMHZoOwoJCQl6LWluZGV4OiAtMTAwOwoJCQlvYmplY3Qt Zml0OiBjb3ZlcjsKCQl9Cgk8L3N0eWxlPgo8L2hlYWQ+Cgo8Ym9keT4KCjxkaXYgaWQ9ImNvbnRl bnQiPgoKCTxoMj5Db250ZW50PC9oMj4KCTxwPgoJCUxvcmVtIGlwc3VtIGRvbG9yIHNpdCBhbWV0 LCBjb25zZWN0ZXR1ciBhZGlwaXNjaW5nIGVsaXQuIENyYXMgZWxlaWZlbmQgdWx0cmljZXMgYXJj dSwgc2FnaXR0aXMgcGhhcmV0cmEgbGlndWxhIHByZXRpdW0gYmliZW5kdW0uIEN1bSBzb2NpaXMg bmF0b3F1ZSBwZW5hdGlidXMgZXQgbWFnbmlzIGRpcyBwYXJ0dXJpZW50IG1vbnRlcywgbmFzY2V0 dXIgcmlkaWN1bHVzIG11cy4gU2VkIGFjY3Vtc2FuIGxvcmVtIGFjIGR1aSB1bGxhbWNvcnBlciBl Z2V0IGNvbnNlY3RldHVyIGRvbG9yIHZlc3RpYnVsdW0uIFByb2luIGNvbmd1ZSBuZXF1ZSBlZ2V0 IG1hZ25hIGludGVyZHVtIHNpdCBhbWV0IGxhb3JlZXQgc2VtIGJpYmVuZHVtLiBTdXNwZW5kaXNz ZSBzZWQgbWV0dXMgZmVsaXMsIHZlbCBwbGFjZXJhdCBlcmF0LiBBbGlxdWFtIHZlbmVuYXRpcyBh dWN0b3IgZG9sb3IgaW4gdmVuZW5hdGlzLiBFdGlhbSB1cm5hIHRlbGx1cywgbG9ib3J0aXMgdml0 YWUgY29uc2VxdWF0IGVnZXQsIHRyaXN0aXF1ZSBpZCBuaXNpLiBOdWxsYW0gbGFjdXMgdXJuYSwg Y29uZGltZW50dW0gdXQgaWFjdWxpcyBxdWlzLCB2aXZlcnJhIHZpdGFlIGVuaW0uIFZpdmFtdXMg bWFzc2EgbGliZXJvLCB1bGxhbWNvcnBlciBhIHZpdmVycmEgbG9ib3J0aXMsIGJsYW5kaXQgdmVs IGVzdC4gVmVzdGlidWx1bSBzb2xsaWNpdHVkaW4gdWx0cmljZXMgbGlndWxhLCBpbnRlcmR1bSBw b3J0dGl0b3IgbmlzbCB1bHRyaWNpZXMgdmVsLiBWZXN0aWJ1bHVtIGx1Y3R1cywgcHVydXMgZWdl dCBlbGVpZmVuZCBmZXJtZW50dW0sIHJpc3VzIGlwc3VtIHRyaXN0aXF1ZSBpcHN1bSwgaW4gZWxl bWVudHVtIHR1cnBpcyBhdWd1ZSBlZ2V0IHB1cnVzLiBNb3JiaSBldSBwdXJ1cyBjb21tb2RvIG1h Z25hIGNvbmRpbWVudHVtIGxvYm9ydGlzIGV0IGVnZXQgbG9yZW0uCgk8L3A+Cgk8cD4KCQlOdWxs YSBmYWNpbGlzaS4gTmFtIGZlcm1lbnR1bSBsZW8gc2l0IGFtZXQganVzdG8gYXVjdG9yIHF1aXMg YWNjdW1zYW4gZG9sb3IgbGFvcmVldC4gUXVpc3F1ZSBldSBlbGVpZmVuZCBkaWFtLiBWaXZhbXVz IG5lYyBtZXR1cyBuaXNpLiBEb25lYyB0dXJwaXMgZmVsaXMsIHBvcnRhIGF0IG1vbGxpcyB2dWxw dXRhdGUsIGZhdWNpYnVzIGF0IG1ldHVzLiBWZXN0aWJ1bHVtIGZhY2lsaXNpcyBjb25ndWUgYXJj dSBuZWMgZWdlc3Rhcy4gVml2YW11cyB1dCBsZWN0dXMgbWV0dXMuIE1vcmJpIHF1aXMgdWxsYW1j b3JwZXIgcHVydXMuIE51bGxhbSBxdWFtIHF1YW0sIHRyaXN0aXF1ZSB1dCBtYXR0aXMgZWdldCwg aGVuZHJlcml0IHNpdCBhbWV0IGVyYXQuIER1aXMgYSBzZW0gYWMgcXVhbSBsdWN0dXMgaW1wZXJk aWV0IGlkIHNlZCBhbnRlLiBEdWlzIGNvbnZhbGxpcyBsZWN0dXMgc2VkIHF1YW0gZWxlbWVudHVt IHZ1bHB1dGF0ZSB2ZXN0aWJ1bHVtIGFyY3Ugc2NlbGVyaXNxdWUuIE1vcmJpIGVnZXN0YXMgZmVs aXMgdml0YWUgbnVsbGEgbWFsZXN1YWRhIGFjY3Vtc2FuLiBWaXZhbXVzIHRpbmNpZHVudCBoZW5k cmVyaXQgbnVuYyBlZ2V0IGN1cnN1cy4gQWxpcXVhbSBpZCB0cmlzdGlxdWUgYXVndWUuIE51bmMg Y29uZGltZW50dW0sIG5pc2kgaW4gZnJpbmdpbGxhIHBvc3VlcmUsIGp1c3RvIG5pc2kgaW50ZXJk dW0gYXVndWUsIGZlcm1lbnR1bSB0aW5jaWR1bnQgdHVycGlzIGp1c3RvIGZhdWNpYnVzIHRvcnRv ci4gU2VkIHZpdGFlIG1pIGZlbGlzLgoJPC9wPgoJPHA+CgkJUXVpc3F1ZSBpbiBkaWFtIGp1c3Rv LCBlZ2V0IHN1c2NpcGl0IGVzdC4gU3VzcGVuZGlzc2UgZW5pbSBkdWksIGNvbmRpbWVudHVtIG5v biBsYWNpbmlhIHF1aXMsIG1hdHRpcyBlZ2V0IG51bmMuIFV0IGRhcGlidXMgcnV0cnVtIGZlbGlz IG5lYyByaG9uY3VzLiBJbiBoYWMgaGFiaXRhc3NlIHBsYXRlYSBkaWN0dW1zdC4gQ3VyYWJpdHVy IGNvbmRpbWVudHVtIG1hdHRpcyBwdXJ1cyBlZ2V0IHRlbXB1cy4gSW50ZWdlciBkaWN0dW0gY29u dmFsbGlzIGxpZ3VsYSwgdmVsIHNhZ2l0dGlzIGxvcmVtIHNvZGFsZXMgc2l0IGFtZXQuIFByb2lu IGVnZXQgdGluY2lkdW50IHB1cnVzLiBDdXJhYml0dXIgcGxhY2VyYXQgbmliaCB2ZWwgcXVhbSB0 aW5jaWR1bnQgY29uc2VxdWF0IHB1bHZpbmFyIG51bGxhIHBoYXJldHJhLiBEb25lYyBwaGFyZXRy YSBhdWN0b3IgcGxhY2VyYXQuIEFlbmVhbiBldSBwdXJ1cyB1dCBxdWFtIGNvbnZhbGxpcyBzYWdp dHRpcy4gVml2YW11cyBpbiBudWxsYSBvZGlvLCBxdWlzIGRhcGlidXMgbmlzaS4gU2VkIGEgc2Fw aWVuIGVnZXQgbGFjdXMgdmVzdGlidWx1bSBwdWx2aW5hci4gQWxpcXVhbSBjb25zZXF1YXQganVz dG8gaW4gbnVsbGEgZ3JhdmlkYSBhIGFsaXF1YW0gcXVhbSBpYWN1bGlzLiBOdWxsYSBwdXJ1cyBs aWJlcm8sIGlhY3VsaXMgZWdldCBwb3J0YSBhdCwgaWFjdWxpcyBldSBtYXNzYS4gUGhhc2VsbHVz IGFsaXF1YW0gZWxpdCBxdWlzIHJpc3VzIGxvYm9ydGlzIHRlbXBvci4KCTwvcD4KCTxwPgoJCU51 bmMgYmliZW5kdW0gY29uZGltZW50dW0gY29uc2VjdGV0dXIuIEV0aWFtIGxvcmVtIGxlbywgdm9s dXRwYXQgaWQgYWxpcXVhbSBub24sIG9ybmFyZSBldCBlbGl0LiBQaGFzZWxsdXMgb3JjaSBtYXVy aXMsIHVsdHJpY2llcyBmcmluZ2lsbGEgZmF1Y2lidXMgZXUsIHZpdmVycmEgcXVpcyBsYWN1cy4g RG9uZWMgbm9uIGVyYXQgZWdldCBlc3QgcGxhY2VyYXQgY29uc2VxdWF0LiBQcmFlc2VudCBuZWMg bnVsbGEgYXJjdSwgbG9ib3J0aXMgbGFjaW5pYSBtYXNzYS4gVml2YW11cyBhYyBjb252YWxsaXMg cHVydXMuIERvbmVjIGNvbmRpbWVudHVtLCBqdXN0byBxdWlzIGJpYmVuZHVtIHB1bHZpbmFyLCBu aXNsIHR1cnBpcyBjb25zZXF1YXQgbnVuYywgbWF0dGlzIHNvZGFsZXMgdHVycGlzIGF1Z3VlIGEg bGFjdXMuIE51bmMgY29uc2VjdGV0dXIgZnJpbmdpbGxhIHB1bHZpbmFyLiBBZW5lYW4gdXQgYXVj dG9yIG9yY2kuIERvbmVjIGVyYXQgbmVxdWUsIHB1bHZpbmFyIHNpdCBhbWV0IG1hbGVzdWFkYSBz ZWQsIG1vbGVzdGllIHV0IHB1cnVzLiBEdWlzIHZlbCBpcHN1bSBsaWJlcm8sIGluIGN1cnN1cyBs b3JlbS4gRXRpYW0gcG9zdWVyZSwgYXJjdSBjb21tb2RvIGltcGVyZGlldCBsdWN0dXMsIGF1Z3Vl IGVyYXQgaGVuZHJlcml0IGVsaXQsIHBsYWNlcmF0IGlhY3VsaXMgZG9sb3IgbWFnbmEgbmVjIGVy b3MuIFBlbGxlbnRlc3F1ZSBoYWJpdGFudCBtb3JiaSB0cmlzdGlxdWUgc2VuZWN0dXMgZXQgbmV0 dXMgZXQgbWFsZXN1YWRhIGZhbWVzIGFjIHR1cnBpcyBlZ2VzdGFzLgoJPC9wPgoKCTxkaXYgY2xh c3M9ImJnaW1hZ2UiPgoJCTxpbWcgc3JjPSJodHRwczovL2ltYWdlcy51bnNwbGFzaC5jb20vcGhv dG8tMTQ5MDcyMzI4NjYyNy00YjY2ZTZiMjg4MmE/ZHByPTEmYW1wO2F1dG89Y29tcHJlc3MsZm9y bWF0JmFtcDtmaXQ9Y3JvcCZhbXA7dz04MDAmYW1wO2g9NjAwJmFtcDtxPTgwJmFtcDtjcz10aW55 c3JnYiZhbXA7Y3JvcD0iIC8+Cgk8L2Rpdj4JCjwvZGl2PgoKPC9ib2R5Pgo8L2h0bWw+Cg==