1057185 - [Ambient Light API] Retrieve light levels at any time

Status: NEW

(Core :: DOM: Device Interfaces, defect, P3)

Description

[Joshua Smith [:joshua-s]]

The current event-based Ambient Light API has one limitation: light levels are not retrievable until a change causes the devicelight event to fire.

Scenario:
A newly loaded page wants to retrieve the ambient light levels.

Expected result:
The app can get the value from window.deviceLight or some such interface.

Actual result:
The app must wait until a devicelight event fires before receiving the light value.  This could cause errant behavior on the part of the app, such as optimizing the interface for bright environments when it is actually dark.

Comment 1

[Doug Turner (:dougt)]

mchen, is this something we can fix easily?  I suspect it's just a design flaw in using addEventListener and having to wait for a sensor update.

Comment 2

[Marco Chen [:mchen]]

Hi,

As I know that there are two types of sensors regarding to how to report events - "continuous" & "none continuous". The former will send events periodically within a number of "delay" and the latter will update the event only if value is changed.

I think the issue here is happened on none continuous sensor type. I would suggest that maybe we can store last events of each sensor types then report last one to every new eventListenner.

Comment 3

[Doug Turner (:dougt)]

Yeah, people don't like that in the DOM event spec.  Probably better to hang a property.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, the current API design just doesn't work for non-continuous sensors.

Firing an event whenever addEventListener is called sadly breaks some of the invariants that the event system has. So it's not a very well liked solution.

Unfortunately no other solution has been able to be agreed upon in any of the standards orgs.

Simply having a property also isn't good because it would require that we always keep the sensor on. We need some form of signal from the page that it's interested in sensor data before we turn on a particular sensor.

Anne, Marcos, is this something you guys could help with? I'd hate to hack this into addEventListener.

Comment 5

[Marcos Caceres [:marcosc]]

The design of this particular API is pretty sad and not very flexible (an event tied to the window object). Doesn't give us a lot to work with. We can certainly push for something better: e.g., a real interface with a subscription model of some kind. 

An ugly hack requiring minimal changes would be to add something to the DeviceLightEvent interface object. That way, the current API can remain as is, but we can get what we need:

```IDL
partial interface DeviceLightEvent{
   static promise<unrestricted double> requestCurrentValue();
}
```

and then: 

```
window.DeviceLightEvent.getCurrentValue().then(doWhatever)
```

my 2c.

Comment 6

[Anne (:annevk)]

Can the existing API be changed? That is, do you want a standardized version of this API that does not have this problem? It's not clear what the scope of the solution space is.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If gecko is the only browser that supports the ambient light sensor events, then I'd be ok with coming up with an API that isn't backwards compatible.

But yes, the goal is to have a standardized version of ambient light events.

Comment 8

[Anne (:annevk)]

http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0213.html

Comment 9

[Doug Turner (:dougt)]

we should figure out what we want to do wrt all of these device 'events'.  Going to assign to overholt to help drive that.

Comment 10

[Marco Chen [:mchen]]

(In reply to Doug Turner (:dougt) from comment #9)
> we should figure out what we want to do wrt all of these device 'events'. 

Since we want to re-visit the design of all device events, maybe we can count [1] into this round.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=910150#c0

Comment 11

[Julien Wajsberg [:julienw]]

FTR there are some very concrete issues coming from this.

On the Flame, when the light is low, the sensor never send events until there is enough light. I don't know if this specific behavior happens on all devices.

I also think Flame-kk has made this more noticeable because the sensor reports values that are lower than Flame-jb (for the same real ambient light). As a result, I think we reach the lowest boundary when there is more ambient light than we used to on Flame-jb.

This is IMO the root cause of bug 1083018 and bug 989281.

If we could retrieve the value at any time (and get 0 in low light conditions) we could properly set the screen brightness to the lowest value.


I understand the real concerns, especially from comment 4, and I don't have a good solution for this, but I wanted to give a real-world use case for this issue.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We should simply fire the event every time after an event handler has been added. Waiting for a better API is clearly taking too long.

Comment 13

[Rick Waldron [:rwaldron]]

(In reply to Jonas Sicking (:sicking) from comment #12)
> We should simply fire the event every time after an event handler has been
> added. Waiting for a better API is clearly taking too long.

We got onto github.com/w3c this past month and work was steady until I was interrupted by TC39, a (US) holiday and then RobotsConf. The good news is that our rough design definitely addresses the issue Julien has described: 


  // This will get an update 10 times per second
  var ambient = new sensors.AmbientLight({ frequency: 10 });
  
  ambient.value; <-- initially null

  // Some execution turn in future, after the sensor has been initialized and 
  // is delivering its latest readings 10 times per second, log the value:
  console.log(ambient.value);
  

BUT! Comment 4 is also well understood and equal attention given, since _yes_ the sensor doesn't need to always be on, so in those cases: 

  sensors.AmbientLight.requestValue().then(val => console.log(value));
  

(requestValue() may accept some known AmbientLight sensor identification for cases where greater than 1 exists in the device)

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

When can we have an official W3C draft with some assurance that it's stable?