mozilla :: #content

6 Oct 2017
12:14farrejgraham: ping
12:15farrebkelly: we're running a shield study for foreground throttling
13:00jgraham_farre: Not really here until next week, but ask anyway
13:03farrejgraham: not important enough. I have written a bad set of tests, and I wanted absolution :)
13:24jgraham_farre: Haha
13:30bzfarre: go forth an sin no more
13:31farrebz: ah, but it was in preparation of sinning :)
13:44bzfarre: Oh, you wanted an indulgence?
13:44bzfarre: Those went out of style around the 16th century.... ;)
13:46farrebz: exactly!
15:03bkellybaku|away: do you have any ideas for https://bugzilla.mozilla.org/show_bug.cgi?id=1404105?
15:03firebotBug 1404105 NEW, nobody@mozilla.org Crash in AsyncShutdownTimeout | Places Clients shutdown | sanitize.js: Sanitize,sanitize.js: Sanitiz
15:17* bkelly is pleasantly surprised by our image cache.
16:32smaugehsan: why you need script blockers in https://hg.mozilla.org/try/rev/9dea18a99fa27e578abe38a8d1ca5a59be58dc9e
16:32smaugI'd assume there is script blocker on stack already
16:48bzman
16:48bztechnical debt strikes again
17:05smaugwhere this time?
17:06smaug(I'm mostly quite happy with DOM)
17:12ehsansmaug, I thought there would be somewhere too, but didn't check all the way yet
17:12ehsansmaug, the patch isn't quite ready for review yet :)
17:12ehsanjust wanted to see what try thinks!
17:12smaugehsan: running scripts while there might be other mutation observer handlers pending sounds rather scary
17:13smaugwhich is why I assume there is script blocker on stack already
17:13ehsanindeed
17:13smaugsince there should be AutoDocUpdate on stack
17:15ehsansmaug, yeah this one: https://searchfox.org/mozilla-central/rev/8efd128b48cdae3a6c6862795ce618aa1ca1c0b4/dom/base/nsINode.cpp#2251
18:13ehsanannevk, about https://bugzilla.mozilla.org/show_bug.cgi?id=1404022, what about getAttributeNode/getAttributeNodeNS?
18:13firebotBug 1404022 NEW, nobody@mozilla.org setAttributeNode() is incorrectly deprecated.
18:15ehsanannevk, also removeAttributeNode?
18:15ehsanannevk, and createAttribute/createAttributeNS
18:39annevkehsan: all warnings can go
18:39annevkehsan: they are all in the spec now
18:40annevkehsan: the only simplifications we kept are those that had already landed successfully
18:40annevkehsan: such as Attr never having children
18:40ehsanannevk, ok I already wrote one patch, I can write one for the rest
18:40annevkehsan: ta!
18:48jibbz: ping
18:54bzjib: ack
18:54jibHi, I've filed https://github.com/w3c/permissions/issues/162
18:54jibas we discussed
18:54bzThanks
18:54jiband I'll try to add a PR for mediacapture
18:55jibI'm just a bit rusty on the global objects
18:55jibWhat's the current best practice for talking about e.g. a relevant document being fully active? I see specs doing different things. e.g.
18:55jibcontext object - in https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
18:55jibenvironment settings object
18:56jibbrowsing context's document
18:56jibThe permission spec is even referencing Realms in ecmascript - https://w3c.github.io/permissions/#reacting-to-revocation
18:57bzmmmhm
18:57bzSo look
18:57bzAny time an API call happens there are sort of 4 global objects that can be related to it
18:57bzThey're documented at https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-objects
18:57bzFor our purposes, ignore entry and incumbent
18:57bzBecause you shouldn't add new uses of those.
18:58bzSo that leaves "current" and "relevant"
18:58bzWhich, intuitively, are "the global of the function being called" and "the global of the object being worked with"
18:58bzIf you do foo.bar() they're the same
18:58jibexcellent
18:58bzIf you do window1.SomeInterface.prototype.bar.call(fooFromWindow2)
18:58bzthen they're different.
18:59jibhmm
19:00jibso if I do window1.navigator.mediaDevices.prototype.getUserMedia.call(fooFromWindow2), which window's origin would it be safe to display in a permission prompt?
19:01bzThe above is a slight oversimplification
19:01jibwhat yardstick do people use to decide?
19:01bzIn that foo.bar() could have foo and foo.bar coming from different windows
19:01jibI appreciate that :)
19:01bzit just doens't by default
19:01bzok
19:01bzSo which one you should pick...
19:01bzThe answer is "it probably doesn't matter too much"
19:01bzEspecially if you only care about the origin
19:01jibhow so?
19:01bzBecause, unless document.domain is involved, they will be same-origin
19:02bzAgain, normally.
19:02bzIf a Firefox extension does window1.navigator.mediaDevices.prototype.getUserMedia.call(frooFromWindow2), then....
19:02bz(well, then the "current" thing will be the extension)
19:03bzMy gut feeling would be to use the "relevant settings" origin
19:03bzFwiw
19:03jibok that's where I was leaning based on what you said
19:03bzBut I might just be biased.
19:03jibthe object being worked with
19:04bzA JS spec person would claim that "current" is the only thing that makes sense, because that's the only concept the JS spec has. ;)
19:04bzAnyway.
19:04jibhmm
19:04jibok and Realms?
19:04bzAlright
19:04bzSo a Realm is a JS spec concept
19:04jibI was only wondering why the permissions spec decided to relate permissions to realms
19:04* bz shrugs
19:05bzSo some of this is just bureaucratic bookkeeping
19:05bzA Realm is defined at https://tc39.github.io/ecma262/#sec-code-realms
19:05bzIt's just a struct with the fields listed there
19:05jibok so from our end that's really about whether we want something to be reusable outside of browsers?
19:06bzum...
19:06bzSo a Realm on its own has no concept of origin
19:06bzThe permissions spec is going from the Realm to the "settings object"
19:06bzwhich is the HTML spec concept that includes things like origins
19:07bzBasically, the ES spec has this [[HostDefined]] thing on Realms
19:07bzwhich is an extension point
19:07bzOn the web, [[HostDefined]] points to a settings object
19:07jibok
19:07bzSee https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-objects
19:08* bz looks at what the permissions spec is saying
19:08bz"queue a task on the Realms settings objects responsible event loop
19:08bz_that_ sounds like nonsense
19:09* jib is glad it's not just mediacapture
19:09* bz reads more
19:09bzOh, I see, that's in the context of "the user no longer intends to grant permission for a realm to use a feature"
19:09bzWhatever that means.
19:09bzSo "the Realm" is the one that's not supposed to have the permission anymore, ok
19:09bzMy concern was with the definite article. ;)
19:10jibyeah or "other realms of the same origin"
19:10bzThat part is slightly nonsensical, because realms don't have an origin per se
19:10jib"other realms with the same origin"
19:10jibyeah
19:10jibtoo many relationships
19:11bzWhat you can do is look at the settings object, which has an origin
19:11bzhttps://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-origin
19:11bzRight
19:11bzSo if this were all one big spec
19:11bzwe sould not have separate Realms and settings objects
19:11bzIt would just be a single object
19:11jibmakes sense
19:12bzThe fact that they're separate concepts is basically Conway's Law in action
19:13jibheh
19:13bzanyway, for your purposes you can take the relevant settings object
19:13bzlook at its origin
19:14jibso then for getUserMedia, origin should be the relevant settings object's origin (double-keyed with top-level browsing context's active document's ... ?)
19:14bzthen if you know you're in a window context, look at its responsible document
19:14jibok
19:14bzCheck whether that's fully active.
19:14jibright
19:14bzIf so, get the toplevel browsing context of the responsible browsing context.
19:14bzGet its active document.
19:14bzGrab its origin
19:14jibcool
19:15bzChase all the pointers. ;)
19:15jibso one remaining issue I notice with permissions is that spec don't seem to talk much about what happens when a navigating away from a doc
19:15bzmmhm
19:16bzLike while a prompt is up, say?
19:16jibright
19:16jibor what should happen with outstanding promises
19:17bzPromises are bad
19:17jibI suggested returning "denied" in the permission issue I filed, but I also wondered if it would be better to not do anything at all somehow
19:17jibwell
19:17bzhttps://github.com/whatwg/html/issues/2621
19:17jibpromises make us think we should resolve them. People don't seem to have a problem with saying we shouldn't call any callbacks once we navigate away
19:18jibor reject them
19:18bzsure
19:18bzin your case there are sane solutions
19:18bzThe general promise case is busted wrt navigation
19:19jibfun
19:20jibpromises are just fancy callbacks imho
19:20jibwith microtask sprinkles
19:20smaug(our promises don't use microtasks ;) )
19:21bzjib: the problem is the factoring
19:21jibthey don't?
19:21bzjib: they're defined in ES, and implemented in ES
19:21bzjib: and ES has no concept of navigation
19:21bzjib: back to Conway's Law....
19:21smaug( they will. Trying to get that fix finally, with help from others. )
19:21jibright, though for browser APIs returning them, we have options
19:21bzjib: they basically defined a simplistic event loop
19:21bzjib: That doesn't play nice with the HTML event loop
19:22bzjib: then all attempts to make them work together have failed
19:22jibe.g. on PeerConnection we never resolve or reject any promises we return past pc.close()
19:22bzjib: because TC39 wants to control the event loop
19:22bzjib: but so does the HTML spec
19:22bzjib: It's a long story.
19:22jibsounds like it
19:23jibWhoever controls the event loop...
19:24jibbz: ok thanks, I think I have a much better understanding now! Will file an issue on mediacapture and put up a PR. May ping you for review.
19:24bzIt's a matter of time until the sandworms come, I tell you.
19:24bzjib: OK
19:24jibhehe
19:24* jib got the reference
19:25bkellywow, this channel got a lot more itneresting since I last looked at it
19:28annevkThere is some PR that makes ECMAScript just queue things, but Domenic hasnt worked on it for a while
19:28* bz goes back to trying to figure out how to fix the xml content sink sanely
19:32smaugehsan: ping
19:32ehsansmaug, pong
19:32smaugehsan: that range bug. Can it happen if some other script runner changes the DOM before this range's script runner runs?
19:33ehsansmaug, not after the patch...
19:33smaughmm, I think I see :)
19:34smaugyeah, ok, we're from DOM point of view at a "stable state"
19:43ehsanright
19:47bzWe need an even more stable state
19:47bza DOM-9 sort of thing
7 Oct 2017
No messages
   
Last message: 11 days and 3 hours ago