Re: [blink-dev] Turning off use_v8_context_snapshot in non-production builds by default

[Daniel Cheng]

I'm guessing the root cause is this:

---
/b/s/w/ioajsmeisv/layout-test-results/fast/dom/Window/window-constructor-expected.txt
+++
/b/s/w/ioajsmeisv/layout-test-results/fast/dom/Window/window-constructor-actual.txt
@@ -0,0 +1,5 @@
+This is a testharness.js-based test.
+[FAIL] Test Window and its prototype chain's constructors.
+  assert_equals: WindowProperties constructor is EventTarget. expected
function "function EventTarget() { [native code] }" but got function
"function WindowProperties() { [native code] }"
+Harness: the test ran to completion.
+

Though *why* it's failing, I don't know off hand and will need to dig into
it. It does seem worth fixing that.

Daniel

On Mon, 15 Jul 2024 at 23:29, Leszek Swirski  wrote:

> I'm not saying that it's subtle and hard to get right, any more so than
> any other code we ship at least, I'm saying that it's a full separate code
> path and behaviour that we would be shipping to users without running
> locally. The difficulties I'm having on android are because of build
> config/dependency issues.
>
> For "how much performance", I'm currently trying to enable it on Android
> because it would improve Search page load by what they estimate to be ~24
> SWE-years worth of improvement (Kentaro has a calculation in this doc
> ).
> Also +Kouhei Ueno  who has been looking into the
> impact of context setup on page load, and +Camillo Bruni
>  who looked at the performance with Scott.
>
> On Tue, 16 Jul 2024, 02:43 Nico Weber,  wrote:
>
>> If the code path behind use_v8_context_snapshot is subtle and hard to get
>> right, it sounds like there's our second reason for not having it, right
>> there :)
>>
>> How much performance does the blink snapshot buy us? Is it possible to
>> get some of that with less expensive techniques?
>>
>> (+sky who I think looked at this at some point.)
>>
>> On Monday, July 15, 2024 at 2:54:35 PM UTC-4 Leszek Swirski wrote:
>>
>>> +Michael Lippautz 
>>>
>>> I'm not sure we should do this for build time reasons alone.
>>> `use_v8_context_snapshot` is the default behaviour in shipping browsers,
>>> and it makes the renderer take quite a different path during page load /
>>> navigation. If we disable it in regular builds, then regular builds
>>> (including all the dchecks!) won't be running and texting the same code
>>> that we're shipping.
>>>
>>> The fact that tests are failing with this flag change should be a huge
>>> flashing red light about this proposal - if we make the tests not test the
>>> code we're shipping, then we risk it breaking without us noticing. Indeed,
>>> I've been trying to turn this flag on for Android, and have been struggling
>>> to do so.
>>>
>>> - Leszek
>>>
>>>
>>> On Mon, 15 Jul 2024, 20:25 Dave Tapuska,  wrote:
>>>
 Have you thought about setting gn config v8_use_external_startup_data
 on any bots?

 I don't know why they are failing. The window constructor one is weird
 as well because the prototype chain is different...

 dave.

 On Mon, Jul 15, 2024 at 2:13 PM Nico Weber  wrote:

> Hello,
>
> use_v8_context_snapshot causes us to build lots of files (blink +
> dependencies) twice on bots that cross-compiler (win/arm64, android, etc).
>
> We'd like to turn off use_v8_context_snapshot in regular release
> builds by default, and only keep it enabled in is_official_build builds.
>
> However, a small number of tests, almost all of
> them inspector-protocol tests, fail if I try this:
> https://chromium-review.googlesource.com/c/chromium/src/+/5704136
>
> That's surprising to me. I would've expected use_v8_context_snapshot
> to not change behavior.
>
> Does anyone have an idea why this might happen?
>
> Thanks,
> Nico
>
> --
> 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/CADZ1XibPV%3Dd448fckQeYFaO617_9aahsxysAjMEdQ4sy%3DQw4kQ%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/CAHgVhZU-er_dfh_esgBmfLQ%2BOVf24y2yN7K6W6yjGqNkH%3Df%3D6w%40mail.gmail.com
 

Re: [blink-dev] Merging a UseCounter addition

['Daniel Cheng' via blink-dev]

I think what you've done is fine; that being said, I probably would have
just cherry-picked the specific use counter the diff uses, but I don't
think it really makes a difference either way.

Daniel

On Thu, 5 Oct 2023 at 13:25, Donn Denman  wrote:

> Can someone review a merge of new UseCounters in
> https://crrev.com/c/4915881?
>
> I'm merging a CL that adds UseCounters, but my counters are not the next
> sequential values due to other additions that are not being merged. I'm
> thinking it's OK to add those values
> to third_party/blink/public/mojom/use_counter/metrics/web_feature.mojom and
> the associated enums.xml even though they won't be used.
>
> LMK if there's a better list to ask this question on.
>
> --
> 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/CALCERB7%3DDLjqye-_u0g6X4k658f%3D6EHxcWJDTwL_djfFWR_fWQ%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/CAF3XrKr3JG0G6anib-YvF0dYhWiVRzO0feT842r3r78BxOodag%40mail.gmail.com.

Re: [blink-dev] Debugging compressed pointers in Blink

[Daniel Cheng]

For now, I guess it should be sufficient to add something
to v8/include/cppgc/internal/member-storage.h like

#ifndef NDEBUG  // DCHECK_IS_ON() would be nicer, but not sure what v8 uses
extern "C" void* DecompressPointerForDebugger(uint32_t value) {
  return cppgc::internal::CompressedPointer::Decompress(value);
}
#endif

Which should hopefully be callable from the debugger and not eliminated by
the linker?

Daniel

On Mon, 10 Oct 2022 at 11:32, Stefan Zager  wrote:

> I ran into this today, and it's pretty frustrating:
>
> (rr) p inner_node_
>
> $11 = {
>
>= {
>
> raw_ = {
>
>   static kCompressedSentinel = 1,
>
>   value_ = 2148082696 <(214)%20808-2696>
>
> }
>
>   },
>
>= {},  fields>}
> (rr) p inner_node_.Load()
>
> Couldn't find method blink::Member::Load
>
> (rr) p inner_node_.raw_.Load()
>
> Cannot evaluate function -- may be inlined
>
> (rr) p
> cppgc::internal::CompressedPointer::Decompress(inner_node_.raw_.value_)
>
> Cannot evaluate function -- may be inlined
>
> (rr)
>
> I found that I can avoid the issue with this in args.gn:
>
> cppgc_enable_caged_heap = false
> cppgc_enable_pointer_compression = false
>
> ... but I would prefer a better solution.
>
> On Mon, Oct 10, 2022 at 10:22 AM Ian Kilpatrick 
> wrote:
>
>> Is there a bug to follow regarding the debuggability of the pointers?
>>
>> Ian
>>
>> On Thu, Sep 22, 2022 at 11:10 AM Anton Bikineev 
>> wrote:
>>
>>> There is "cppgc::internal::CompressedPointer::Decompress(void*)". I
>>> would, however, hide it behind a simpler name in .gdbinit.
>>>
>>> On Thu, Sep 22, 2022 at 5:51 PM Daniel Cheng 
>>> wrote:
>>>
>>>> Is there a callable C++ function that can turn a compressed pointer
>>>> into the actual pointer value?
>>>>
>>>> Daniel
>>>>
>>>> On Thu, 22 Sept 2022 at 08:43, Anton Bikineev 
>>>> wrote:
>>>>
>>>>> We have plans to provide more debugging tooling for Oilpan. I haven't
>>>>> had a need to examine compressed pointers myself, however I see that some
>>>>> simple gdb/windbg function that'd follow pointers would be useful.
>>>>>
>>>>> On Thu, Sep 22, 2022 at 1:14 AM Kentaro Hara 
>>>>> wrote:
>>>>>
>>>>>> +Michael Lippautz 
>>>>>>
>>>>>> 2022年9月22日(木) 4:01 'Daniel Libby' via blink-dev <
>>>>>> blink-dev@chromium.org>:
>>>>>>
>>>>>>> https://crrev.com/c/3835682 enabled pointer compression for Blink
>>>>>>> Member<> pointers. How are folks handling these while debugging (either
>>>>>>> live or crash dumps)? Is there some tooling available that will look up 
>>>>>>> and
>>>>>>> apply the cage base?
>>>>>>>
>>>>>>> I didn't see anything mentioned in
>>>>>>> https://docs.google.com/document/d/1neGN8Jq-1JLrWK3cvwRIfrSjLgE0Srjv-uq7Ze38Iao/edit#
>>>>>>> but maybe there are better known tools/techniques from v8 (which IIUC 
>>>>>>> has
>>>>>>> had compressed pointers for some time now).
>>>>>>>
>>>>>>> --
>>>>>>> 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/4b3e5bbb-134a-4483-9a1e-8e33fbc6f38en%40chromium.org
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b3e5bbb-134a-4483-9a1e-8e33fbc6f38en%40chromium.org?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>> --
>>>>>> 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/bl

