Re add inert #4288

alice · 2019-01-14T00:31:19Z

Re-adds the inert attribute, and clarifies mouse pointer and event behaviour for the inert concept.

See https://github.com/WICG/inert/blob/master/explainer.md for justification.

Taken over from #1474.

💥 Error: Wattsi server error 💥

PR Preview failed to build. (Last tried on Mar 31, 2021, 2:47 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 Related URL

<html>
<head><title>524 Origin Time-out</title></head>
<body bgcolor="white">
<center><h1>524 Origin Time-out</h1></center>
<hr><center>cloudflare-nginx</center>
</body>
</html>

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

alice · 2019-01-14T00:42:57Z

Replying to #1474 (comment)

The new text doesn't seem right though. It has the following normative consequence:

document.body.addEventListener("foo", () => console.log("foo event fired"));
document.body.inert = true;

document.body.dispatchEvent(new Event("foo")); // doesn't log anything

That actually seems right to me. @robdodson had the same reaction when I checked with him.

(Edited to add) Specifically, I think it would be more confusing for authors if some events worked, sometimes, than if events simply didn't work.

However, I just realised there's still an issue with event delegation as written, so some edits to UI events are still needed...

In addition it's a pretty heavy monkeypatch to the event dispatch algorithm, although I guess that was already true for the previous patch in some ways.

Agreed.

It seems like you're going for (3) in #1474 (comment), right? My stab at some text for that would be "User interactions which would otherwise cause events to be targeted at an inert element must instead do nothing". Not sure that's great either...

More like (2) (which was poorly worded) - the event fires, but nothing happens at the targeting phase. Capture/bubble work as normal.

alice · 2019-01-14T00:51:53Z

However, I just realised there's still an issue with event delegation as written, so some edits to UI events are still needed...

Actually, I think we can avoid that. Will make some edits and ping this PR when ready.

domenic · 2019-01-14T18:45:26Z

That actually seems right to me. @robdodson had the same reaction when I checked with him.

Hmm. I don't think this is OK. We can't have a high-level, UI/UX HTML-level content attribute interfere with foundational EventTarget-level technologies like dispatching custom events. We should only be changing UI interaction behavior, not general event functionality.

alice · 2019-01-14T21:51:44Z

Ok, I'm convinced. Will look at UI Events.

alice · 2019-01-15T04:46:50Z

Hm - so I had a chat to Gary K and apparently there's no easy place for it to hook in right now.

Some options:

Make a vague reference to UI Events, details to be filled in in that spec.
Spec what is currently implemented in Chrome, which is:
- Element cannot be focused
- Element cannot be selected
- Element is not visible to hit testing - this seems quite difficult to actually spec, since I can't find where hit testing is defined.

annevk · 2019-01-15T15:09:05Z

Element is not visible to hit testing

Hit testing is indeed not defined, but can be observed through various means (e.g., elementFromPoint()). Perhaps this can be defined in terms of the pointer-events CSS property? It seems if it cannot be hit tested or focused, you cannot get to it with UI Events either, right? So that would automatically be solved.

Focusing is defined in HTML, so could be patched there. Selection is in https://w3c.github.io/selection-api/.

domenic · 2019-01-15T19:23:54Z

I don't think there's a great solution here in terms of creating a perfect spec, at least until w3c/uievents#200 is done. So we just need to focus practically on writing a good enough spec to get interop.

For that route, I would:

Hook into focus. Oh, this is already done in the spec today, yay! :)
Have a vague summary statement (like "the user agent must act as if the node was absent for the purposes of targeting user interaction events" but more accurate). Then help out by adding more details corresponding to what Chrome intends to implement. Some examples:
- "The element is ignored for the purposes of "hit testing" (a not-yet-defined part of the web platform, related to the 'pointer-events' CSS property)"
- Explicitly list the events that will never fire on the element.
- Expand the current note about "may prevent the user from selecting text in that node" to also cover http://localhost:8080/#dom-textarea/input-setselectionrange (what does Chrome do for that method on inert elements?)

As for defining in terms of pointer-events, it appears that's not specced anywhere precisely because properly speccing it would require defining hit testing: https://wiki.csswg.org/spec/css4-ui#pointer-events :)

annevk · 2019-01-16T08:49:20Z

