Re: [blink-dev] New API owner: Domenic Denicola

[Rakina Zata Amni]

Congrats Domenic!!

On Mon, Jan 22, 2024 at 7:25 AM Sangwhan Moon  wrote:

> Congratulations Domenic, looking forward to your contributions.
>
> On Jan 22, 2024, at 4:39, Mike Taylor  wrote:
>
> 
>
> +1 - congrats! I look forward to Domenic bringing his decade plus of web
> and standards experience to the group.
>
> (I think it was somewhere between 2010-2012 that I first saw Domenic give
> a talk at the NYC.js meetup and have been a fan since).
> On 1/21/24 4:24 AM, Yuki Shiino wrote:
>
> Congratulations!!!
>
>
> 2024年1月20日(土) 17:44 Mathias Bynens :
>
>> Thanks and congratulations, Domenic!
>>
>> On Fri, Jan 19, 2024 at 9:59 PM Rick Byers  wrote:
>>
>>> Hi blink-dev,
>>> +Domenic Denicola  has volunteered to donate his
>>> time and considerable web platform expertise to reviewing intent threads as
>>> an API owner. Domenic is very active in the web standards community
>>> including as an HTML editor, runs our spec mentors
>>>  program and has
>>> contributed helpfully to a wide variety of intent discussions over the past
>>> year. His nomination
>>> 
>>> was reviewed and approved 
>>> by the existing API owners today.
>>>
>>> Thank you Domenic!
>>>Rick
>>> --
>>> 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/CAFUtAY-Zq2WDWz0_UhfweWd4e4c1dr8OTaCaLXiW289pNKfDDg%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> 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/CADizRgadwW%2B6a-G9nycsuWdbzKpCFQcW%3Dj%3DutS48%2B6ULMWvC4w%40mail.gmail.com
>> 
>> .
>>
> --
> 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/CAN0uC_TG%2BchJr8dEBBPczJVKPtb4Pdc1OV0WQd-cFG-2EDbsww%40mail.gmail.com
> 
> .
>
> --
> 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/3f88c852-9c36-4090-a64a-3d4019afec83%40chromium.org
> 
> .
>
> --
> 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/B3BE5F38-D4BA-4521-8C96-288228FD2C4E%40chromium.org
> 
> .
>

-- 
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/CACPC1r4KVEf9bUSD85ryhqVxmJcc%3DJKC4SMWE7R27%2BgwsQ0-WQ%40mail.gmail.com.

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] How to check if a document is fully active in Blink?

[Rakina Zata Amni]

