chore(adblock): setup priority #321
Conversation
|
Hmm strange this is strange
Based on the priority configuration, Maybe it is just a logging issue since logging order is not guaranteed? browserless/packages/goto/src/index.js Line 25 in 4524583 |
| const resourceType = req.resourceType() | ||
| if (!abortTypes.includes(resourceType)) { | ||
| debug('continue', { url: req.url(), resourceType }) | ||
| return req.continue(req.continueRequestOverrides(), 2) |
There was a problem hiding this comment.
Sorry if I am meddling where I don't belong 😅 This .continue({}, 2) will cause the request to continue even if adBlocker calls .abort('..',1). I think your intent might be to defer to other handlers by using .continue({}, 0) if abortTypes has no opinion about it?
There was a problem hiding this comment.
yes, that was the intention; should I call isInterceptResolutionHandled to be sure about that?
There was a problem hiding this comment.
When #7796 is approved (I hope soon), that method will be available and should definitely be used.
Also see the PR for a discussion on when to use a custom priority to continue a request.
Again sorry to jump in, I just found this issue and thought it was interesting because I’m learning a lot by how people are implementing support for cooperative mode.
There was a problem hiding this comment.
no problem 🙂 I did my best implementing the API and since there is not too examples out there probably the code can be rewritten in a better way
There was a problem hiding this comment.
If you decide to change anything, I suggest using .continue({...},0) for this case :)
|
puppeteer/puppeteer#7796 has been accepted by the Puppeteer team 👍 |
According to Puppeteer API docs:
so:
abortTypestakes2priority (highest priority).adblocktakes priority1.0priority by default, not collisioning with the library priorities.Related: