This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In order to create a reuseable component using iframe, sometimes we need to make the iframe unfocusable. For example if we want to create a on screen virtual keyboard the resides in a iframe, it should not take the focus from the input field while it still needs to receive the touch events, this rules out the pointer-events:none css style. The ignorefocus attribute should explicitly mark the iframe unfocusable, no focus transition will happen. If it is set after the iframe already has focus then the focus remain as is, but the iframe can't take focus again if it lose it.
Should this prevent controls in the iframe from being focused also?
Yes, the idea is that tabbing or mouse/pointer wouldn't focus anything in the iframe. Perhaps the attribute could be ignoreuserfocus, if we still want to .focus() to work
How would keyboard-only users use pages that used this?
(In reply to Ian 'Hixie' Hickson from comment #3) > How would keyboard-only users use pages that used this? They won't be able to access that iframe. Other elements are focused normally.
Isn't that a problem...?
Well, in this particular use case, keyboard-only users wouldn't need the whole thing since they can just use a keyboard. This is more for keyboard-less users, at least the use case is. Also, I'd expect this to work so that user focus is ignored. The page itself could call .focus() or some such, which means the page inside ignorefocus would be just accessible to keyboard-only user as for touch-only user, if wanted.
If the goal is to make pointer events not transfer focus (but to leave the controls in, e.g., the tab order), since is probably more an issue for something like CSS. Something like pointer-events:no-focus or something.
no tab order either, when looking at the outside of the iframe.
Preventing users from focusing a frame entirely seems a bit dodgy.
Would putting this in the iframe be insufficient?: <body onmousedown="return false">
(In reply to Ian 'Hixie' Hickson from comment #10) > Would putting this in the iframe be insufficient?: > > <body onmousedown="return false"> That would require all of this kind of content to include this snippet, which maybe not so bad... And it does not work with remote iframes (the frame's page is loaded in a separate content process). The parent frame couldn't block on the iframe's event handler execution.
(In reply to Kan-Ru Chen (陳侃如) [:kanru] from comment #11) > (In reply to Ian 'Hixie' Hickson from comment #10) > > Would putting this in the iframe be insufficient?: > > > > <body onmousedown="return false"> > > That would require all of this kind of content to include this snippet, > which maybe not so bad... Well, presumably the content of the iframe is in a better position to know if it's good to not focus things than the container is, right? (I'm still not 100% clear on the use case, but if it's an on-screen keyboard, one could imagine that it might sometimes want to show a settings dialog where focus _is_ to be allowed, e.g. so that someone can type some text in an "add to dictionary" dialog.) This snippet isn't particularly longer than having an ignorefocus="" attribute on the <iframe>, either. > And it does not work with remote iframes (the frame's page is loaded in a > separate content process). Can you elaborate on this? Why would it not work if the iframe was remote? > The parent frame couldn't block on the iframe's event handler execution. The snippet would have to go in the embedded frame, not on the <iframe> element.
(In reply to Ian 'Hixie' Hickson from comment #12) > (In reply to Kan-Ru Chen (陳侃如) [:kanru] from comment #11) > > (In reply to Ian 'Hixie' Hickson from comment #10) > > > Would putting this in the iframe be insufficient?: > > > > > > <body onmousedown="return false"> > > > > That would require all of this kind of content to include this snippet, > > which maybe not so bad... > > Well, presumably the content of the iframe is in a better position to know > if it's good to not focus things than the container is, right? (I'm still > not 100% clear on the use case, but if it's an on-screen keyboard, one could > imagine that it might sometimes want to show a settings dialog where focus > _is_ to be allowed, e.g. so that someone can type some text in an "add to > dictionary" dialog.) > > This snippet isn't particularly longer than having an ignorefocus="" > attribute on the <iframe>, either. Agree. But using the ignorefocus attribute the iframe owner could inforce the rule. > > And it does not work with remote iframes (the frame's page is loaded in a > > separate content process). > > Can you elaborate on this? Why would it not work if the iframe was remote? Because if the iframe was remote then the event handler will be run asynchronously. Otherwise if the on-screen keyboard is slow to responce, it could block the owner content. > > The parent frame couldn't block on the iframe's event handler execution. > > The snippet would have to go in the embedded frame, not on the <iframe> > element.
I don't understand why it matters if it is async or not. Can you elaborate? All that matters if that the focus isn't taken when the user interacts with the focusable controls using a non-keyboard input device, right?