One particular part that might differ a bit than the currently specified
definition of "fully active" is the check for whether the page's lifecycle
state is "active" or not, as we should also categorize BFCached documents
(and maybe prerendered documents as well?) as not "fully active" (see this
section
 of
TAG's design principles guideline). This is important because in Chrome's
implementation we just keep a BFCached document as is without resetting the
frame/window, so checking only those won't be enough.

(+Domenic Denicola  and others are currently working
on updating the spec
 to
include the "lifecycle state" check too, probably by checking the browsing
context status?)

On Wed, Feb 23, 2022 at 4:51 AM Daniel Cheng  wrote:

> I would be supportive of adding Document::IsFullyActive(), even if the
> underlying implementation simply checks if Document::GetFrame() or
> Document::domWindow() is null. That makes the intent more explicit rather
> than a null test of a random pointer getter/field.
>
> Daniel
>
> On Tue, 22 Feb 2022 at 11:35, Stefan Zager  wrote:
>
>> I *think* (document->domWindow() != nullptr) is the right check for that.
>> It's more typical to see (document->GetFrame() != nullptr) in the code, and
>> that should also work; they should be interchangeable.
>>
>> On Tue, Feb 22, 2022 at 4:29 AM Raphael Kubo da Costa <
>> raphael.kubo.da.co...@intel.com> wrote:
>>
>>> Hi Blinkers,
>>>
>>> https://html.spec.whatwg.org/multipage/browsers.html#fully-active
>>> specifies what a fully active document is, and several specs check whether
>>> a document is fully active in their algorithms.
>>>
>>> WebKit has Document::isFullyActive(), which essentially implements
>>> HTML's definition:
>>> https://github.com/WebKit/WebKit/blob/ee5042294047abd231e9f86f623d48924cbc2309/Source/WebCore/dom/Document.cpp#L2976
>>>
>>> We don't seem to have anything similar in Blink though, and as far as I
>>> can see different parts of the code implement that check differently. Some
>>> examples I've encountered so far:
>>> - Check ExecutionContext::IsContextDestroyed()
>>> - Check Document::IsActive()
>>> - Check Document::IsActive() and Document::GetFrame()
>>> - Check ExecutionContextLifecycleObserver::DomWindow() or
>>> ExecutionContextClient::DomWindow() (and optionally check
>>> DomWindow()->GetFrame too)
>>>
>>> Is there a recommendation here?
>>>
>>> --
>>> 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/c8141c56-158e-fe2d-e5b3-a72201e63327%40intel.com
>>> 
>>> .
>>>
>> --
>> 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/CAHOQ7J_xkTqPmHt2zFW3e69nYG_rJvSB90-FYJb3G9wK%2BxnDqw%40mail.gmail.com
>> 
>> .
>>
> --
> 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/CAF3XrKo0AhjnMzACg9NyJeeE9Y1vTY6trtan%2Bwe36qgwS8gTpg%40mail.gmail.com
> 
> .
>

-- 
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/CACPC1r4rGcD8pRu1LPnB31io4wRb7T4vcQsV%2BLck-KCoBx1tFQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Remove clamping of setTimeout(..., 0)

[Rakina Zata Amni]

I had a quick chat with Philip about whether we want to fix
crbug.com/1209717 or not, and I think we don't need to fix that bug for
shipping this.
In the bug, the code expected a same-document history navigation (and its
scroll restoration) would happen synchronously, so any scroll changes that
happen after the navigation was initiated won't be overwritten by the
history scroll restore. Because all history navigation in Chrome needs to
go through the browser process, the same-document history navigation is
actually asynchronous, and so the history scroll restoration is also
asynchronous. Looks like this was fast enough before that the history
scroll restoration might happen before code with clamping of setTimeout,
but now that the clamping is being removed it's not fast enough, so we got
that regression.

That bug was derived from crbug.com/1205285, which is noted
 as having been fixed by Wikipedia since it's
showing a similar behavior
 on Firefox with
Fission. The fix

itself is very simple: they just needed to set history.scrollRestoration to
"manual". As the motivating bug has been fixed with a simple fix, and
asynchronous same-document history navigation has been in Chrome for a
while (and is also what Firefox is doing), I think we don't need to
reland/make the full fix for crbug.com/1209717.


On Tue, Oct 12, 2021 at 11:16 PM Philip Jägenstedt 
wrote:

> Hi Wanming,
>
> If the reason for reverting no longer applies, then trying to reland the
> fix sounds like a reasonable next step. If that is done and it sticks this
> time, it seems to me we might be ready for a final Intent to Ship for this.
> At least I don't know what more could be done to vet the change before
> trying to let it reach stable.
>
> Best regards,
> Philip
>
> On Tue, Oct 12, 2021 at 10:14 AM Wanming Lin 
> wrote:
>
>> Hi all,
>>
>> Thanks Philip's bridge, I've been connected with the release managers and
>> completed the new round of origin trial on M95 (we reached an agreement on
>> reverting the change after the first M95 Beta release itself). During this
>> period, I didn't receive any relevant bugs.
>>
>> But unfortunately, after the origin trial, the fix for the previous block
>> issue #1209717
>>  was
>> reverted due to regression at issue #1254867
>> , @rakina
>> is considering that maybe we can do nothing here because per
>> crbug.com/1205285#c16
>> , the
>> original bug on Wikipedia has been fixed on Wikipedia's side.
>>
>> So we are looking forward your feedbacks, on both the bug of #1209717
>>  and
>> what's the next step to move forward this intent-to-ship. Many thanks in
>> advance!
>>
>>
>> Thanks,
>>
>> Wanming
>> On Tuesday, August 31, 2021 at 8:32:59 PM UTC+8 Philip Jägenstedt wrote:
>>
>>> Hi Wanming, I'll put you in touch with our release managers so that
>>> they're aware of this happening.
>>>
>>> On Fri, Aug 27, 2021 at 5:38 PM Chris Harrelson 
>>> wrote:
>>>
 Sounds good to me.

 On Thu, Aug 26, 2021 at 7:07 PM Wanming Lin  wrote:

> Hi all,
>
> The CL
> 
> has been relanded and following's the new original plan:
>
>- Land the change to M95 - Done
>- Allow the change to reach M95 beta (promoted Sep 23)
>- Revert it on the M95 branch well before the stable cut/release
>(Cut Oct 12)
>- Get back to this thread with test reports on M95 beta
>
> Does that sound good to you? Looks like Philip is still on vacation,
> could someone help notice the release managers about this plan? Or just
> help me reach out the release managers. Many thanks!
>
> Thanks,
> Wanming
> On Friday, August 6, 2021 at 3:13:06 AM UTC+8 Chris Harrelson wrote:
>
>> Hi,
>>
>> On Tue, Aug 3, 2021 at 9:28 PM Wanming Lin 
>> wrote:
>>
>>> Hi Chris, Daniel and all,
>>>
>>> The blocker issue
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1209717 has
>>> been fixed now, and per above performance improvement @verwaest 
>>> reported,
>>> can we start testing on Beta again?
>>>
>>
>> Sure, go ahead and experiment on canary/dev/beta, and then come back
>> to us with any new findings.
>>
>>
>>>
>>> On Saturday, June 12, 2021 at 1:59:25 AM UTC+8 08629...@gmail.com
>>> wrote:
>>>
 Re:[blink-dev] Ineng to Ship:Remove clamping of set Up

 BGODL209B013

 ในวันที่ ศ. 11 มิ.ย. 2021 09:13 Wanming Lin 
 เขียนว่า: