search

WICG / inert

Polyfill for the inert attribute and property.
Other
924 stars 81 forks source link

Able to focus an ostensibly inert input in Safari #124

Open aaxelb opened 5 years ago

aaxelb commented 5 years ago

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)

robdodson commented 5 years ago

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

alice commented 5 years ago

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.

aaxelb commented 5 years ago

@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!

alice commented 5 years ago

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).

bkardell commented 5 years ago

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