-
Notifications
You must be signed in to change notification settings - Fork 313
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
Ensure WebExtensions finish startup task before allowing the platform to submit the first request #224
Comments
Possibly related: gbaptista/luminous#55 and EFForg/privacybadger#1865. |
There may be two separate kinds of issues here:
|
@ghostwords thanks for pointing that out. I updated the title and filed #242 to make it clear there are two potential issues. |
It's now possible to block requests on startup until webextensions are ready. See mozilla/contain-facebook#206 and mdn/sprints#1015 for a description. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Alright, I looked at the code landed in bug 1447551 and it's promising. It indeed allows us to write a blocking WebRequest listener that stalls page loads till the instrumentation is ready. I'm going to try and write a patch for this today. |
@nhnt11 Have you made any progress with this patch? Or otherwise, would you mind if I pick it up? |
@jallmann ugh, I didn't see this. Please feel free to pick it up and let me know if I can help. |
@englehardt Can we close this? |
@nhnt11 If I remember correctly from a few weeks back you mentioned that you had tested this manually by adding in a big delay into startup and didn't see any missed requests? Is that right? |
Yes. Specifically, we verified that the extension content script is guaranteed to run before page scripts. I'm not sure if this issue includes the idea of making the extension send an ack to the platform before the platform starts issuing requests. Edit: Ah, that was #242! My bad, sorry. |
I think what we verified was that we can indeed use the blocking WebRequest listener to achieve this but I can't remember if we landed it. It doesn't seem like it. |
The second part of the issue (the ack to the plattform) is being tracked in #135 and the first part was successfully implemented so I'm closing this |
In #221 we started the move over to WebExtensions. Unfortunately, WebExtensions do not block the first page load on extensions startup, meaning that page content may load before the extension injects instrumentation. See Bug 1378459. We've thus had to account for this in our tests, see: 643e457.
This is a problem for us since most of our crawls are stateless and will experience some delay on every load, meaning we'll miss a small amount of data at the start of each page.
Let's see if we can block on startup within the browser manager until the extension has fully loaded.
The text was updated successfully, but these errors were encountered: