Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Chris Harrelson]

LGTM3

On Wed, Jan 17, 2024 at 7:25 AM Mike Taylor  wrote:

> LGTM2
> On 1/17/24 10:24 AM, Yoav Weiss (@Shopify) wrote:
>
> LGTM1
>
> On Friday, January 12, 2024 at 9:13:56 AM UTC+1 Nonoka Muraki wrote:
>
>> spec PR was merged.(https://github.com/whatwg/html/pull/9933)
>>
>> On Friday, January 12, 2024 at 12:41:31 AM UTC+9 Mike Taylor wrote:
>>
>>> Thanks Rakina - right now the biggest blocker is the unlanded spec PR.
>>> Things should move pretty quickly once that's resolved.
>>> On 1/10/24 11:15 PM, Rakina Zata Amni wrote:
>>>
>>> > Hoping that the design doc can become an GH explainer with the usual
>>> format, as the design doc doesn't answer questions in the strucutre we like
>>> to see
>>>
>>> Can you clarify which part isn't answered yet in the explainer
>>> 
>>> ?
>>>
>>> From the list in your link:
>>>
>>>- The user-facing problem which needs to be solved;
>>>- Covered by this section
>>>   
>>> 
>>>   .
>>>- The proposed approach to solving the problem;
>>>- Covered by this section
>>>   
>>> 
>>>   .
>>>- The way the proposed solution may be used in practice to address
>>>the intended use cases, via example code;
>>>- Pretty much covered by this section
>>>   
>>> 
>>>  although
>>>   there's no actual code example. We will add the code example 
>>> (basically
>>>   just an event listener using the close event)
>>>- Any other venues (such as mailing list, pull requests or issue
>>>threads external to the location of the explainer) where the reader may
>>>catch up on discussions regarding the proposed feature or features;
>>>- The issue  is linked
>>>   from the explainer.
>>>- The alternatives which have already been considered and why they
>>>were not chosen;
>>>- Covered by this section
>>>   
>>> 
>>>   .
>>>- Accessibility, security and privacy implications which have been
>>>considered as part of the design process.
>>>- Security & Privacy is covered by this sectio
>>>   
>>> n,
>>>   and there is no accessibility implication introduced by the new event.
>>>
>>>
>>> Please let us know if there are any parts that need further
>>> clarification.
>>>
>>> (BTW just to update the thread, the TAG review
>>>  has been
>>> requested last month)
>>>
>>> On Thu, Jan 4, 2024 at 1:49 AM Alex Russell 
>>> wrote:
>>>
 +1 to Yoav's excitement about this. Thank you for pushing it forward.

 On TAG review, we're living in hope that the newly-expanded TAG will
 have more bandwidth and focus for reviews, but as Mike says, we're
 increasingly timing out. Filing for review at I2P time is always the
 pro-move, and I it's a bad look for us to be leaving it to late regardless.

 Hoping that the design doc can become an GH explainer with the usual
 format, as the design doc doesn't answer questions in the strucutre we like
 to see:

 https://w3ctag.org/explainers/

 Best,

 Alex

 On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike Taylor wrote:

> Gentle reminder to request approvals for the other review gates in
> chromestatus, thanks.
> On 12/1/23 1:05 PM, Mike Taylor wrote:
>
> On 11/30/23 10:56 PM, Fergal Daly wrote:
>
> On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:
>
>
> On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki 
> wrote:
> TAG review
>
> Not needed because This is a small feature where we just dispatch a
> new event.
>
>
> Unfortunately that's not a criteria for skipping a TAG review. Can you
> file one?
>
>
> I'm concerned by this because every TAG review I've seen in the last
> couple of years has taken months to get a response. If our own privacy
> review is positive and we have agreement with other vendors would we block
> on the TAG review?
>
> In practice, we don't block on TAG reviews, but we like to give them a
> chance to review or comment within a reasonable time period (typically a
> week or two).
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Mike Taylor]

LGTM2

On 1/17/24 10:24 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Friday, January 12, 2024 at 9:13:56 AM UTC+1 Nonoka Muraki wrote:

spec PR was merged.(https://github.com/whatwg/html/pull/9933
)

On Friday, January 12, 2024 at 12:41:31 AM UTC+9 Mike Taylor wrote:

Thanks Rakina - right now the biggest blocker is the unlanded
spec PR. Things should move pretty quickly once that's resolved.

On 1/10/24 11:15 PM, Rakina Zata Amni wrote:

> Hoping that the design doc can become an GH explainer with
the usual format, as the design doc doesn't answer questions
in the strucutre we like to see

Can you clarify which part isn't answered yet in the
explainer

?


From the list in your link:

  * The user-facing problem which needs to be solved;
  o Covered by this section

.
  * The proposed approach to solving the problem;
  o Covered by this section

.
  * The way the proposed solution may be used in practice to
address the intended use cases, via example code;
  o Pretty much covered by this section


 although
there's no actual code example. We will add the code
example (basically just an event listener using the
close event)
  * Any other venues (such as mailing list, pull requests or
issue threads external to the location of the explainer)
where the reader may catch up on discussions regarding
the proposed feature or features;
  o The issue
 is
linked from the explainer.
  * The alternatives which have already been considered and
why they were not chosen;
  o Covered by this section

.
  * Accessibility, security and privacy implications which
have been considered as part of the design process.
  o Security & Privacy is covered by this sectio

n,
and there is no accessibility implication introduced
by the new event.


Please let us know if there are any parts that need further
clarification.

(BTW just to update the thread, the TAG review
 has
been requested last month)

On Thu, Jan 4, 2024 at 1:49 AM Alex Russell
 wrote:

+1 to Yoav's excitement about this. Thank you for pushing
it forward.

On TAG review, we're living in hope that the
newly-expanded TAG will have more bandwidth and focus for
reviews, but as Mike says, we're increasingly timing out.
Filing for review at I2P time is always the pro-move, and
I it's a bad look for us to be leaving it to late regardless.

Hoping that the design doc can become an GH explainer
with the usual format, as the design doc doesn't answer
questions in the strucutre we like to see:

https://w3ctag.org/explainers/

Best,

Alex

On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike
Taylor wrote:

Gentle reminder to request approvals for the other
review gates in chromestatus, thanks.

On 12/1/23 1:05 PM, Mike Taylor wrote:


On 11/30/23 10:56 PM, Fergal Daly wrote:


On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9
Yoav Weiss wrote:


On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki
 wrote:
TAG review

Not needed because This is a small feature
where we just dispatch a new event.


Unfortunately that's not a criteria for
skipping a TAG review. Can you file one?


I'm concerned by this because every TAG review I've
seen in the last couple of years has taken months
to get a response. If our own privacy review is
positive and we have agreement with other vendors
woul

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Yoav Weiss (@Shopify)]

LGTM1

On Friday, January 12, 2024 at 9:13:56 AM UTC+1 Nonoka Muraki wrote:

> spec PR was merged.(https://github.com/whatwg/html/pull/9933)
>
> On Friday, January 12, 2024 at 12:41:31 AM UTC+9 Mike Taylor wrote:
>
>> Thanks Rakina - right now the biggest blocker is the unlanded spec PR. 
>> Things should move pretty quickly once that's resolved.
>> On 1/10/24 11:15 PM, Rakina Zata Amni wrote:
>>
>> > Hoping that the design doc can become an GH explainer with the usual 
>> format, as the design doc doesn't answer questions in the strucutre we like 
>> to see
>>
>> Can you clarify which part isn't answered yet in the explainer 
>> 
>> ? 
>>
>> From the list in your link:
>>
>>- The user-facing problem which needs to be solved;
>>- Covered by this section 
>>   
>> 
>>   . 
>>- The proposed approach to solving the problem;
>>- Covered by this section 
>>   
>> 
>>   . 
>>- The way the proposed solution may be used in practice to address 
>>the intended use cases, via example code;
>>- Pretty much covered by this section 
>>   
>> 
>>  although 
>>   there's no actual code example. We will add the code example 
>> (basically 
>>   just an event listener using the close event) 
>>- Any other venues (such as mailing list, pull requests or issue 
>>threads external to the location of the explainer) where the reader may 
>>catch up on discussions regarding the proposed feature or features;
>>- The issue  is linked 
>>   from the explainer. 
>>- The alternatives which have already been considered and why they 
>>were not chosen;
>>- Covered by this section 
>>   
>> 
>>   . 
>>- Accessibility, security and privacy implications which have been 
>>considered as part of the design process.
>>- Security & Privacy is covered by this sectio 
>>   
>> n,
>>  
>>   and there is no accessibility implication introduced by the new event. 
>>
>>
>> Please let us know if there are any parts that need further clarification.
>>
>> (BTW just to update the thread, the TAG review 
>>  has been requested 
>> last month)
>>
>> On Thu, Jan 4, 2024 at 1:49 AM Alex Russell  
>> wrote:
>>
>>> +1 to Yoav's excitement about this. Thank you for pushing it forward. 
>>>
>>> On TAG review, we're living in hope that the newly-expanded TAG will 
>>> have more bandwidth and focus for reviews, but as Mike says, we're 
>>> increasingly timing out. Filing for review at I2P time is always the 
>>> pro-move, and I it's a bad look for us to be leaving it to late regardless.
>>>
>>> Hoping that the design doc can become an GH explainer with the usual 
>>> format, as the design doc doesn't answer questions in the strucutre we like 
>>> to see:
>>>
>>> https://w3ctag.org/explainers/
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike Taylor wrote:
>>>
 Gentle reminder to request approvals for the other review gates in 
 chromestatus, thanks.
 On 12/1/23 1:05 PM, Mike Taylor wrote:

 On 11/30/23 10:56 PM, Fergal Daly wrote:

 On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:


 On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki  
 wrote:
 TAG review 

 Not needed because This is a small feature where we just dispatch a new 
 event.


 Unfortunately that's not a criteria for skipping a TAG review. Can you 
 file one?


 I'm concerned by this because every TAG review I've seen in the last 
 couple of years has taken months to get a response. If our own privacy 
 review is positive and we have agreement with other vendors would we block 
 on the TAG review?

 In practice, we don't block on TAG reviews, but we like to give them a 
 chance to review or comment within a reasonable time period (typically a 
 week or two).



-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/184aedde-7eb9-433f-b378-db2665df87cdn%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Nonoka Muraki]

