-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The link to 'focus' is not appropriate #282
Comments
Did you check what we did in wakelock spec? |
Wakelock uses "fully active":
While generic sensor uses "currently focused area of a top-level browsing context": Currently focused area belongs to a document whose origin is same origin-domain with the origin of the given active document. |
So area means that is refers to the viewport? That doesn't really make sense here, @anssiko |
What we really want is that the web site is active and visible to the user. I don't really see why we mix this with element focus |
Whether we are using "active" or "fully active" depends on whether we support the feature in iframes etc, which I don't think we should do (hard to convey to users and what is the use-case?) Doesn't the visibility check make the focused area check pointless? @anssiko |
Btw, I like the way this was specced in Generic Sensors, we should do the same, very clear |
Both checks are needed to mitigate skimming attacks. A window can be both visible and not currently focused at the same time in traditional windowing systems. |
From sensor impl point of view : readings are only available for active documents whose origin is same origin-domain with the currently focused frame (LocalFrame)
|
BTW, should Web NFC API be allowed in an iframe? Currently it is not allowed in Chromium implementation, but I think it should be, and we may need integrate the Feature Policy API. Thoughts? |
I don't think we need to support webNFC on iframes right now, unless some specific use case comes up. WebNFC implementation is now following the same way as sensors and I don't see a reason to change that atleast for the time being. |
So a get focused iframe(same origin-domain) is able to expose Web NFC API, right? Same as the sensor implementation. |
Sorry, was not clear, Which is already checked in NFCProxy So yes, in that respect a bit different from sensors, which does allow access from iframes with Feature Policy and Focus Areas. |
Yeah, we can consider supporting the same in the future, but for now we can do simpler. @anssiko there is a difference between the frame having focus and a certain element. |
Yes, this sounds like element focus and not about whether the containing browser window has focus. Web NFC and Generic Sensors are not elements or contained by elements so it feels wrong. Also on mobile you often don't have keyboard focus because the keyboard is visible if you do |
Do we have other remaining tasks for this issue? Looks like the spec already got refined and our impl is also fine with it. |
Conclusion from TPAC meeting is that we drop relying on focus and adopt prose similar to wake lock, meaning that we abort push/scan when we loose visibility |
@zolkis do you agree with this, then I can probably work on this tomorrow? |
Certainly. Let me finish the current PR, let's review/merge and then do this tomorrow. |
The "focus" used in the spec links to https://html.spec.whatwg.org/multipage/interaction.html#focused which only applies to elements, rather than the web pages or browsing contexts.
e.g.
We need to find an another way to indicate the focus, maybe it could be something like:
Thoughts?
The text was updated successfully, but these errors were encountered: