Snackbar not closing

[pndewit]

What MDC-Web Version are you using?

0.22.0

What browser(s) is this bug affecting?

Chrome (Version 61.0.3163.100 (Official Build) (64-bit))
User agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"

What OS are you using?

macOS Sierra (version 10.12.6)

What are the steps to reproduce the bug?

1. Open Snackbar demo page: https://material-components-web.appspot.com/snackbar.html
2. Snackbar settings should be left as is (only Dismiss on action enabled)
3. Click the "Show" button twice and switch browser tab (within the 2750ms timer which should close the first snackbar and open the second one)
4. Switch back to the snackbar demo tab and the snackbar never closes (even when setting focus on other elements)

What is the expected behavior?

The snackbar should close.

What is the actual behavior?

It doesn't close.

Any other information you believe would be useful?

I was digging through the Snackbar component and found out that it gets focus when switching tab to the tab that is showing the snackbar. When it has focus, it doesn't close (expected behaviour). The blur handler should then kick in when moving focus to some other element, but AFAIK the blur handler doesn't trigger any more. I am not sure yet why. The blur handler does kick in when performing the steps above, but clicking the "Show" button only once at step 3.

Besides the actual bug I'd also like to know why the Snackbar gets focus when switching tab? Shouldn't it just continue (or restart) the snackbar timer for closure?

EDIT:
Found a dirty workaround: manually set the snackbarHasFocus variable to false when the visibility change handler is triggered (make sure the MDC visibility change handler is run first by using setTimeout as it sets the snackbarHasFocus variable to true...) and there is a Snackbar queue.

[pndewit]

I got some more related issues:

1. Set no Action Text (just empty the field)
2. Open the snackbar once (click the "Show" button once)
3. Switch browser tab and switch back to the Snackbar demo tab
4. Trigger blur (select some text on the background)
5. Notice that the Snackbar is never removed

This is probably because the focus is set on the action button inside the Snackbar and as there is no action button, the focus can not be set and thus the blur is never triggered. Setting a space character in the Action Text textfield is a workaround for this issue.

[Garbee]

Besides the actual bug I'd also like to know why the Snackbar gets focus when switching tab?

I'd assume this is when the tab is switched back to the MCW tab being active. The snackbar is given focus since it is used as a priority message system that users may need to interact with within the given time constraint. So making that the focus before returning to page focus is there for screen readers and other accessible technology. This way, users actually get the information provided.

[pndewit]

@Garbee Thank you for your reply and I get your point. But wouldn't it be better to just reset the close timer as the Snackbar does not get removed when having focus (obviously you don't want it to be removed while the user is actively using it)?
This would set it "back" to the original state (when it was opened in the first place, before switching tabs).

[Garbee]

But wouldn't it be better to just reset the close timer as the Snackbar does not get removed when having focus

Not necessarily. It all depends on tab order within the page. By forcing focus, you're negating any travel time to give the user the most pertinent information as quickly as possible before it leaves.

[pndewit]

Thanks, that answers my question.
Do you (by any chance) know why the blur handler is not triggered when moving focus to some other element after switching tabs and having a queue?

[Garbee]

I don't know off the top myself. I'd need to do deeper debugging of the code as it runs to understand that. I'm seeing a blur event happen when tabs are switched, so that should trigger the blurring even though it really shouldn't. I think there needs to be some analysis of the blur event to see what the cause is (or simply if the page is visible using the page visibility API) to handle things well for that scenario.

Currently, a blur is a blur is a blur but that isn't necessarily the case given the context and needs of a snackbar.

[rickdesantis]

I'm coping with this problem checking on tab/window change if the snackbar is still active, disabling and recreating it if so (and after 1.5s for a smooth slide down animation and to give the time to read it).

This is my code, it seems to work on most browsers (I'm using webpack/babili):

document.addEventListener('DOMContentLoaded', function () {
  let first = true
  let hidden = 'hidden'

  // Standards:
  if (hidden in document) {
    document.addEventListener('visibilitychange', onchange)
  } else if ((hidden = 'mozHidden') in document) {
    document.addEventListener('mozvisibilitychange', onchange)
  } else if ((hidden = 'webkitHidden') in document) {
    document.addEventListener('webkitvisibilitychange', onchange)
  } else if ((hidden = 'msHidden') in document) {
    document.addEventListener('msvisibilitychange', onchange)
  } else if ('onfocusin' in document) { // IE 9 and lower:
    document.onfocusin = document.onfocusout = onchange
  } else { // All others:
    window.onpageshow = window.onpagehide = window.onfocus = window.onblur = onchange
  }
  function onchange (evt) {
    let v = 'visible'
    let h = 'hidden'
    let evtMap = {
      focus: v, focusin: v, pageshow: v, blur: h, focusout: h, pagehide: h
    }

    evt = evt || window.event
    let visibility = v
    if (evt.type in evtMap) {
      visibility = evtMap[evt.type]
    } else {
      visibility = this[hidden] ? h : v
    }
    if (first) {
      first = false
      return
    }
    if (visibility === v) {
      let el = document.querySelector('.mdc-snackbar--active')
      if (el) {
        setTimeout(function () {
          el.setAttribute('aria-hidden', true)
          el.classList.remove('mdc-snackbar--active')
          window.snackbar = mdc.snackbar.MDCSnackbar.attachTo(el)
        }, 1500)
      }
    }
  }

  // set the initial state (but only if browser supports the Page Visibility API)
  if (document[hidden] !== undefined) {
    onchange({type: document[hidden] ? 'blur' : 'focus'})
  }
})

[ronnievsmith]

[UPDATE] This workaround/fix works 80% of the time. Still having issues.

It seems like using .promise.all would be the proper method for the toast/snackbar. Just .push into an array that get's .all'ed so that multiple toasts can queue up if necessary. Or, I'm sure the jQuery UI sauce has the code that one could copy/paste from.

Workaround/Fix: setTimeout.

    // toastD hack. Toast was sticking when fired from catch block or promise result. This timer fixed it.
    var toastD = function(msg) {
        setTimeout(function() {
            msg = String(msg);
            snackbar.show({
                message: msg,
                timeout: 2750
            });
        }, 500);
    }; 

One last thing. 2+2 is 4, minus 1 is 3; quick maths. smoke trees.🌲

[ronnievsmith]

I'm not even understanding my visibility is used for this. It's super easy basic position:fixed and just CSS transition it from -96px to whatever (for example). CSS fixed will basically force it off screen. No need to over-engineer it. That's just my 2 cents.

[piotr-cz]

For me snackbar doesn't close even without switching tabs, probably when called from inside a promise.
Workaround mentioned @rhroyston did the job, timeout can be as low as 10ms