| Auto-Submit | +1 |
| Commit-Queue | +1 |
The test works but I tried adding this code to induce a crash in the renderer:
--- a/third_party/blink/renderer/modules/content_extraction/ai_page_content_agent.cc
+++ b/third_party/blink/renderer/modules/content_extraction/ai_page_content_agent.cc
@@ -983,6 +983,9 @@ void AIPageContentAgent::GetAIPageContent(
GetAIPageContentCallback callback) {
base::TimeTicks start_time = base::TimeTicks::Now();
+ bool* bad = nullptr;
+ CHECK(bad);
+
LocalFrameView* view = GetSupplementable()->View();
And that doesn't result in the callback being invoked via WrapCallbackWithDefaultInvokeIfNotRun...
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
GetAIPageContent(I think this will race with the signal sent by `child_process->Shutdown(0)` and sometimes the `GetAIPageContents` call will succeed. You may need to wait for the mojo disconnection or simulate it to get deterministic behavior.
Not sure, depends on the details of the `GetAIPageContents` implementation.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
GetAIPageContent(I think this will race with the signal sent by `child_process->Shutdown(0)` and sometimes the `GetAIPageContents` call will succeed. You may need to wait for the mojo disconnection or simulate it to get deterministic behavior.
Not sure, depends on the details of the `GetAIPageContents` implementation.
I think this will race with the signal sent by `child_process->Shutdown(0)` and sometimes the `GetAIPageContents` call will succeed. You may need to wait for the mojo disconnection or simulate it to get deterministic behavior.
Not sure, depends on the details of the `GetAIPageContents` implementation.
GetAIPageContents is sending an IPC to each renderer. I figured sending the shutdown IPC above *before* the IPCs issued by GetAIPageContent will ensure the disconnection happens first. But I realize now that since these are using mojo interfaces which aren't associated, ordering is not guaranteed.
Hmmm, this is hard to do in a browsertest environment. Will think about this more...
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
It's interesting that the test is only flaky on Linux/Android - the pipe destruction timing likely depends on OS specifics
GetAIPageContent(Khushal SagarI think this will race with the signal sent by `child_process->Shutdown(0)` and sometimes the `GetAIPageContents` call will succeed. You may need to wait for the mojo disconnection or simulate it to get deterministic behavior.
Not sure, depends on the details of the `GetAIPageContents` implementation.
I think this will race with the signal sent by `child_process->Shutdown(0)` and sometimes the `GetAIPageContents` call will succeed. You may need to wait for the mojo disconnection or simulate it to get deterministic behavior.
Not sure, depends on the details of the `GetAIPageContents` implementation.
GetAIPageContents is sending an IPC to each renderer. I figured sending the shutdown IPC above *before* the IPCs issued by GetAIPageContent will ensure the disconnection happens first. But I realize now that since these are using mojo interfaces which aren't associated, ordering is not guaranteed.
Hmmm, this is hard to do in a browsertest environment. Will think about this more...
Are you specifically testing process crash behavior or just behavior on mojo disconnect? If the latter then you could plumb in a test API to disconnect the specific pipe for `GetAIPageContent`.
The assumption would be that renderer crash would always trigger a mojo pipe disconnect and the callback, but that seems like a safe assumption.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |