inert icon indicating copy to clipboard operation
inert copied to clipboard

Able to focus an ostensibly inert input in Safari

Open aaxelb opened this issue 6 years ago • 5 comments

Update: Most of this issue was just browsers being browsers (I didn't realize how much tab key behavior varies), but one real problem remains: In Safari, pressing tab can sometimes focus and allow interacting with elements that should be inert.

For example, on https://wicg.github.io/inert/demo/, clicking on the page and then pressing tab focuses an input that should be inert. I can send exactly one keypress to that input, but typing further has no effect. inert-safari (Safari 12.1.1 on MacOS 10.13)

aaxelb avatar Jun 19 '19 15:06 aaxelb

hm thanks for reporting this! @alice or I will try to look into it when we have a moment.

robdodson avatar Jun 20 '19 20:06 robdodson

Aside from being able to focus a supposedly-inert element in Safari, do these browsers have the same behaviour without the inert polyfill present? It seems like these may be browser-specific focusing behaviours/bugs.

alice avatar Jun 24 '19 01:06 alice

@alice Oh wow, you're absolutely right. Firefox was respecting a Mac OS setting and Safari... has its own opinion on the tab key.

So yes, the only issue here is allowing focus on a should-be-inert input in Safari. Sorry for wasting your time with the rest!

aaxelb avatar Jun 24 '19 16:06 aaxelb

I wonder if Safari simply doesn't respect tabindex=-1.

I had a bit of a think a little while back about the logic behind their "opinions" on the tab key, and came to the conclusion that their defaults are optimised for fast form filling, rather than keyboard-only navigation (with the setting to switch to the latter).

alice avatar Jun 25 '19 00:06 alice

Safari's things are kind of complex, and on iOS even more so. A lot of that is being discussed in the whatwg focus meta-bug/linked issues, thankfully... Unfortunately I don't have a link to handy at the moment as I'm on my phone

bkardell avatar Jun 25 '19 02:06 bkardell