QA and collaborate on branch deploys using the Netlify Drawer

Developers can now collaborate with stakeholders using the Netlify Drawer on branch deploys!

The Netlify Drawer has long enabled teams to discuss changes, make suggestions, and file issues from the context of Deploy Previews; activity is synced back to your Git provider and other task management services you depend on. Deploy Preview environments are automatically generated for pull requests on your Git repository at unique URLs for each PR.

If you need to work with your QA team or other stakeholders on a more stable preview URL though, the Netlify Drawer is now available on branch deploys as well!

As always, Reviewers are free to add to your team: those who don’t need full access to Netlify can review your work from the Netlify Drawer without added cost.

Learn more on the blog post, and let us know if you have any feedback! We’re always happy to hear what you think.

Update on January 23, 2023: previously, the Netlify Drawer was enabled by default on branch deploys that do not use custom domains. Based on customer feedback, it is now disabled by default. To enable the Netlify Drawer on branch deploys, go to Site Settings > Build & deploy > Collaboration tools. Thank you for sharing your thoughts!

2 Likes

Hi, we encountered a problem that our production site (mobile app) shows the Netlify Drawer. It took a bit of time to figure out that the problem seems to be the result of this change.
We use netlify sites inside our mobile apps, and as we want to use versioning, we use branch deploys as production sites. So, the Netlify Drawer appeared on these sites.

Then I found this news and changed the “Collaboration tools” setting and it has “sort of” fixed.

But I think it is better that the Netlify Drawer setting for branch deploys to be disabled for existing sites. So that it does not require developers to solve the problem.

Also I noticed that the Netlify Drawer appears for a bit of time (like 0.2sec) for sites that have the setting disabled. This is also annoying and I hope you to fix soon.

1 Like

Hi @mhama, thank you for the feedback!

For existing sites, the Netlify Drawer should be disabled on branch deploys if the site uses the “Branch subdomains” feature. We were hoping to avoid this case where the Drawer is shown on branch deploys used like production environments (i.e. those that use custom branch subdomains). Would you mind confirming for me if your team was using that feature on the site in question?

Also I noticed that the Netlify Drawer appears for a bit of time (like 0.2sec) for sites that have the setting disabled. This is also annoying and I hope you to fix soon.

Can you tell me more about this issue? Does this happen every time you visit the site, or just the first time after modifying the setting? Is this on branch deploys?

Thank you for any additional info, that will help us address any bugs you might be hitting!

We’re also getting the drawer showing up briefly as well. You can see it if you run a pagespeed test on a deploy branch that has the drawer disabled.

That being said, it’s murdering our pagespeed score which makes testing optimizations impossible.

If the deploy preview is disabled, the code should not be injected at all.

1 Like

You can see all the resources loading and processing in the network tab. Seems like the only thing “disable” does is forbid loading one of the scripts. Not only is this causing hitching and jank during load, it’s also probably resulting in thousands of unnecessary HTTP requests on Netlify servers.

1 Like

Thanks Neil! We’re actively investigating this right now.

1 Like

Hi there @mhama and @cosmicneil – thank you both for using the forums to report these bugs. I apologize that these errors have negatively impacted your sites. Here’s an update on the progress we’ve made so far on alleviating these issues:

@mhama, does your production site have an active split test? There is an issue we discovered where the drawer may show up for traffic sent to a branch in a split test. Today, we pushed a change to mitigate this issue, so your production traffic should no longer see the drawer, and the drawer should not mount at all on production URLs, so any performance testing should remain unaffected. On branch deploys themselves, we’ve also pushed a change to remedy the “appears for a bit of time (like 0.2sec)” problem that you mentioned. The drawer is intended to be seen only by your Netlify teammates. I’m very sorry for the inconvenience this caused you and your users!

@cosmicneil, you are absolutely right in that the drawer assets should not download when the setting is disabled. There is a bug that we’re investigating where the drawer snippet is getting injected into the HTML, regardless of the enabled/disabled setting. It is intended for the drawer assets to not be downloaded at all when the setting is disabled. I am hoping we can find and fix this problem this week. In the meantime, if you’d like, you can use a strict Content Security Policy to block the drawer script, which should alleviate the hitching and jank you described. In your _headers file, adding something like the following:

/*
  Content-Security-Policy: script-src 'self' 'unsafe-inline' *.example.com;

would only allow scripts loaded from relative paths, inline script tags, and from any subdomain of example.com.

Thank you for your patience, and we will report back on this thread once the issues have been 100% fixed.

4 Likes

HI, Thanks for the reply.

Would you mind confirming for me if your team was using that feature on the site in question?

It looks like, we don’t have any branch subdomains settings. So we currently uses automatic subdomain. aka {brancname}.{domain}

Can you tell me more about this issue? Does this happen every time you visit the site, or just the first time after modifying the setting? Is this on branch deploys?

The Drawer was shown every time last night, but I checked now and it does not appear from the start. It looks like the problem has been solved !

No, but as we didn’t have branch subdomains and just using {branchname}.{domain} so Netlify may not think these as production site.

we’ve also pushed a change to remedy the “appears for a bit of time (like 0.2sec)” problem that you mentioned.

We confirmed that it was solved now! Thank you!

Our main branch deploy is our main development target, and we have a delayed release cycle into production. So, this change has affected all our performance monitoring baselines. We have Drawer disabled in all contexts according to the UI, and still see the injected JS in our main branch deploy, the target of a bunch of performance monitoring (using no custom domain, like main–app.netlify.app).

So, this unexpectedly injected new asset is blocking the largest-content-paint timings of our pages enough to trigger all the performance tests in our CI to fail. It’s cost me a bit of debugging time so far, to make sure I wasn’t seeing a bad test, and our page performance did majorly change even though nothing in our bundle did.

And, even after identifying this and reaching for every available opt out, Netlify will still be injecting this new library by rewriting the page, and the expected workaround is to block it with CSP? Ouch: that means more work for me to get our performance baselines back (than just being able to “Turn It Off™”). I also suspect the CSP-blocking approach will lead to lots of false-positives in CSP-violation-reporting because, for many sites, it’s not a normal condition to have any blocked resources (although we’re not doing that right now).

I guess adding subdomains so that these branch deploys we’re using are considered closer to production-like would be the workaround for me to pursue?

1 Like

Thanks for reporting this so early!

My performance test are all down at the moment due to the script injection. Turning the nob removed the div but injection is still happening, it is adding like 20 network requests, increases (compressed) load size by 300Kbs and delaying time to interactive by 200ms.

A little surprised that this feature got turned on by default, and also (if I get it right) - retrospectively on old builds as well.

1 Like

Hey all, thanks again for your patience. We’ve fixed the issue of drawer assets downloading even when the site setting for the drawer was disabled. If you’re still seeing drawer assets downloading in your console, try toggling the setting again to kick the CDN cache. Please let us know if this isn’t working for you.

A fix for the drawer’s snippet being injected when a site has an active split test has been identified. We rolled out a change on Wednesday so that the snippet would remove itself in this case as a mitigation, but a fix to prevent it from writing to HTML is still planned and should be rolled out shortly.

Furthermore, we’re planning to change the default to be opt-in for the drawer on branch deploys.

Thank you again for writing in, your feedback truly makes Netlify better!

4 Likes

Hi everyone, thanks so much again for all your feedback on the new functionality for branch deploys and the Netlify Drawer! Getting your input really does help us provide a better experience.

We have a batch of updates for your start of the week:

  1. Netlify Drawer assets being loaded when disabled on branch deploys: as Jason mentioned, this issue should be fixed as of end of last week.
  2. Drawer injection in production during split tests: this has also been addressed. Note that with this fix, the Netlify Drawer will not load on branch deploys either when a split test is active.
  3. Default setting for Netlify Drawer on branch deploys: the Netlify Drawer is now disabled by default for all sites, including those that don’t use custom domains on branch deploy contexts (previously was on by default for these). Due to limitations on how we could roll out this update, developers who do want the drawer on branch deploys will need to re-enable that in Site Settings now.

We apologize for any stress or inconvenience caused by the above, and are grateful to everyone who took the time to share your feedback with the team! Thank you!

3 Likes

You guys iterate fast, thank you! :heart:

1 Like