-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#6649: Avoid background messaging to handle AJAX page updates #7030
Conversation
Why low priority? This is an mv3 issue. Without this, page updates can take seconds after the worker deactivation |
@@ -51,12 +51,6 @@ async function onNavigation({ tabId, frameId }: Target): Promise<void> { | |||
if (syncFlagOn("navigation-trace")) { | |||
await traceNavigation({ tabId, frameId }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not removed the listeners due to this logging.
What would you like to do?
- Leave as is
- Drop logging
- Attach/remove the listeners depending on the flag (via
addAuthListener
), instead of checking the flag at every navigation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attach/remove the listeners depending on the flag (via addAuthListener), instead of checking the flag at every navigation
Lets do this. Unfortunately navigation tracing code is still helpful to understand wacky SPA navigation behavior of some in-house applications
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in #7178
@@ -51,12 +51,6 @@ async function onNavigation({ tabId, frameId }: Target): Promise<void> { | |||
if (syncFlagOn("navigation-trace")) { | |||
await traceNavigation({ tabId, frameId }); | |||
} | |||
|
|||
if (await canAccessTab({ tabId, frameId })) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that messaging + this check added at least 100ms to the navigation event.
Thanks for noting the MV3, I was not aware of that context. Will take a look at the PR today |
It seems that the API matches our expectations, and that our previous HANDLE_NAVIGATE doesn't take long, assuming that the background is alive and not busy: Screen.Recording.2.movThe only adjustment needed, so far, is that the Here's what I used to compare the API:
|
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #7030 +/- ##
==========================================
- Coverage 71.15% 71.11% -0.05%
==========================================
Files 1213 1209 -4
Lines 37621 37519 -102
Branches 7074 7075 +1
==========================================
- Hits 26768 26680 -88
+ Misses 10853 10839 -14 ☔ View full report in Codecov by Sentry. |
I made a testing page to see how this new event behaves: https://pbx.vercel.app/navigation/ I confirmed that it catches the events we're looking for:
There's one situation that it doesn't catch:
And also it triggers on unnecessary events:
I think PB can handle additional requests fine though, so this shouldn't be a blocker. |
👍 That's OK. I think the user would want to address this with a focus listener/tigger (or introduce an "tab activated trigger"? It's sort of the same use case as flipping to another tab and then going back to the original tab. I don't think we should treat as navigation
Can we filter those out? Looks like navigation away is handled here?: https://github.com/pixiebrix/pixiebrix-extension/pull/7030/files#diff-83e126c90c800dfc9992a0a6213d9f60b6afb4e8d68797228550cdf5535cb25bR642 |
@@ -66,6 +66,7 @@ export async function init(): Promise<void> { | |||
initToaster(); | |||
|
|||
await handleNavigate(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we comment on the ordering here? I.e., why is initNavigation after handleNavigate. I think the answer is just: "handle initial load, then watch for additional navigation events"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in #7178
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments on your questions
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 see comments on your questions. Also, can you double-check this works for frame navigation?
I looked at the logs and couldn't find a way. I thought I could use the
Actually I don’t think that's doing any good right now, but it looks like I can use that in combination with The result of window.onbeforeunload = () => console.log('unload');
window.navigation.addEventListener('navigate', () => {
console.log('navigate')
setTimeout(console.log, 0, 'delayed navigate')
}) is
I'll work on this a bit more |
Each document deals with this independently, so it should keep working. The |
If the page is going to unload anyway, it might be fine to leave it? The page would navigate before the bricks run/our bricks running wouldn't block the navigation We can probably get this merged in and do any tweaks in follow up if necessary |
Sure. I was working on it today but I suppose I'll open a separate PR. I think I found a solution that correctly avoids the event on unload.
True but maybe we will receive errors, for example if a message is initiated but the page is unloaded immediately after. Or even visible breaking and "noisy" actions on "page load" triggers could be shown to the user for a moment. |
Not yet ready for review, but it's a very small change.
What does this PR do?
Discussion
This reduces the time it takes between navigation and reaction, making it almost
sync
by comparison. I need to:Checklist
src/tsconfig.strictNullChecks.json
(if possible)