Skip to main content
  1. Blog
  2. Article

Anthony Dillon
on 19 February 2021

Supporting “I don’t care about cookies”


It all started one day when my boss turned to me and said, the legal team have said we need to ask a person before our websites can start using non-essential cookies. So we started the cookie-policy project which is written in vanilla JavaScript with accompanying styling and the back-end implemented via Google Tag Manager.

The cookie-policy project displays a modal to each first-time visitor to manage which cookies they would like to accept. We have rolled out successfully across over 30 of our sites.

Recently we received an issue that there was no way to scroll on our site if you were using a popular browser extension named I don’t care about cookies. The cookie policy script added a class to the body of the site to lock scrolling as it was expecting the cookie management modal to be present. The plugin has a range of selectors targeting known cookie notification elements and hides the cookie modal making it impossible for users to remove the scroll lock. 

How to support the extension

Here is a subset of the CSS injected into the site by the plugin. As you can see .cookie-policy is targeted and happens to be the container class used by our cookie-policy.

#stickyCookieBar, 
.cookiebar-bar:not(body):not(html), 
#sliding-popup, 
#cookie_bar_top, 
#cookielaw:not(.modal),
[ … ]
.cookie-policy:not(body):not(html),
[ … ]
#cookiebnr, 
#cookieWarning, {
    display: none !important;
    ...
}

There are a few body classes but they have been kept to a minimum for good reason.

This isn’t what we want to happen and we believe it’s important to respect the wishes of our users so we want to support this extension. Therefore we removed the scroll lock after the cookie management modal appeared as there was no way to identify if the modal was being hidden via this extension.

So if you have written a cookie policy widget for your site or application try and support the extension by using one of the supported selectors and also try and keep it self contained within that element to limit issues such as we expereinced.

Related posts


Kola Ojoodide
26 June 2026

Challenges designers face in open source (and how to fix them)

Design open source

Open source powers up to 90% of modern software, yet many projects lack usability. Canonical’s Design team surveyed 115 cross-functional professionals to uncover the 4 core challenges UI/UX designers face when contributing, and how maintainers can solve them. ...


Nina Rojc
16 June 2026

Template: Streamlining open source design contributions

Design Ubuntu tech blog

As designers working at Canonical, we’re always thinking about open source. We believe that encouraging more designers to contribute to open source  benefits everyone, from the project maintainers to the end users themselves.   In the 2025 edition of FOSSBackstage conference, we presented our research findings on  why designers don’t get ...


Miguel Divo
22 May 2026

Decoding design: How design and engineering thrive together in open source

Design Ubuntu tech blog

Open source thrives on engineering-driven processes. Fast feedback loops, terminal tools, Git workflows: they’re the lifeblood of how we build software in the open. But for software to truly excel, we need to create user experiences that empower people to use them. I wanted to bring this conversation into the spotlight as part of Canonica ...