spec PR was merged.(https://github.com/whatwg/html/pull/9933)

On Friday, January 12, 2024 at 12:41:31 AM UTC+9 Mike Taylor wrote:

> Thanks Rakina - right now the biggest blocker is the unlanded spec PR. 
> Things should move pretty quickly once that's resolved.
> On 1/10/24 11:15 PM, Rakina Zata Amni wrote:
>
> > Hoping that the design doc can become an GH explainer with the usual 
> format, as the design doc doesn't answer questions in the strucutre we like 
> to see
>
> Can you clarify which part isn't answered yet in the explainer 
> 
> ? 
>
> From the list in your link:
>
>- The user-facing problem which needs to be solved;
>- Covered by this section 
>   
> 
>   . 
>- The proposed approach to solving the problem;
>- Covered by this section 
>   
> 
>   . 
>- The way the proposed solution may be used in practice to address the 
>intended use cases, via example code;
>- Pretty much covered by this section 
>   
> 
>  although 
>   there's no actual code example. We will add the code example (basically 
>   just an event listener using the close event) 
>- Any other venues (such as mailing list, pull requests or issue 
>threads external to the location of the explainer) where the reader may 
>catch up on discussions regarding the proposed feature or features;
>- The issue  is linked 
>   from the explainer. 
>- The alternatives which have already been considered and why they 
>were not chosen;
>- Covered by this section 
>   
> 
>   . 
>- Accessibility, security and privacy implications which have been 
>considered as part of the design process.
>- Security & Privacy is covered by this sectio 
>   
> n,
>  
>   and there is no accessibility implication introduced by the new event. 
>
>
> Please let us know if there are any parts that need further clarification.
>
> (BTW just to update the thread, the TAG review 
>  has been requested 
> last month)
>
> On Thu, Jan 4, 2024 at 1:49 AM Alex Russell  
> wrote:
>
>> +1 to Yoav's excitement about this. Thank you for pushing it forward. 
>>
>> On TAG review, we're living in hope that the newly-expanded TAG will have 
>> more bandwidth and focus for reviews, but as Mike says, we're increasingly 
>> timing out. Filing for review at I2P time is always the pro-move, and I 
>> it's a bad look for us to be leaving it to late regardless.
>>
>> Hoping that the design doc can become an GH explainer with the usual 
>> format, as the design doc doesn't answer questions in the strucutre we like 
>> to see:
>>
>> https://w3ctag.org/explainers/
>>
>> Best,
>>
>> Alex
>>
>> On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike Taylor wrote:
>>
>>> Gentle reminder to request approvals for the other review gates in 
>>> chromestatus, thanks.
>>> On 12/1/23 1:05 PM, Mike Taylor wrote:
>>>
>>> On 11/30/23 10:56 PM, Fergal Daly wrote:
>>>
>>> On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:
>>>
>>>
>>> On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki  
>>> wrote:
>>> TAG review 
>>>
>>> Not needed because This is a small feature where we just dispatch a new 
>>> event.
>>>
>>>
>>> Unfortunately that's not a criteria for skipping a TAG review. Can you 
>>> file one?
>>>
>>>
>>> I'm concerned by this because every TAG review I've seen in the last 
>>> couple of years has taken months to get a response. If our own privacy 
>>> review is positive and we have agreement with other vendors would we block 
>>> on the TAG review?
>>>
>>> In practice, we don't block on TAG reviews, but we like to give them a 
>>> chance to review or comment within a reasonable time period (typically a 
>>> week or two).
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c1d7e05e-0980-4146-a028-273269d14c1an%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Mike Taylor]

Thanks Rakina - right now the biggest blocker is the unlanded spec PR. 
Things should move pretty quickly once that's resolved.


On 1/10/24 11:15 PM, Rakina Zata Amni wrote:
> Hoping that the design doc can become an GH explainer with the usual 
format, as the design doc doesn't answer questions in the strucutre we 
like to see


Can you clarify which part isn't answered yet in the explainer 
? 



From the list in your link:

  * The user-facing problem which needs to be solved;
  o Covered by this section

.
  * The proposed approach to solving the problem;
  o Covered by this section

.
  * The way the proposed solution may be used in practice to address
the intended use cases, via example code;
  o Pretty much covered by this section


 although
there's no actual code example. We will add the code example
(basically just an event listener using the close event)
  * Any other venues (such as mailing list, pull requests or issue
threads external to the location of the explainer) where the
reader may catch up on discussions regarding the proposed feature
or features;
  o The issue  is
linked from the explainer.
  * The alternatives which have already been considered and why they
were not chosen;
  o Covered by this section

.
  * Accessibility, security and privacy implications which have been
considered as part of the design process.
  o Security & Privacy is covered by this sectio