I'm not sure I understand why not. It's commonly understood that most UI Events always goes through hit testing (keyboard stuff relies on focus). pointer-events affects hit testing and has a none value. So if we specified that user agents need to act as if pointer-events is none for the relevant element, that would be reasonably well-defined and even future proof (i.e., need no adjusting when UI Events is properly specified or even when hit testing is properly specified).

domenic · 2019-01-16T13:29:12Z

@alice, can you comment on how Chrome's implementation of inert="" (or, alternately, the ideal implementation of inert="") maps onto Chrome's pointer-events implementation?

alice · 2019-01-16T22:14:07Z

When checking whether a layout object/paint fragment is visible to hit testing, the associated Node is queried for both pointer events style and inertness.
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/layout_object.h?type=cs&sq=package:chromium&g=0&l=1709

pointer-events explicitly allows the "transparent to click events" behaviour, which I find frankly alarming if not paired with at least partial transparency.

alice · 2019-01-17T04:16:41Z

I spoke to Tab about this, and he explained what pointer-events: none actually means, i.e. "no part (none) of the shape defined by this thing is visible to pointer events". This to me makes it seem like less of a good fit for inert, which Tab described as more "absorbing events", which I liked, and proposed that I could propose some kind of pointer-events-behavio[u]r property to go along with inert.

So, I think that's kind of back to the drawing board a little bit. I definitely want the "absorb events" behaviour rather than the "transparent to hit testing" behaviour. Will keep thinking about how that might be written.

domenic · 2019-01-17T16:24:40Z

Sounds like the difference between the two will make for some good web platform tests! But yeah, writing up bespoke text that's clear enough to get interoperability for now, and later maybe grounding in a new CSS primitive, makes sense to me.

alice · 2019-03-18T05:25:27Z

I added a blacklist of events not to be fired, and a comment about setSelectionRange().

I decided the hit testing piece is probably unnecessary - for example, getElementsFromPoint() should probably still work for things like contrast ratio testing (used to figure out background colour).

alice · 2019-03-19T04:30:04Z

On further thought, decided I did need to say something about hit testing - these elements will still show up for hit testing in general, but events which would be targeted by hit testing should be targeted at ancestors instead.

The wording is a little convoluted - my intention is to avoid the "click through to an unrelated element" scenario which pointer-events: none allows, and instead require that the event target be an ancestor, but still an ancestor which would be in elementsFromPoint.

annevk

Thanks for working on this!

annevk · 2019-03-20T13:06:59Z

source

+
+  <ul>
+   <li>
+    <p>the user agent must not fire any of the following events on the node:</p>


When would this safelist apply? Does this only apply when the user agent is responsible for dispatching these events? Or would this also happen for synthetic events?

It seems highly likely this safelist will go out-of-date when new events get added. What about pointer events for instance? I'd be much more comfortable with this kind of setup if there were some intrinsic properties on the event object that indicate whether to filter it as such.

In either case.

There's not really any good option here; I agree the blacklist will need to be kept up to date until we have some kind of way of referring to user input events as a class.

So then it should probably be defined as a modification of https://dom.spec.whatwg.org/#concept-event-dispatch?

Are pointer events in or out? That wasn't clear from your answer.

Does it apply regardless of what class the event implements? E.g., click with CustomEvent gets filtered?

A lot of that seems rather different from existing setups, so I'm not entirely convinced it's the design we want to use.

(FWIW, we try to avoid using "whitelist" and "blacklist", preferring "safelist" and "blocklist": https://whatwg.org/style-guide#tone.)

Understood re language (and thanks for the pointer) - I meant more that it's a blocklist rather than a safelist, since these events will not fire.

I do think this is the design we want in terms of behaviour - in lay terms, we want any event which is or could be fired via a user interaction (which, yes, includes pointer events) not to be fired on an element which is inert. Perhaps I can find a better way to say that.

I really don't think this should change event dispatch or prevent people from doing dispatchEvent... I think instead inert should be about blocking user interaction from translating into events.

Stated another way, I think it's better if the base EventTarget class does not give special semantics to certain event names, or to whether the EventTarget is actually a HTML Element with a certain content attribute. That seems like a layering violation; EventTarget should just be concerned with a generic eventing system.

Hm, I'm not sure we'd want people to be able to dispatch click events programmatically on inert elements, would we?

I don't think we should stop them... programmatic event dispatch is basically just an indirect way of doing function calls, by coordinating everything through various strings. Whether those strings are named "click" or "myevent" shouldn't, IMO, effect whether this indirect-function-call mechanism works.

Hmmmm. I guess we could try this out, then:

Remove the list of forbidden events

Include the "topmost event target" re-targeting language

Include the existing language in https://html.spec.whatwg.org/#focus-processing-model about not focusing inert elements and note in the inert section that inert elements generally aren't focusable

Include the points about find in page and selection potentially being disallowed by the user agent.

That would make inert elements effectively unable to be interacted with via a user interaction, I think.

(Did that ☝️)

source

annevk · 2019-03-20T13:39:41Z

source

+
+   <li><p>the user agent may prevent the user from selecting text in that node, and may prevent
+   code calling <code data-x="dom-textarea/input-setSelectionRange">setSelectionRange()</code>
+   on the node.</p></li>


This would be better defined as a modification of the setSelectionRange() algorithm, as currently it's unclear what this means.

annevk · 2019-03-20T13:41:29Z

source

-  <span data-x="inert">inertness</span>.</p>
+  named "inert". This section merely defines an abstract <em>concept</em> of <span
+  data-x="inert">inertness</span>. See <code data-x="attr-inert">inert</code> for an explanation of
+  the attribute of the same name.</p>


I'd make this something like "See also the inert attribute." if we think we need to keep this note at all.

domenic

This looks great to me. I made some minor editorial tweaks, but I am quite happy with the event dispatching changes. I know @annevk and @smaug---- are a bit more demanding there, so it'll be good to get their take. And of course web platform tests will help.

But from my perspective, this is ready to merge.

annevk · 2019-04-16T10:09:50Z

source

-    is omitted, it will be reset to be the platform default (none or forward).</p>
+    <p>If <var>element</var> is not <span>inert</span>, changes the selection to cover the given
+    substring in the given direction. If the direction is omitted, it will be reset to be the
+    platform default (none or forward).</p>


This is the non-normative description of the method. The normative description should also be changed, no?

Added an early return into the normative description.

So, reading this more closely, shouldn't this affect the other selection methods as well?

I moved it into the "set the selection range" algorithm, what do you think?

annevk · 2019-04-16T10:12:24Z

source

+   <li>
+    <p>If an event would be fired as a result of user input, such that the
+    <span>inert</span> element would be the <span data-x="topmost-event-target">topmost event
+    target</span>, an alternative <span data-x="event-target">event target</span> must be found as


Is topmost event target always an element? The earlier text suggests it could be a text node too.

https://w3c.github.io/uievents/#topmost-event-target says "[t]he topmost event target MUST be the element highest in the rendering order which is capable of being an event target", so it seems like we can assume it is always an element.

Maybe? Not sure UI Events can be trusted. But that means the earlier text is wrong, no?

Not necessarily. The following two points specifically concern text nodes:

The user interaction events, agent may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), page"); and

The user agent may prevent the user from selecting text in that node.

What is unclear is if the current text applies when it's not an element that is inert or if it should be ignored in that case. (Perhaps there's no way to get UI events to fire on non-elements though, but then it comes back to the synthetic cases and I've somewhat forgotten what we decided on there.) It's rather hard to revisit this every couple of weeks and remember all the various details. 😟

On reflection, I'm happy to change it to Node, seems like that would be the most inclusive and not inaccurate.

annevk · 2019-04-16T10:14:25Z

source

+       <li><p>Add <var>candidate</var> to <var>ineligible</var>.</p></li>
+       <li><p>Let <var>candidate</var> be the element which would be the <span
+       data-x="topmost-event-target">topmost event target</span> if all the elements in
+       <var>ineligible</var> were excluded from consideration.</p></li>


So you'd have to perform hit testing again? In particular, if a position a div under an inert element, that div element would become candidate?

Do we have tests for that?

Working on tests, yeah.

The intent is that if you position a div which is not an ancestor under the inert element, that div would not be targeted. The old wording, and indeed the old implementation in blink, would have targeted the event at the non-ancestor div, as does pointer-events: none.

Clarification, sorry - the div would become candidate, but would be added to ineligible as it is not an ancestor.

I've looked at implementing this in Blink, and it seems to be possible to do without performing redundant hit testing at least in our codebase - rather, you continue the hit testing process until a suitable candidate is found.

Ah right, thanks. Ideally this shares infrastructure with https://drafts.csswg.org/cssom-view/#dom-document-elementsfrompoint I think, which should use the same primitive.

This also needs to be rephrased a bit using "Set candidate to" as you already initialized it earlier.

Ideally this shares infrastructure with https://drafts.csswg.org/cssom-view/#dom-document-elementsfrompoint I think, which should use the same primitive.

Do you mean the implementation, or the spec? The implementation does indeed share infastructure.

This also needs to be rephrased a bit using "Set candidate to" as you already initialized it earlier.

Done, thanks.

(Edited because I originally pasted the wrong thing into my quote)

I meant both.

There is a lot of spec technical debt to be cleared up around hit testing.

UIEvents says:

The topmost event target MUST be the element highest in the rendering order which is capable of being an event target. In graphical user interfaces this is the element under the user’s pointing device. A user interface’s hit testing facility is used to determine the target. For specific details regarding hit testing and stacking order, refer to the host language.

As far as I know, "hit testing" is not defined for HTML.

The elementsFromPoint definition says:

For each layout box in the viewport, in paint order, starting with the topmost box, that would be a target for hit testing at coordinates x,y even if nothing would be overlapping it, when applying the transforms that apply to the descendants of the viewport, append the associated element to sequence.

without even attempting to define "hit testing" or "paint order".

source

annevk · 2019-04-16T10:21:17Z

source

+     <li><dfn data-x="event-compositionupdate" data-x-href="https://w3c.github.io/uievents/#event-type-compositionupdate"><code>compositionupdate</code></dfn> event</li>
+     <li><dfn data-x="event-compositionend" data-x-href="https://w3c.github.io/uievents/#event-type-compositionend"><code>compositionend</code></dfn> event</li>
+
+     <li>The <dfn data-x="event-target" data-x-href="https://w3c.github.io/uievents/#event-target">event target</dfn> concept</li>


I don't think we should add this reference as it's rather confusing and duplicative of the DOM Standard.

Hm, the term event target is not actually defined in the DOM standard, and the way I'm using it refers specifically to the sense used in UIEvents.

Okay, but I think we need to find some other way as UI Events really shouldn't define this term and we shouldn't take a new dependency on that "flaw".

This doesn't seem like a reasonable objection, to be honest. I don't think there is another way (if you think of one, please let me know), and I don't think it affects implementability.

I'm happy to discuss this further, but I don't think adding a dependency on a bug in UI Events is a good strategy.

The bug being that UIEvents defines this term?

Per my understanding of the setup here all of this happens before the dispatch algorithm. The dispatch algorithm is handed a target and an event, but it might fiddle with these as it sees fit (e.g., to account for shadow trees).

The manipulation you define is therefore about the eventual input for the dispatch algorithm at which point you can't really speak about an event target. And UI Events also shouldn't define the term the way it does because that gives the impression you are able to manipulate it in this manner.

Hm. Leaving aside "topmost event target", the only references to "event target" are these two, in the retargeting rules:

... an alternative event target must be found as follows:

If candidate is not null, let candidate be the new event target.

I agree that the manipulation is about the eventual input for the dispatch algorithm. The input for these steps is what the UIEvents spec refers to as the "topmost event target" (really more a potential event target), and the output is the input to the dispatch algorithm.

I think this is correct; we only want to do this manipulation when there is hit testing involved, not as part of the dispatch algorithm in general. Effectively, we want to change the output of the hit testing.

source

annevk · 2019-04-16T10:22:08Z

source

+
+  <ul>
+   <li>
+    <p>If an event would be fired as a result of user input, such that the


It's not clear what this would count. E.g., form submission can be the result of user input, can that be prevented?

Would the form be the topmost event target in that case?

It's still not entirely clear to me what topmost event target means.

A better question, to help us figure this out: what user input would cause a form to be submitted?

There might be a click somewhere or some such (though I suppose even click is not technically user input).

I can read that in two ways:

The user clicks at the location of the submit button within the form.

In that case, the submit button is the topmost event target, and since it is within the form and the form is inert, the click event is retargeted, possibly at the form's parent element (depending on the circumstances which led to the form being inert).

The user clicks at the location of a non-inert button outside the form, which would have the effect of submitting the form due to javascript running in its click event handler.