Re: [blink-dev] Debugging compressed pointers in Blink

[Daniel Cheng]

Is there a callable C++ function that can turn a compressed pointer into
the actual pointer value?

Daniel

On Thu, 22 Sept 2022 at 08:43, Anton Bikineev  wrote:

> We have plans to provide more debugging tooling for Oilpan. I haven't had
> a need to examine compressed pointers myself, however I see that some
> simple gdb/windbg function that'd follow pointers would be useful.
>
> On Thu, Sep 22, 2022 at 1:14 AM Kentaro Hara  wrote:
>
>> +Michael Lippautz 
>>
>> 2022年9月22日(木) 4:01 'Daniel Libby' via blink-dev :
>>
>>> https://crrev.com/c/3835682 enabled pointer compression for Blink
>>> Member<> pointers. How are folks handling these while debugging (either
>>> live or crash dumps)? Is there some tooling available that will look up and
>>> apply the cage base?
>>>
>>> I didn't see anything mentioned in
>>> https://docs.google.com/document/d/1neGN8Jq-1JLrWK3cvwRIfrSjLgE0Srjv-uq7Ze38Iao/edit#
>>> but maybe there are better known tools/techniques from v8 (which IIUC has
>>> had compressed pointers for some time now).
>>>
>>> --
>>> 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/4b3e5bbb-134a-4483-9a1e-8e33fbc6f38en%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/CABg10jxSdx3JzWvTC2j7RUEcw01P9gTRhT%3DnftwehY3br4qNWA%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/CABH6udYH6VGy8Ooz6ZLZWpWR_LjjQfu1xh-AMBvWoyAnArojbA%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/CAF3XrKoBjKzgkpo%2BJf2HVEnPBZpV9Z%2BpXNaB_5yT9tYYo8JYjA%40mail.gmail.com.

Re: [blink-dev] How to check if a document is fully active in Blink?

[Daniel Cheng]

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.

Re: [blink-dev] HTTP return code of iframe?

[Daniel Cheng]

Hm, I wasn't careful enough when I checked the spec yesterday, I guess. I
notice that  seems to fire an error event on HTTP error
<https://html.spec.whatwg.org/multipage/iframe-embed-object.html#:~:text=If%20the%20load%20failed%20(e.g.%20there%20was%20an%20HTTP%20404%20error%2C%20there%20was%20a%20DNS%20error)%2C%20fire%20an%20event%20named%20error%20at%20the%20element%2C%20then%20jump%20to%20the%20step%20below%20labeled%20fallback.>.
Is that not leaky in the same way?

Daniel

On Wed, 17 Nov 2021 at 12:16, K. Moon  wrote:

