public-device-apis-log@w3.org from May 2019 by author

Adrian Nita via GitHub

Re: [wake-lock] Add "geolocation" wake lock (#170) (Monday, 27 May)

Anne van Kesteren via GitHub

Re: [wake-lock] request(): Order for permission and other checks (#202) (Wednesday, 8 May)

Anssi Kostiainen via GitHub

Re: [sensors] Add API for requesting permission (#388) (Monday, 27 May)
Closed: [wake-lock] Avoid cases like |options|.|signal| as that creates a new variable signal (#208) (Wednesday, 15 May)
Closed: [wake-lock] Avoid cases like |options (#207) (Tuesday, 14 May)
Re: [wake-lock] Create PULL_REQUEST_TEMPLATE.md (#168) (Monday, 6 May)

Chris Dumez via GitHub

Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Tuesday, 14 May)

Jake Archibald via GitHub

Re: [wake-lock] Losing reference to a WakeLock object is a bug or intended behavior (#199) (Wednesday, 1 May)

Joe Palmer via GitHub

Re: [ambient-light] Security and Privacy considerations for ALS (#13) (Wednesday, 29 May)

Kenneth Rohde Christiansen via GitHub

Re: [wake-lock] Adjust the "Release Wake Lock" algorithm after #209 (#216) (Thursday, 23 May)
Re: [wake-lock] Adjust the "Release Wake Lock" algorithm after #209 (#216) (Thursday, 23 May)
Re: [wake-lock] Adjust the "Release Wake Lock" algorithm after #209 (#216) (Thursday, 23 May)
Re: [wake-lock] request(): Order for permission and other checks (#202) (Tuesday, 21 May)
Closed: [wake-lock] New API with AbortController is not intuitive for developers. (#214) (Tuesday, 21 May)
Re: [wake-lock] New API with AbortController is not intuitive for developers. (#214) (Tuesday, 21 May)
Re: [wake-lock] Make page visibility checks use the resposible document. (#212) (Wednesday, 15 May)
[wake-lock] Avoid cases like |options|. (#208) (Monday, 13 May)
[wake-lock] Avoid cases like |options (#207) (Monday, 13 May)
Closed: [wake-lock] Clarify platform wake lock's internal slots have different contexts (#192) (Monday, 13 May)
Closed: [wake-lock] Lifetime of WakeLock (#195) (Monday, 13 May)
Closed: [wake-lock] Losing reference to a WakeLock object is a bug or intended behavior (#199) (Monday, 13 May)
Re: [wake-lock] request(): Order for permission and other checks (#202) (Monday, 13 May)
Re: [wake-lock] Page visibility and browsing contexts (#206) (Monday, 13 May)
Re: [wake-lock] Do not assign a default value to WakeLockRequestOptions.signal (#203) (Saturday, 4 May)
Closed: [wake-lock] Canceling using AbortSignal is a bit weird (#171) (Friday, 3 May)
Re: [wake-lock] request(): Order for permission and other checks (#202) (Friday, 3 May)
Re: [wake-lock] Losing reference to a WakeLock object is a bug or intended behavior (#199) (Wednesday, 1 May)
Closed: [wake-lock] Losing reference to a WakeLock object is a bug or intended behavior (#199) (Wednesday, 1 May)
Re: [wake-lock] Remove query(), fixes #199 (#200) (Wednesday, 1 May)
Re: [wake-lock] Losing reference to a WakeLock object is a bug or intended behavior (#199) (Wednesday, 1 May)
Re: [wake-lock] Losing reference to a WakeLock object is a bug or intended behavior (#199) (Wednesday, 1 May)
Re: [wake-lock] Losing reference to a WakeLock object is a bug or intended behavior (#199) (Wednesday, 1 May)

Marcos Cáceres via GitHub

Closed: [wake-lock] ReSpec is complaining about some spec references (#219) (Wednesday, 29 May)
Re: [wake-lock] chore: fix ReSpec xref errors (#220) (Wednesday, 29 May)
Re: [wake-lock] ReSpec is complaining about some spec references (#219) (Wednesday, 29 May)
Re: [wake-lock] Create PULL_REQUEST_TEMPLATE.md (#168) (Monday, 6 May)
Re: [wake-lock] chore(.travis): use GET instead of HEAD for ReSpec validator (#205) (Monday, 6 May)
Re: [wake-lock] chore(.travis): use GET instead of HEAD for ReSpec validator (#205) (Monday, 6 May)
Re: [wake-lock] request(): Order for permission and other checks (#202) (Monday, 6 May)
Re: [wake-lock] request(): Order for permission and other checks (#202) (Monday, 6 May)
Re: [wake-lock] Do not assign a default value to WakeLockRequestOptions.signal (#203) (Monday, 6 May)
Re: [wake-lock] Losing reference to a WakeLock object is a bug or intended behavior (#199) (Wednesday, 1 May)

Michael Sunwoo \(AvatarLabs\) via GitHub

Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Friday, 10 May)

Mrunal Kapade via GitHub

[wake-lock] New API with AbortController is not intuitive for developers. (#214) (Thursday, 16 May)

Nicholas Butko \[8th Wall\] via GitHub

Raphael Kubo da Costa via GitHub

Re: [wake-lock] ReSpec is complaining about some spec references (#219) (Wednesday, 29 May)
[wake-lock] ReSpec is complaining about some spec references (#219) (Tuesday, 28 May)
Re: [wake-lock] Adjust the "Release Wake Lock" algorithm after #209 (#216) (Thursday, 23 May)
Re: [wake-lock] Adjust the "Release Wake Lock" algorithm after #209 (#216) (Thursday, 23 May)
Re: [wake-lock] Make WakeLockRequestOptions' signal non-nullable, do not set a default (#204) (Thursday, 23 May)
Re: [wake-lock] Tweak a bit on the description of WakeLock interface (#215) (Thursday, 23 May)
Re: [wake-lock] Make page visibility checks use the resposible document. (#212) (Wednesday, 22 May)
Re: [wake-lock] New API with AbortController is not intuitive for developers. (#214) (Tuesday, 21 May)
Re: [wake-lock] Make page visibility checks use the resposible document. (#212) (Wednesday, 15 May)
Re: [wake-lock] Avoid cases like |options|.|signal| as that creates a new variable signal (#208) (Wednesday, 15 May)
Re: [wake-lock] Avoid cases like |options|.|signal| as that creates a new variable signal (#208) (Tuesday, 14 May)
Re: [wake-lock] Fix AbortSignal handling in WakeLock.request() after #201 (#209) (Tuesday, 14 May)
Re: [wake-lock] Fix AbortSignal handling in WakeLock.request() after #201 (#209) (Tuesday, 14 May)
Re: [wake-lock] Fix AbortSignal handling in WakeLock.request() after #201 (#209) (Tuesday, 14 May)
Re: [wake-lock] Fix the checkbox example after #201 (#210) (Tuesday, 14 May)
Re: [wake-lock] Fix the checkbox example after #201 (#210) (Tuesday, 14 May)
Re: [wake-lock] Avoid cases like |options (#207) (Tuesday, 14 May)
Re: [wake-lock] request(): Order for permission and other checks (#202) (Friday, 10 May)
Re: [wake-lock] Page visibility and browsing contexts (#206) (Thursday, 9 May)
[wake-lock] Page visibility and browsing contexts (#206) (Thursday, 9 May)
Re: [wake-lock] chore(.travis): use GET instead of HEAD for ReSpec validator (#205) (Monday, 6 May)
Re: [wake-lock] request(): Order for permission and other checks (#202) (Monday, 6 May)
Re: [wake-lock] Make WakeLockRequestOptions' signal non-nullable, do not set a default (#204) (Monday, 6 May)
Re: [wake-lock] Make WakeLockRequestOptions' signal non-nullable, do not set a default (#204) (Monday, 6 May)
Re: [wake-lock] Do not assign a default value to WakeLockRequestOptions.signal (#203) (Monday, 6 May)
Re: [wake-lock] Move to new static API as agreed upon (#201) (Friday, 3 May)
[wake-lock] request(): Order for permission and other checks (#202) (Friday, 3 May)
Re: [wake-lock] Move to new static API as agreed upon (#201) (Thursday, 2 May)

Reilly Grant via GitHub

Re: [sensors] Add API for requesting permission (#388) (Tuesday, 28 May)
Closed: [wake-lock] Page visibility and browsing contexts (#206) (Wednesday, 22 May)
Re: [wake-lock] Avoid cases like |options|.|signal| as that creates a new variable signal (#208) (Tuesday, 14 May)
Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Tuesday, 14 May)
Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Tuesday, 14 May)
Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Friday, 10 May)
Re: [wake-lock] Page visibility and browsing contexts (#206) (Thursday, 9 May)
Re: [wake-lock] Remove query(), fixes #199 (#200) (Wednesday, 1 May)
Re: [wake-lock] Losing reference to a WakeLock object is a bug or intended behavior (#199) (Wednesday, 1 May)

Rick Waldron via GitHub

Re: [sensors] Add API for requesting permission (#388) (Wednesday, 22 May)

Last message date: Wednesday, 29 May 2019 13:26:33 UTC