Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Pressing Escape key to dismiss on Safari causes window to scroll to bottom of page

See original GitHub issue

Current behavior

Using Safari (v13.1.1) on Mojave (10.14.6) and also (on a completely separate Mac) the latest released versions of Mac OS and Safari, when I press the Escape key to dismiss a SweetAlert modal, it closes the modal correctly but then scrolls to the very bottom of the page.

Only seems to happen if an input is displayed (for example input: 'text')

There are no console messages and this behavior does not happen in Chrome or Firefox. Only Safari.

Pressing the “close” button closes the SweetAlert modal correctly without scrolling. Similarly, positive buttons do not affect the window’s scroll position.

The odd behavior seems to be prevented by clicking. At first I thought it was the act of “blurring” or unfocusing the input but then I realized that tabbing focus to the button and back to the input still causes the issue to happen when hitting Escape.

The below fiddle uses latest jQuery at the time of writing (3.5.1) and latest SweetAlert2 at the time of writing (10.6.1).

Expected behavior

Not the above. Window should not scroll on pressing Escape to dismiss.

Live demo

https://jsfiddle.net/twistedpixel/e6ktzL51/

Edit 1: add video demonstrating the issue: Dropbox link

Issue Analytics

State:
Created 3 years ago
Comments:25 (15 by maintainers)

Top GitHub Comments

2reactions

gvernicommented, Nov 1, 2020

Quick update @limonte, I gave up fixing it in renderInput.js because the workaround works well only with input: text. For the other types, a different character need to be used (and I wasn’t able to find the correct one for password).

So I went back to debugging the issue and that’s what i found so far. The issue is reproduced when you have all of the following conditions:

An external script loaded in the <head> of the page
A <div> with role="dialog" and aria-modal="true" within a <div> with absolute position.
An <input> inside the above <div>

I created a sample page with no Swal code here: https://nutritious-gem-order.glitch.me. In order to reproduce the issue:

Open https://nutritious-gem-order.glitch.me with Safari
Hard refresh the page (shift + refresh button)
If the issue doesn’t happen, open the developer console and hard refresh again

I’ll start from here to see if there is a way to fix it. I tried already removing the role and aria-modal from swal, but the issue is still reproduced. So there must be something else. @twistedpixel if you can five a try with the page I sent above, that’d confirm I don’t have any gremlins in my safari.

2reactions

gvernicommented, Oct 31, 2020

@twistedpixel I don’t have a workaround / fix yet, but I have a better workaround you can apply to you code and avoid creating a container. The point here is to create a mixin that uses didOpen to change the value of the input (twice).

  function safariFix (popup) {
    let input = popup.getElementsByClassName('swal2-input')
    if (input.length) {
      let prevValue = input[0].value
      input[0].value = ' '
      input[0].value = prevValue
    }
  }
    
  swalForSafari = swal.mixin({
    didOpen: (popup) => {safariFix(popup)}
  })
    
	$(document).ready(function() {
		$('body').on('click', '.weirdness-test', function(e) {
      e.preventDefault()
			swalForSafari.fire({
				title: 'TEST',
				input: 'text',
				allowEscapeKey: true,
			})
		})
	})

Have a go and let me know if this is solving (at least temporarily) your issue.