In that case, the button is the topmost event target, and the click event is fired as a result of the user interaction since the button is not inert.

I'm guessing you're thinking of the second case? I guess you could argue that in that case, the form submission event is "as a result of user input", making "topmost event target" ambiguous, but I don't know that it would be a likely interpretation.

alice · 2019-04-17T06:15:38Z

Just a quick comment to say thanks for the thorough review.

I'll be out for the next week and a half so it might take me a bit to get back to all of it, but just wanted to say it's well appreciated, and in particular that I'm planning to work on the WPT tests for the new behaviour (including retargeting) soon.

alice · 2019-05-02T23:48:59Z

Sorry for all the noise, I am so bad at github. Anyway, I've tried to address all your comments (WPT tests are still WIP) - thanks again!

alice · 2019-05-06T03:36:56Z

(Not sure why the build failed; it passed for me locally. Would it be possible to re-run?)

domenic · 2019-05-07T14:53:52Z

Sorry for the delay; build re-started, and filed whatwg/html-build#194 to track making the script more resilient to network failures.

asurkov · 2020-07-31T14:47:30Z

I think this hasn't been merged as it only has one implementation so far.

Firefox 81 makes a second implementation, see https://bugzilla.mozilla.org/show_bug.cgi?id=1655722

domenic · 2020-07-31T17:33:35Z

Excellent! Do either Firefox or Chrome have plans to ship?

carmacleod · 2020-08-24T23:17:25Z

@asurkov Just to confirm, will inert be behind a flag in Firefox 81?

@alice Is inert still behind a feature flag in Chrome?