n,
and there is no accessibility implication introduced by the
new event.


Please let us know if there are any parts that need further clarification.

(BTW just to update the thread, the TAG review 
 has been 
requested last month)


On Thu, Jan 4, 2024 at 1:49 AM Alex Russell  
wrote:


+1 to Yoav's excitement about this. Thank you for pushing it forward.

On TAG review, we're living in hope that the newly-expanded TAG
will have more bandwidth and focus for reviews, but as Mike says,
we're increasingly timing out. Filing for review at I2P time is
always the pro-move, and I it's a bad look for us to be leaving it
to late regardless.

Hoping that the design doc can become an GH explainer with the
usual format, as the design doc doesn't answer questions in the
strucutre we like to see:

https://w3ctag.org/explainers/

Best,

Alex

On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike Taylor wrote:

Gentle reminder to request approvals for the other review
gates in chromestatus, thanks.

On 12/1/23 1:05 PM, Mike Taylor wrote:


On 11/30/23 10:56 PM, Fergal Daly wrote:


On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav
Weiss wrote:


On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki
 wrote:
TAG review

Not needed because This is a small feature where we
just dispatch a new event.


Unfortunately that's not a criteria for skipping a TAG
review. Can you file one?


I'm concerned by this because every TAG review I've seen in
the last couple of years has taken months to get a response.
If our own privacy review is positive and we have agreement
with other vendors would we block on the TAG review?

In practice, we don't block on TAG reviews, but we like to
give them a chance to review or comment within a reasonable
time period (typically a week or two).




--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7f7a2d3c-876e-4fec-bd36-254846cb6261%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Rakina Zata Amni]

> Hoping that the design doc can become an GH explainer with the usual
format, as the design doc doesn't answer questions in the strucutre we like
to see

Can you clarify which part isn't answered yet in the explainer

?

>From the list in your link:

   - The user-facing problem which needs to be solved;
   - Covered by this section
  

  .
   - The proposed approach to solving the problem;
   - Covered by this section
  

  .
   - The way the proposed solution may be used in practice to address the
   intended use cases, via example code;
   - Pretty much covered by this section
  

although
  there's no actual code example. We will add the code example (basically
  just an event listener using the close event)
   - Any other venues (such as mailing list, pull requests or issue threads
   external to the location of the explainer) where the reader may catch up on
   discussions regarding the proposed feature or features;
   - The issue  is linked from
  the explainer.
   - The alternatives which have already been considered and why they were
   not chosen;
   - Covered by this section
  

  .
   - Accessibility, security and privacy implications which have been
   considered as part of the design process.
   - Security & Privacy is covered by this sectio
  
n,
  and there is no accessibility implication introduced by the new event.


Please let us know if there are any parts that need further clarification.

(BTW just to update the thread, the TAG review
 has been requested
last month)

On Thu, Jan 4, 2024 at 1:49 AM Alex Russell 
wrote:

> +1 to Yoav's excitement about this. Thank you for pushing it forward.
>
> On TAG review, we're living in hope that the newly-expanded TAG will have
> more bandwidth and focus for reviews, but as Mike says, we're increasingly
> timing out. Filing for review at I2P time is always the pro-move, and I
> it's a bad look for us to be leaving it to late regardless.
>
> Hoping that the design doc can become an GH explainer with the usual
> format, as the design doc doesn't answer questions in the strucutre we like
> to see:
>
> https://w3ctag.org/explainers/
>
> Best,
>
> Alex
>
> On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike Taylor wrote:
>
>> Gentle reminder to request approvals for the other review gates in
>> chromestatus, thanks.
>> On 12/1/23 1:05 PM, Mike Taylor wrote:
>>
>> On 11/30/23 10:56 PM, Fergal Daly wrote:
>>
>> On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:
>>
>>
>> On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki 
>> wrote:
>> TAG review
>>
>> Not needed because This is a small feature where we just dispatch a new
>> event.
>>
>>
>> Unfortunately that's not a criteria for skipping a TAG review. Can you
>> file one?
>>
>>
>> I'm concerned by this because every TAG review I've seen in the last
>> couple of years has taken months to get a response. If our own privacy
>> review is positive and we have agreement with other vendors would we block
>> on the TAG review?
>>
>> In practice, we don't block on TAG reviews, but we like to give them a
>> chance to review or comment within a reasonable time period (typically a
>> week or two).
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r6vCsYVj0LsfcvRfg-qoz9u9RhasQBpLn4169qUsxv__g%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Alex Russell]

+1 to Yoav's excitement about this. Thank you for pushing it forward.

On TAG review, we're living in hope that the newly-expanded TAG will have 
more bandwidth and focus for reviews, but as Mike says, we're increasingly 
timing out. Filing for review at I2P time is always the pro-move, and I 
it's a bad look for us to be leaving it to late regardless.

Hoping that the design doc can become an GH explainer with the usual 
format, as the design doc doesn't answer questions in the strucutre we like 
to see:

https://w3ctag.org/explainers/

Best,

Alex

On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike Taylor wrote:

