-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
fix(browser): Try multiple options for lazyLoadIntegration
script parent element lookup
#13717
Conversation
…arent element lookup
if (parent) { | ||
parent.appendChild(script); | ||
} else { | ||
logger.error(`Could not find parent element to insert lazy-loaded ${name} script`); |
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 opted to only log an error and not throw here because this likely is an edge case behavior which our users wouldn't test against. So I'd rather let lazyLoadIntegration
never resolve/reject than throwing/rejecting a promise in an effort to "fail silently". Happy to change if reviewers have different opinions.
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 think I'd rather not do that, because users code may then pend forever, which is probably harder to debug than an error in this case? 🤔 But no strong feelings...
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 guess it comes down to how SDK consumers use the API. If they don't use it in a blocking way (i.e. let other program code depend on the integration being loaded), we should be good. But sure, they can also just await
it and have important logic come afterwards... I'll revert to throwing an error.
size-limit report 📦
|
lazyLoagIntegration
script parent element lookuplazyLoadIntegration
script parent element lookup
@@ -68,7 +69,14 @@ export async function lazyLoadIntegration( | |||
script.addEventListener('error', reject); | |||
}); | |||
|
|||
WINDOW.document.body.appendChild(script); | |||
const currentScript = WINDOW.document.currentScript; | |||
const parent = (currentScript && currentScript.parentElement) || WINDOW.document.body || WINDOW.document.head; |
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.
l: Not 100% sure, but I think I would flip this around and do the currentScript stuff at the end rather then the beginning? so body || head || currentScript
? 🤔 Not sure though and probably does not matter, maybe it's just because I don't really know/knew currentScript so I feel less comfortable around it 😅
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.
sure, no strong opinions either. Will turn it around :)
This PR makes our
lazyLoadIntegration
a bit more robust when trying to find the parent element to inject the script tag of the integration CDN bundle. It looks like some browsers don't automatically setdocument.body
if the html page doesn't contain a<body>
tag. Unfortunately, I couldn't reproduce this with Chrome, FF or Safari, so my running theory is that this is rather an exotic browser.Anyway, for now the order of looking up parent elements is:
document.body
document.head
document.currentScript.parentElement
Unfortunately, I couldn't find a way to test these branches since neither chromium (integration tests) nor JSDOM (unit tests) allow unsetting
document.body|head
. I think we should be fine with leaving this specific change untested but I can also spend some more time to try and figure out some way to test this...closes #13707