> There's no generic way to do this, as it would leak information. I don't
> think this route is worth exploring.
>
> On Wed, Nov 17, 2021, 11:44 AM Tibor Goldschwendt 
> wrote:
>
>> We explored postMessages for a bit, too. IIUC, this would only solve the
>> success case properly though. But how do we know the iframe is broken? Not
>> receiving the postMessage could also mean the iframe hasn't completed
>> loading yet.
>>
>> On Wed, Nov 17, 2021 at 11:34 AM Domenic Denicola 
>> wrote:
>>
>>> The "error" event does not fire on iframes though, precisely because we
>>> don't want to leak information cross-origin.
>>>
>>> Pages generally deal with broken iframes, in cases where they need to,
>>> by noticing that the iframe has not sent them the message they expect. (Via
>>> parent.postMessage() from inside the iframe.) That is, they use an opt-in
>>> protocol where the iframed page must affirmatively decide what information
>>> to send cross-origin.
>>>
>>> On Wed, Nov 17, 2021 at 2:24 PM Daniel Cheng 
>>> wrote:
>>>
>>>> The iframe element supports "load" and "error event listeners. Is the
>>>> exact HTTP error needed? Or does the feature just need to know if it
>>>> succeed or not?
>>>>
>>>> Daniel
>>>>
>>>> On Wed, 17 Nov 2021 at 11:19, Tibor Goldschwendt 
>>>> wrote:
>>>>
>>>>> +Nasko Oskov 
>>>>>
>>>>> Thanks, Kahmy. Adding custom code in the browser process is another
>>>>> avenue I'm exploring. Generally though, how do pages deal with broken
>>>>> iframes?
>>>>>
>>>>> On Wed, Nov 17, 2021 at 6:39 AM K. Moon  wrote:
>>>>>
>>>>>> This would violate the same-origin policy, so I don't think you can
>>>>>> do this within Blink, but given this is a chrome: page, maybe you could 
>>>>>> add
>>>>>> some code in the browser to give this information to you.
>>>>>>
>>>>>> On Tue, Nov 16, 2021, 4:40 PM Tibor Goldschwendt 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Blink Dev!
>>>>>>>
>>>>>>> Is there any way to get the HTTP return code of a cross-domain
>>>>>>> iframe? FWIW, the hosting page has the chrome:// scheme while the iframe
>>>>>>> has https:// scheme. From my limited testing I receive the load
>>>>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Window/load_event> 
>>>>>>> event
>>>>>>> in all scenarios but couldn't find a way to query whether the load
>>>>>>> succeeded. I also tried window.addEventListener('error', ...) and
>>>>>>> iframe.addEventListener('error', ...) without any luck.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Tibor
>>>>>>>
>>>>>>> --
>>>>>>> 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/CAFgr3n%2B8i%2BNQNSJY0DFab9JrXG0QTq3W473t-beRtPYbLn1XjA%40mail.gmail.com
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFgr3n%2B8i%2BNQNSJY0DFab9JrXG0QTq3W473t-beRtPYbLn1XjA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "blink-dev" group.
>>&g

Re: [blink-dev] HTTP return code of iframe?

[Daniel Cheng]

The iframe element supports "load" and "error event listeners. Is the exact
HTTP error needed? Or does the feature just need to know if it succeed or
not?

Daniel

On Wed, 17 Nov 2021 at 11:19, Tibor Goldschwendt 
wrote:

> +Nasko Oskov 
>
> Thanks, Kahmy. Adding custom code in the browser process is another avenue
> I'm exploring. Generally though, how do pages deal with broken iframes?
>
> On Wed, Nov 17, 2021 at 6:39 AM K. Moon  wrote:
>
>> This would violate the same-origin policy, so I don't think you can do
>> this within Blink, but given this is a chrome: page, maybe you could add
>> some code in the browser to give this information to you.
>>
>> On Tue, Nov 16, 2021, 4:40 PM Tibor Goldschwendt 
>> wrote:
>>
>>> Hi Blink Dev!
>>>
>>> Is there any way to get the HTTP return code of a cross-domain iframe?
>>> FWIW, the hosting page has the chrome:// scheme while the iframe has
>>> https:// scheme. From my limited testing I receive the load
>>>  event
>>> in all scenarios but couldn't find a way to query whether the load
>>> succeeded. I also tried window.addEventListener('error', ...) and
>>> iframe.addEventListener('error', ...) without any luck.
>>>
>>> Best regards,
>>> Tibor
>>>
>>> --
>>> 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/CAFgr3n%2B8i%2BNQNSJY0DFab9JrXG0QTq3W473t-beRtPYbLn1XjA%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/CAFgr3nL-J4A0bQuXnU1Ns-eUYLNqVV65KZLeY3HuiPuBYQQmiQ%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/CAF3XrKpDqd9ixPDOFiOu7NjMpmMm62nD0JxzBxyHfLmTJhr0PA%40mail.gmail.com.