> Gentle reminder to request approvals for the other review gates in 
> chromestatus, thanks.
> On 12/1/23 1:05 PM, Mike Taylor wrote:
>
> On 11/30/23 10:56 PM, Fergal Daly wrote:
>
> On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:
>
>
> On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki  
> wrote:
> TAG review 
>
> Not needed because This is a small feature where we just dispatch a new 
> event.
>
>
> Unfortunately that's not a criteria for skipping a TAG review. Can you 
> file one?
>
>
> I'm concerned by this because every TAG review I've seen in the last 
> couple of years has taken months to get a response. If our own privacy 
> review is positive and we have agreement with other vendors would we block 
> on the TAG review?
>
> In practice, we don't block on TAG reviews, but we like to give them a 
> chance to review or comment within a reasonable time period (typically a 
> week or two).
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1143f224-0417-465e-961e-31d74a66c791n%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Mike Taylor]

Gentle reminder to request approvals for the other review gates in 
chromestatus, thanks.


On 12/1/23 1:05 PM, Mike Taylor wrote:


On 11/30/23 10:56 PM, Fergal Daly wrote:


On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:


On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki
 wrote:
TAG review

Not needed because This is a small feature where we just
dispatch a new event.


Unfortunately that's not a criteria for skipping a TAG review.
Can you file one?


I'm concerned by this because every TAG review I've seen in the last 
couple of years has taken months to get a response. If our own 
privacy review is positive and we have agreement with other vendors 
would we block on the TAG review?
In practice, we don't block on TAG reviews, but we like to give them a 
chance to review or comment within a reasonable time period (typically 
a week or two).


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bd8cbd8f-4451-4af5-9cea-709a54d0996c%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Mike Taylor]

On 11/30/23 10:56 PM, Fergal Daly wrote:


On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:


On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki
 wrote:
TAG review

Not needed because This is a small feature where we just
dispatch a new event.


Unfortunately that's not a criteria for skipping a TAG review. Can
you file one?


I'm concerned by this because every TAG review I've seen in the last 
couple of years has taken months to get a response. If our own privacy 
review is positive and we have agreement with other vendors would we 
block on the TAG review?
In practice, we don't block on TAG reviews, but we like to give them a 
chance to review or comment within a reasonable time period (typically a 
week or two).


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d0f88af5-83d9-43c3-a3be-cbcfc7e172da%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Fergal Daly]

On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:

I ran into a Chromium-internal case where having a `close` signal would've 
helped me reduce complexity significantly. So I'm very excited about this 
work.

I also believe 
 there's an 
equivalent mechanism in Electron. Might be worthwhile to get those folks 
involved and see if there are any learnings to be had.

On Tue, Nov 28, 2023 at 9:34 PM Torne (Richard Coles)  
wrote:

Android WebView exposes the ability to create and use MessagePorts to the 
host app through a Java API, and currently one of the limitations of this 
API is the lack of a signal about the channel being closed, which in some 
cases can lead to apps holding on to Java objects longer than intended.

So, I'm very happy to see this proposed for the web API side, as this 
should hopefully also enable us to support the same thing in WebView's Java 
API. +Peter Birk Pakkenberg  has been tackling some 
issues here recently.

On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki  
wrote:

Contact emails

murakinon...@chromium.org, m...@chromium.org, rak...@chromium.org

Explainer

https://github.com/fergald/explainer-messageport-close 


Specification

https://github.com/whatwg/html/pull/9933

Design docs

https://docs.google.com/document/d/1lXZU2Pk2ycitqj8aL9kxT2aauwXqp
A0vJDUalkXA29Y

Summary

Notifies one of the MessagePorts that the other port has been disentangled 
(i.e., close() is called, an owning document is destroyed, or the port is 
garbage collected).

Blink component

Blink 

Motivation

Channel Messaging API enables two separate scripts running in different 
browsing contexts to communicate directly. Once MessageChannel is created, 
we can access two entangled  MessagePorts (MessageChannel.port1 and 
MessageChannel.port2), transfer port2 to the other browsing context, 
allowing these two scripts to post and receive messages. 

The problem with this API is that there is currently no timely and reliable 
way to detect when a MessagePort becomes disentangled. This makes it 
difficult to release resources associated with ports. Some users have used 
the unload event to detect disconnection, but it is unreliable especially 
on mobile. Therefore, the approach available now is to hold a MessagePort 
in WeakRef and periodically check if this port has been garbage collected 
by using deref() or to make use of the pagehide event. However, this event 
is also not an effective solution. The reasons are as follows:

1) It doesn't work when the document crashes.

2) The port must cooperate in signaling the port is going to be 
disentangled.(i.e., the port must post the message which is "it is going to 
be closed" to the entangled port.)

3) It fires even if the page is not being destroyed and just enters BFCache.

Adding a close event helps to detect timely and reliably that MessagePort 
is disentangled and make it easier to release resources associated with 
ports.

Initial public proposal

https://github.com/whatwg/html/issues/1766#issuecomment-1708027883

Search tags

close , onclose 


TAG review

Not needed because This is a small feature where we just dispatch a new 
event.


