Closed Bug 1701824 Opened 3 years ago Closed 3 years ago

Disable ondevicelight attribute behind the flag

Categories

(Core :: DOM: Core & HTML, task)

x86_64
Windows 10
task

Tracking

()

RESOLVED FIXED
89 Branch
Tracking Status
firefox89 --- fixed

People

(Reporter: saschanaz, Assigned: saschanaz)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

No description provided.
Severity: -- → N/A
Status: NEW → ASSIGNED
Attachment #9212367 - Attachment description: WIP: Bug 1701824 - Hide ondevicelight behind a flag → Bug 1701824 - Hide ondevicelight behind a flag
Attachment #9212367 - Attachment description: Bug 1701824 - Hide ondevicelight behind a flag → WIP: Bug 1701824 - Hide ondevicelight behind a flag
Attachment #9212367 - Attachment description: WIP: Bug 1701824 - Hide ondevicelight behind a flag → Bug 1701824 - Hide ondevicelight behind a flag
Pushed by krosylight@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a616ae588449
Hide ondevicelight behind a flag r=smaug
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

Hi @Kagami

So as I understand it, this moves the Window.ondevicelight behind the preference device.sensors.ambientLight.enabled.

Looking at the docs the associated event DeviceLightEvent has been behind this same preference since FF62 so would it be fair to say that this is just cleanup - ie making the event and the event handler be controlled in the same way?

Further, my understanding (and please correct me if I am wrong) is that there is no android UI for setting these preferences. Doesn't this mean that you're effectively turning off all device light support - since it is really only relevant on mobile devices and inaccessible on them too?

Last of all, can you give me a little background on why these device APIs (like this and proximity) never got adopted? Did the handling just move into the device itself so that pages don't have to do anything?

Flags: needinfo?(krosylight)

Hi Hamish again,

Looking at the docs the associated event DeviceLightEvent has been behind this same preference since FF62 so would it be fair to say that this is just cleanup - ie making the event and the event handler be controlled in the same way?

Exactly.

Further, my understanding (and please correct me if I am wrong) is that there is no android UI for setting these preferences. Doesn't this mean that you're effectively turning off all device light support - since it is really only relevant on mobile devices and inaccessible on them too?

Not sure "turning off" is the right word here, since it has been "turned off" already. It currently is present only because KaiOS requested to keep it, and not really for Android users.

Last of all, can you give me a little background on why these device APIs (like this and proximity) never got adopted? Did the handling just move into the device itself so that pages don't have to do anything?

Per Anne it's mainly about privacy issues:

  • These APIs have various privacy leaks, including violating the same-origin policy, without the user being informed.
  • These APIs do not match the current standards for sensor APIs and some are incompatible with what is being shipped by Chrome (e.g., device orientation).
  • There's no interest to address these shortcomings. (Mostly in the sense of engineering resources and having other problems to tackle first.)
  • As these are event-driven APIs the compatibility impact should be minimal to none. The events simply won't fire.
Flags: needinfo?(krosylight)

Thanks very much. Really appreciate your help. If you are interested, the documentation for this can be tracked in https://github.com/mdn/content/issues/4308.

Essentially this is

  • a BCD version update which will show removal in FF89 for desktop, FF79 for Android (as the preference UI is not available there).
  • Docs with much more clear warnings against using these events in both the event docs and the API docs (Ambient Light API and Proximity Event API). As part of the tidy the attribute docs got merged into their parent event docs, so there are fewer places where these APIs will be encountered (i.e. this is a first step to on day deciding the docs can be deleted).

Docs completed, so setting this to DDC. Thanks Hamish!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: