| 04:23 | <howdoi> | where does the Caches API storage the data? (Browsers's cache? Disk?) |
| 04:39 | <annevk> | howdoi: why does it matter? |
| 04:39 | <howdoi> | annevk: to understand the internals |
| 04:40 | <howdoi> | like we have chrome\user data\default\local storage\ |
| 04:40 | <annevk> | howdoi: browsers can do whatever as long as it matches the requirements |
| 04:40 | <howdoi> | are we using some kind of DB for the cache? sqllite or something or is it on the disk? |
| 04:41 | <howdoi> | how 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:49 | <howdoi> | annevk: ^ :) |
| 04:50 | <annevk> | howdoi: 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:52 | <howdoi> | annevk: 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:54 | <annevk> | howdoi: there's no reason for the spec to talk about implementation strategies |
| 04:55 | <annevk> | howdoi: JavaScript doesn't require a JIT either, even though in practice you can't compete without one |
| 04:55 | <howdoi> | annevk: agree, makes sense. |
| 04:56 | <howdoi> | one thing that bothers me the most is the try-catch block for await statements |
| 04:58 | <KiChjang> | why use JIT when you can AOT |
| 05:02 | <Domenic> | You could write to cloud instead of disk. |
| 05:26 | <howdoi> | Domenic: what does chrome do? |
| 07:09 | <tobie> | Hey, 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:10 | <tobie> | If that's so, should I just get a PR ready where we can discuss further details (e.g. position in the algo steps)? |
| 07:11 | <annevk> | tobie: probably, though it's unclear to me that section has had sufficient testing in general |
| 07:11 | <tobie> | annevk: not sure what you mean. |
| 07:12 | <annevk> | tobie: 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:12 | <annevk> | tobie: that it's not clear to me that section of the algorithm is stable |
| 07:13 | <tobie> | well, 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:15 | <tobie> | annevk: I'll send a PR. We can discuss further there. |
| 07:15 | <annevk> | tobie: so what's their story for the ambient light? |
| 07:15 | <annevk> | s/the// |
| 07:17 | <tobie> | annevk: 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:17 | <tobie> | annevk: in the meantime, we could expose a mediaquery-inspired LightLevelSensor instead, with just a enum for values. |
| 07:18 | <tobie> | s/a/an/ |
| 07:19 | <tobie> | annevk: 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:20 | <annevk> | And by that you mean UX? |
| 07:25 | <tobie> | annevk: 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:25 | <tobie> | strategies (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:31 | <tobie> | annevk: 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:32 | <annevk> | I think all of that depends on whether UX can even find a way to phrase that question |
| 07:32 | <annevk> | It's hard to get UX feedback, but a lot of features could really do with UX-first |
| 07:33 | <annevk> | Design the user interaction model first, then figure out what engineering is required to make that happen |
| 09:46 | <zcorpan> | Apparently 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:44 | <zcorpan> | TabAtkins: irregular friendly ping re fingerprint :-) |
| 12:31 | <annevk> | Domenic: I added basic tests for all views |
| 12:32 | <annevk> | Domenic: let me know if you had something more in find |
| 12:32 | <annevk> | zcorpan: 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:33 | <zcorpan> | annevk: i guess that is possible |
| 15:29 | <hsivonen> | annevk: 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:29 | <hsivonen> | that 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:33 | <annevk> | hsivonen: not sure |
| 18:15 | <TabAtkins> | annevk, Domenic, bz: Btw, sorry for the frustration coming thru in the Array-like thread, but jiminy christmas i'm getting frustrated over this. |
| 21:06 | <Domenic> | Hmm I wonder why we left the named getter on window instead of moving it to WindowProxy |
| 21:06 | <Domenic> | annevk ^ |
| 21:51 | <tobie> | TabAtkins: share your dev experience concerns about arrays-likes on the platform. Happy to work on this asap. |
| 21:51 | <TabAtkins> | Already doing it in #345, the thread I was indirectly referencing. ^_^ |
| 21:58 | <tobie> | TabAtkins: Yes, I've been following along. |
| 22:04 | <tobie> | TabAtkins: what I meant is I'm happy to do the editing once the dust settles. |
| 22:04 | <TabAtkins> | ah, kk |