Unfortunately that's not a criteria for skipping a TAG review. Can you file 
one?


I'm concerned by this because every TAG review I've seen in the last couple 
of years has taken months to get a response. If our own privacy review is 
positive and we have agreement with other vendors would we block on the TAG 
review?

F
 

 


Risks

Interoperability and Compatibility

None


Gecko:  Positive (https://github.com/mozilla/standards-positions/issues/914
) 


There are definitely positive signals on that thread, but it's not yet 
labeled as "positive" AFAICT.
 

Mozilla people are already involved in the initial Github issue 
.

WebKit: No response (https://github.com/WebKit/
standards-positions/issues/271) 

WebKit people are already involved in the initial Github issue 
.

Web developers: Positive (https://github.com/whatwg/html/issues/1766) 

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that 
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None


Is this feature fully tested by web-platform-tests 

?

Yes.

 https://chromium-review.googlesource.com/c/chromium/src/+/5003089

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

This is a small feature (just dispa

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Yoav Weiss]

Also, can you tick the review boxes in your Chrome status entry to kick off
security, privacy and other reviews?

On Wed, Nov 29, 2023 at 6:22 AM Yoav Weiss  wrote:

> I ran into a Chromium-internal case where having a `close` signal would've
> helped me reduce complexity significantly. So I'm very excited about this
> work.
>
> I also believe
>  there's
> an equivalent mechanism in Electron. Might be worthwhile to get those folks
> involved and see if there are any learnings to be had.
>
> On Tue, Nov 28, 2023 at 9:34 PM Torne (Richard Coles) 
> wrote:
>
>> Android WebView exposes the ability to create and use MessagePorts to the
>> host app through a Java API, and currently one of the limitations of this
>> API is the lack of a signal about the channel being closed, which in some
>> cases can lead to apps holding on to Java objects longer than intended.
>>
>> So, I'm very happy to see this proposed for the web API side, as this
>> should hopefully also enable us to support the same thing in WebView's Java
>> API. +Peter Birk Pakkenberg  has been tackling some
>> issues here recently.
>>
>> On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki 
>> wrote:
>>
>>> Contact emails
>>>
>>> murakinon...@chromium.org, m...@chromium.org, rak...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/fergald/explainer-messageport-close
>>> 
>>>
>>> Specification
>>>
>>> https://github.com/whatwg/html/pull/9933
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1lXZU2Pk2ycitqj8aL9kxT2aauwXqpA0vJDUalkXA29Y
>>>
>>> Summary
>>>
>>> Notifies one of the MessagePorts that the other port has been
>>> disentangled (i.e., close() is called, an owning document is destroyed, or
>>> the port is garbage collected).
>>>
>>> Blink component
>>>
>>> Blink
>>> 
>>>
>>> Motivation
>>>
>>> Channel Messaging API enables two separate scripts running in different
>>> browsing contexts to communicate directly. Once MessageChannel is created,
>>> we can access two entangled  MessagePorts (MessageChannel.port1 and
>>> MessageChannel.port2), transfer port2 to the other browsing context,
>>> allowing these two scripts to post and receive messages.
>>>
>>> The problem with this API is that there is currently no timely and
>>> reliable way to detect when a MessagePort becomes disentangled. This makes
>>> it difficult to release resources associated with ports. Some users have
>>> used the unload event to detect disconnection, but it is unreliable
>>> especially on mobile. Therefore, the approach available now is to hold a
>>> MessagePort in WeakRef and periodically check if this port has been garbage
>>> collected by using deref() or to make use of the pagehide event. However,
>>> this event is also not an effective solution. The reasons are as follows:
>>>
>>> 1) It doesn't work when the document crashes.
>>>
>>> 2) The port must cooperate in signaling the port is going to be
>>> disentangled.(i.e., the port must post the message which is "it is going to
>>> be closed" to the entangled port.)
>>>
>>> 3) It fires even if the page is not being destroyed and just enters
>>> BFCache.
>>>
>>> Adding a close event helps to detect timely and reliably that
>>> MessagePort is disentangled and make it easier to release resources
>>> associated with ports.
>>>
>>> Initial public proposal
>>>
>>> https://github.com/whatwg/html/issues/1766#issuecomment-1708027883
>>>
>>> Search tags
>>>
>>> close , onclose
>>> 
>>>
>>> TAG review
>>>
>>> Not needed because This is a small feature where we just dispatch a new
>>> event.
>>>
>>
> Unfortunately that's not a criteria for skipping a TAG review. Can you
> file one?
>
>
>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> Gecko:  Positive (
>>> https://github.com/mozilla/standards-positions/issues/914)
>>>
>>
> There are definitely positive signals on that thread, but it's not yet
> labeled as "positive" AFAICT.
>
>
>> Mozilla people are already involved in the initial Github issue
>>> .
>>>
>>> WebKit: No response (
>>> https://github.com/WebKit/standards-positions/issues/271)
>>>
>>> WebKit people are already involved in the initial Github issue
>>> .
>>>
>>> Web developers: Positive (https://github.com/whatwg/html/issues/1766)
>>>
>>> Other signals:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Yoav Weiss]

I ran into a Chromium-internal case where having a `close` signal would've
helped me reduce complexity significantly. So I'm very excited about this
work.

I also believe
 there's an
equivalent mechanism in Electron. Might be worthwhile to get those folks
involved and see if there are any learnings to be had.

On Tue, Nov 28, 2023 at 9:34 PM Torne (Richard Coles) 
wrote:

> Android WebView exposes the ability to create and use MessagePorts to the
> host app through a Java API, and currently one of the limitations of this
> API is the lack of a signal about the channel being closed, which in some
> cases can lead to apps holding on to Java objects longer than intended.
>
> So, I'm very happy to see this proposed for the web API side, as this
> should hopefully also enable us to support the same thing in WebView's Java
> API. +Peter Birk Pakkenberg  has been tackling some
> issues here recently.
>
> On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki 
> wrote:
>
>> Contact emails
>>
>> murakinon...@chromium.org, m...@chromium.org, rak...@chromium.org
>>
>> Explainer
>>
>> https://github.com/fergald/explainer-messageport-close
>> 
>>
>> Specification
>>
>> https://github.com/whatwg/html/pull/9933
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1lXZU2Pk2ycitqj8aL9kxT2aauwXqpA0vJDUalkXA29Y
>>
>> Summary
>>
>> Notifies one of the MessagePorts that the other port has been
>> disentangled (i.e., close() is called, an owning document is destroyed, or
>> the port is garbage collected).
>>
>> Blink component
>>
>> Blink
>> 
>>
>> Motivation
>>
>> Channel Messaging API enables two separate scripts running in different
>> browsing contexts to communicate directly. Once MessageChannel is created,
>> we can access two entangled  MessagePorts (MessageChannel.port1 and
>> MessageChannel.port2), transfer port2 to the other browsing context,
>> allowing these two scripts to post and receive messages.
>>
>> The problem with this API is that there is currently no timely and
>> reliable way to detect when a MessagePort becomes disentangled. This makes
>> it difficult to release resources associated with ports. Some users have
>> used the unload event to detect disconnection, but it is unreliable
>> especially on mobile. Therefore, the approach available now is to hold a
>> MessagePort in WeakRef and periodically check if this port has been garbage
>> collected by using deref() or to make use of the pagehide event. However,
>> this event is also not an effective solution. The reasons are as follows:
>>
>> 1) It doesn't work when the document crashes.
>>
>> 2) The port must cooperate in signaling the port is going to be
>> disentangled.(i.e., the port must post the message which is "it is going to
>> be closed" to the entangled port.)
>>
>> 3) It fires even if the page is not being destroyed and just enters
>> BFCache.
>>
>> Adding a close event helps to detect timely and reliably that MessagePort
>> is disentangled and make it easier to release resources associated with
>> ports.
>>
>> Initial public proposal
>>
>> https://github.com/whatwg/html/issues/1766#issuecomment-1708027883
>>
>> Search tags
>>
>> close , onclose
>> 
>>
>> TAG review
>>
>> Not needed because This is a small feature where we just dispatch a new
>> event.
>>
>
Unfortunately that's not a criteria for skipping a TAG review. Can you file
one?