[Edit, April 9, 2021: Yes, still behind a flag in both Firefox and Chrome. The only mainstream browser that doesn't have an implementation yet is webkit/Safari].

asurkov · 2020-08-31T20:07:40Z

@asurkov Just to confirm, will inert be behind a flag in Firefox 81?

correct, Firefox 81 will have html5.inert.enabled preference to turn the feature on

Excellent! Do either Firefox or Chrome have plans to ship?

I think there are at least two blocking issues before it can be shipped in Firefox, which are

accessibility mapping, Inert subtrees mapping w3c/html-aam#295
event retargeting issue, there is disperacy between Firefox and Chromium implementations, in particular the issue is related to inert: Hit-testing / selection behavior shouldn't be magical. #5650

This reverts the edits made in whatwg@5ddfc78 (and whatwg@b0ec716) which removed the inert attribute. The inert attribute was originally added in whatwg@2fb24fc as part of the <dialog> feature. It is currently being re-considered as part of the https://github.com/WICG/inert proposal.

…es and iframes

rniwa · 2021-08-24T07:44:48Z

source

+     <li><p>Let <var>ineligible</var> be an empty list.</p></li>
+     <li>
+      <p>While <var>candidate</var> is <span>inert</span>, or <var>candidate</var> is not an an
+      ancestor of <var>originalElement</var> in the <span>flat tree</span>:</p>


I don't think the use of flat tree here makes much sense. This would mean that an element becomes inert if it's assigned to a slot which is inert. I don't think that's right given inert is a content attribute. We typically don't let content attribute on an element affecting slotted nodes or their descendants.

I think what we want here instead is the concept of shadow-including inclusive ancestor.

Based on work in #4288 by Alice Boxhall. Tests: https://github.com/web-platform-tests/wpt/tree/master/inert. Closes #5650. Co-authored-by: Alice Boxhall <aboxhall@chromium.org>

annevk · 2022-03-10T16:55:34Z

Closing as part of 755ae90 (#7134).

Based on work in whatwg#4288 by Alice Boxhall. Tests: https://github.com/web-platform-tests/wpt/tree/master/inert. Closes whatwg#5650. Co-authored-by: Alice Boxhall <aboxhall@chromium.org>

alice mentioned this pull request Jan 14, 2019

Re-add the inert="" attribute #1474

Closed

alice mentioned this pull request Mar 18, 2019

Support? GoogleChrome/inert-polyfill#7

Open

alice force-pushed the re-add-inert branch from be0a03d to 84203ae Compare March 18, 2019 05:22

alice force-pushed the re-add-inert branch from 380b9cd to ea7f64b Compare March 19, 2019 04:28

annevk reviewed Mar 20, 2019

View reviewed changes

alice force-pushed the re-add-inert branch 2 times, most recently from 104a982 to b9b3fb2 Compare March 22, 2019 04:17

alice force-pushed the re-add-inert branch from f1d35a4 to 2dacebe Compare April 12, 2019 04:37

domenic approved these changes Apr 12, 2019

View reviewed changes

annevk reviewed Apr 16, 2019

View reviewed changes

alice force-pushed the re-add-inert branch from a41817c to e6638e8 Compare May 2, 2019 23:48

robdodson mentioned this pull request May 7, 2019

Browser vendor feedback WICG/inert#69

Open

Base automatically changed from master to main January 15, 2021 07:57

alice force-pushed the re-add-inert branch from f538a12 to 0bb4749 Compare February 16, 2021 09:46

alice mentioned this pull request Feb 16, 2021

inert attribute w3ctag/design-reviews#610

Closed

1 task

domenic and others added 11 commits March 31, 2021 13:41

Add advice to use default cursor

fea0edb

Clarify mouse pointer and event behaviour

4faaca3

Add touch events and comments on hit testing

0819a4b

Clarify event retargeting, and mention inertness in the definition of .

c173dae

Rephrase and capitalise

5da910e

Remove list of forbidden events, and clarify behaviour for shadow tre…

2f1b841

…es and iframes

Address Anne's comments

a69465a

s/when/while/

24ae880

Inert acts on the flat tree, not shadow-including descendants.

825167f

Fix up merge issues

2215756

alice force-pushed the re-add-inert branch from d4ed883 to 2215756 Compare March 31, 2021 02:46

alpadev mentioned this pull request May 3, 2021

Rework modal dialogs twbs/bootstrap#33804

Open

domenic force-pushed the main branch from 0947339 to 1b5099f Compare July 27, 2021 17:07

ddbeck mentioned this pull request Aug 17, 2021

docs(HTMLElement.inert): add missing spec mdn/browser-compat-data#11935

Closed

rniwa reviewed Aug 24, 2021

View reviewed changes

bkardell mentioned this pull request Oct 8, 2021

Add the inert attribute and tweak definition of inert subtrees #7134

Merged

5 tasks

JAWS-test mentioned this pull request Feb 8, 2022

The datepicker Dialog example uses aria-modal without making the rest of the page unavailable to all users w3c/aria-practices#2219

Open

annevk closed this Mar 10, 2022

nt1m mentioned this pull request Aug 21, 2024

[css-ui] Support setting offscreen content inert w3c/csswg-drafts#10711

Open

Re add inert #4288

Re add inert #4288

Conversation

alice commented Jan 14, 2019 • edited by pr-preview bot Loading

💥 Error: Wattsi server error 💥

alice commented Jan 14, 2019 • edited Loading

alice commented Jan 14, 2019

domenic commented Jan 14, 2019

alice commented Jan 14, 2019

alice commented Jan 15, 2019

annevk commented Jan 15, 2019

domenic commented Jan 15, 2019 • edited Loading

annevk commented Jan 16, 2019

domenic commented Jan 16, 2019

alice commented Jan 16, 2019

alice commented Jan 17, 2019 • edited Loading

domenic commented Jan 17, 2019

alice commented Mar 18, 2019

alice commented Mar 19, 2019 • edited Loading

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alice Apr 12, 2019 • edited Loading

Choose a reason for hiding this comment

domenic Apr 12, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alice May 2, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alice May 14, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alice commented Apr 17, 2019

alice commented May 2, 2019

alice commented May 6, 2019

domenic commented May 7, 2019

asurkov commented Jul 31, 2020

domenic commented Jul 31, 2020

carmacleod commented Aug 24, 2020 • edited Loading

asurkov commented Aug 31, 2020

Choose a reason for hiding this comment

alice commented Jan 14, 2019 •

edited by pr-preview bot

Loading

alice commented Jan 14, 2019 •

edited

Loading

domenic commented Jan 15, 2019 •

edited

Loading

alice commented Jan 17, 2019 •

edited

Loading

alice commented Mar 19, 2019 •

edited

Loading

alice Apr 12, 2019 •

edited

Loading

domenic Apr 12, 2019 •

edited

Loading

alice May 2, 2019 •

edited

Loading

alice May 14, 2019 •

edited

Loading

carmacleod commented Aug 24, 2020 •

edited

Loading