freenode :: #whatwg

 
27 Apr 2017
04:23howdoiwhere does the Caches API storage the data? (Browsers's cache? Disk?)
04:39annevkhowdoi: why does it matter?
04:39howdoiannevk: to understand the internals
04:40howdoilike we have chrome\user data\default\local storage\
04:40annevkhowdoi: browsers can do whatever as long as it matches the requirements
04:40howdoiare we using some kind of DB for the cache? sqllite or something or is it on the disk?
04:41howdoihow is the performance taken care? (Even after restart of the app or the device, the caches will be maintained, so I feel it must be on the disk)
04:49howdoiannevk: ^ :)
04:50annevkhowdoi: it would depend on the browser, but yes, at some point it probably needs to be written to disk, but there's no requirement that this happens directly
04:52howdoiannevk: interesting, the spec doesn't speak about the that either, I have cloned https://chromium.googlesource.com/chromium/src.git and eager to dig in.
04:54annevkhowdoi: there's no reason for the spec to talk about implementation strategies
04:55annevkhowdoi: JavaScript doesn't require a JIT either, even though in practice you can't compete without one
04:55howdoiannevk: agree, makes sense.
04:56howdoione thing that bothers me the most is the try-catch block for await statements
04:58KiChjangwhy use JIT when you can AOT
05:02DomenicYou could write to cloud instead of disk.
05:26howdoiDomenic: what does chrome do?
07:09tobieHey, we're planning to lump reporting of all sensor value changes together right before rAF. I assume that implies adding a step in the event loop processing model that references an abstract operation in the generic sensor spec.
07:10tobieIf that's so, should I just get a PR ready where we can discuss further details (e.g. position in the algo steps)?
07:11annevktobie: probably, though it's unclear to me that section has had sufficient testing in general
07:11tobieannevk: not sure what you mean.
07:12annevktobie: also, Firefox is about to remove some earlier sensor APIs due to same-origin policy breaking stuff and nobody seems interested in putting in the effort to give them a security story
07:12annevktobie: that it's not clear to me that section of the algorithm is stable
07:13tobiewell, we're working closely with the Enamel team to get the security story straight. Would be happy to get more involvement from mozilla folks.
07:15tobieannevk: I'll send a PR. We can discuss further there.
07:15annevktobie: so what's their story for the ambient light?
07:15annevks/the//
07:17tobieannevk: I think ambient light should be put on the back burner until we have 1) good use cases for it, 2) a sound permission strategy.
07:17tobieannevk: in the meantime, we could expose a mediaquery-inspired LightLevelSensor instead, with just a enum for values.
07:18tobies/a/an/
07:19tobieannevk: that said, we'll need to figure out a good permission story for all of the motion sensors (which have similar if not worse security concerns than ambient light, and use cases which prevent a lot of the mitigation strategies we could use for ambient-light).
07:20annevkAnd by that you mean UX?
07:25tobieannevk: well; UX, adequate permission descriptors, permission names that work (we have sensors that are combination of others sensors and the Permission spec isn't really designed to handle that), a precise understanding of the threats we're trying to mitigate, precise understanding of the requirements for each sensor and how that affects mitigation
07:25tobiestrategies (e.g. motion sensors values are often integrated, so fuzzing the values or the timestamps isn't an option, while that's something that would work for ambient-light).
07:31tobieannevk: for example, should permission descriptor allow for different permission strategies (e.g. opt-out vs. prompt) depending on the frequency at which the sensors are polled?
07:32annevkI think all of that depends on whether UX can even find a way to phrase that question
07:32annevkIt's hard to get UX feedback, but a lot of features could really do with UX-first
07:33annevkDesign the user interaction model first, then figure out what engineering is required to make that happen
09:46zcorpanApparently meta viewport uses the same parser as window.open() features in at least webkit. https://bugs.webkit.org/show_bug.cgi?id=170548#c36
10:44zcorpanTabAtkins: irregular friendly ping re fingerprint :-)
12:31annevkDomenic: I added basic tests for all views
12:32annevkDomenic: let me know if you had something more in find
12:32annevkzcorpan: maybe in Blink it's not less code, but I'd imagine that if you had some code sharing for boolean features you'd end up with less code
12:33zcorpanannevk: i guess that is possible
15:29hsivonenannevk: is there a reason why the EUC-JP decoder can prepend ASCII *and* 0xA0 *and* 0xFF in the situation where the other two-byte decoders prepend ASCII only?
15:29hsivonenthat is, why are 0xA0 and 0xFF as a bogus trail byte different in EUC-JP compared to the others?
15:36* hsivonen commented on euc-jp tests github
16:33annevkhsivonen: not sure
18:15TabAtkinsannevk, Domenic, bz: Btw, sorry for the frustration coming thru in the Array-like thread, but jiminy christmas i'm getting frustrated over this.
 
27 Apr 2017
   
Last message: 2 hours and 19 minutes ago