>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> Gecko:  Positive (
>> https://github.com/mozilla/standards-positions/issues/914)
>>
>
There are definitely positive signals on that thread, but it's not yet
labeled as "positive" AFAICT.


> Mozilla people are already involved in the initial Github issue
>> .
>>
>> WebKit: No response (
>> https://github.com/WebKit/standards-positions/issues/271)
>>
>> WebKit people are already involved in the initial Github issue
>> .
>>
>> Web developers: Positive (https://github.com/whatwg/html/issues/1766)
>>
>> Other signals:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes.
>>
>>  https://chromium-review.googlesource.com/c/chromium/src/+/5003089
>>
>> Flag name on chrome://flags
>>
>> None
>>
>> Finch feature name
>>
>> None
>>
>> Non-finch justification
>>
>> This is a small feature (just dispatchin

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Torne (Richard Coles)]

Android WebView exposes the ability to create and use MessagePorts to the
host app through a Java API, and currently one of the limitations of this
API is the lack of a signal about the channel being closed, which in some
cases can lead to apps holding on to Java objects longer than intended.

So, I'm very happy to see this proposed for the web API side, as this
should hopefully also enable us to support the same thing in WebView's Java
API. +Peter Birk Pakkenberg  has been tackling some
issues here recently.

On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki 
wrote:

> Contact emails
>
> murakinon...@chromium.org, m...@chromium.org, rak...@chromium.org
>
> Explainer
>
> https://github.com/fergald/explainer-messageport-close
> 
>
> Specification
>
> https://github.com/whatwg/html/pull/9933
>
> Design docs
>
>
> https://docs.google.com/document/d/1lXZU2Pk2ycitqj8aL9kxT2aauwXqpA0vJDUalkXA29Y
>
> Summary
>
> Notifies one of the MessagePorts that the other port has been disentangled
> (i.e., close() is called, an owning document is destroyed, or the port is
> garbage collected).
>
> Blink component
>
> Blink 
>
> Motivation
>
> Channel Messaging API enables two separate scripts running in different
> browsing contexts to communicate directly. Once MessageChannel is created,
> we can access two entangled  MessagePorts (MessageChannel.port1 and
> MessageChannel.port2), transfer port2 to the other browsing context,
> allowing these two scripts to post and receive messages.
>
> The problem with this API is that there is currently no timely and
> reliable way to detect when a MessagePort becomes disentangled. This makes
> it difficult to release resources associated with ports. Some users have
> used the unload event to detect disconnection, but it is unreliable
> especially on mobile. Therefore, the approach available now is to hold a
> MessagePort in WeakRef and periodically check if this port has been garbage
> collected by using deref() or to make use of the pagehide event. However,
> this event is also not an effective solution. The reasons are as follows:
>
> 1) It doesn't work when the document crashes.
>
> 2) The port must cooperate in signaling the port is going to be
> disentangled.(i.e., the port must post the message which is "it is going to
> be closed" to the entangled port.)
>
> 3) It fires even if the page is not being destroyed and just enters
> BFCache.
>
> Adding a close event helps to detect timely and reliably that MessagePort
> is disentangled and make it easier to release resources associated with
> ports.
>
> Initial public proposal
>
> https://github.com/whatwg/html/issues/1766#issuecomment-1708027883
>
> Search tags
>
> close , onclose
> 
>
> TAG review
>
> Not needed because This is a small feature where we just dispatch a new
> event.
>
> Risks
>
> Interoperability and Compatibility
>
> None
>
>
> Gecko:  Positive (
> https://github.com/mozilla/standards-positions/issues/914)
>
> Mozilla people are already involved in the initial Github issue
> .
>
> WebKit: No response (
> https://github.com/WebKit/standards-positions/issues/271)
>
> WebKit people are already involved in the initial Github issue
> .
>
> Web developers: Positive (https://github.com/whatwg/html/issues/1766)
>
> Other signals:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes.
>
>  https://chromium-review.googlesource.com/c/chromium/src/+/5003089
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> None
>
> Non-finch justification
>
> This is a small feature (just dispatching a new event) that doesn’t need
> experimentation.
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1495616
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5086799659794432
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA66OT2mWU9WJnkVzD2gm_

[blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Nonoka Muraki]

Contact emails

murakinon...@chromium.org, m...@chromium.org, rak...@chromium.org

Explainer

https://github.com/fergald/explainer-messageport-close


Specification

https://github.com/whatwg/html/pull/9933

Design docs

https://docs.google.com/document/d/1lXZU2Pk2ycitqj8aL9kxT2aauwXqpA0vJDUalkXA29Y

Summary

Notifies one of the MessagePorts that the other port has been disentangled
(i.e., close() is called, an owning document is destroyed, or the port is
garbage collected).

Blink component

Blink 

Motivation

Channel Messaging API enables two separate scripts running in different
browsing contexts to communicate directly. Once MessageChannel is created,
we can access two entangled  MessagePorts (MessageChannel.port1 and
MessageChannel.port2), transfer port2 to the other browsing context,
allowing these two scripts to post and receive messages.

The problem with this API is that there is currently no timely and reliable
way to detect when a MessagePort becomes disentangled. This makes it
difficult to release resources associated with ports. Some users have used
the unload event to detect disconnection, but it is unreliable especially
on mobile. Therefore, the approach available now is to hold a MessagePort
in WeakRef and periodically check if this port has been garbage collected
by using deref() or to make use of the pagehide event. However, this event
is also not an effective solution. The reasons are as follows:

1) It doesn't work when the document crashes.

2) The port must cooperate in signaling the port is going to be
disentangled.(i.e., the port must post the message which is "it is going to
be closed" to the entangled port.)

3) It fires even if the page is not being destroyed and just enters BFCache.

Adding a close event helps to detect timely and reliably that MessagePort
is disentangled and make it easier to release resources associated with
ports.

Initial public proposal

https://github.com/whatwg/html/issues/1766#issuecomment-1708027883

Search tags

close , onclose


TAG review

Not needed because This is a small feature where we just dispatch a new
event.

Risks

Interoperability and Compatibility

None


Gecko:  Positive (https://github.com/mozilla/standards-positions/issues/914
)

Mozilla people are already involved in the initial Github issue
.

WebKit: No response (
https://github.com/WebKit/standards-positions/issues/271)

WebKit people are already involved in the initial Github issue
.

Web developers: Positive (https://github.com/whatwg/html/issues/1766)

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None


Is this feature fully tested by web-platform-tests

?

Yes.

 https://chromium-review.googlesource.com/c/chromium/src/+/5003089

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

This is a small feature (just dispatching a new event) that doesn’t need
experimentation.

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1495616

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5086799659794432

This intent message was generated by Chrome Platform Status
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA66OT2mWU9WJnkVzD2gm_%2Bk%2Bewag5Lhq_K39Vo9WGdtGW79cQ%40mail.gmail.com.