Use shadow dom to render the toolbar

[federicobond]

Description

Following the discussion on #2007, I started experimenting with shadow DOM and it turns out it's pretty easy to make it work with the debug toolbar.

Most of the changes are related to getting the correct root for querying elements in JS, and those could be extracted to a separate pull request to make it easy to review the changes specific to shadow DOM.

The only change required for custom panels is that they should access the root debug element via the getDebugElement function in utils.js instead of directly querying #djDebug, and they should perform all element queries from that root.

This change effectively isolates the Debug Toolbar styles from the rest of the page, which would make it easier to implement all sorts of utility classes for more advanced panel styling.

Checklist:

• I have added the relevant tests for this change.
• I have added an item to the Pending section of docs/changes.rst.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
debug_toolbar
toolbar.py
debug_toolbar/panels
profiling.py
Project Total

This report was generated by python-coverage-comment-action

[tim-schilling]

Oh dang, this was a much simpler implementation than I expected. Thank you @federicobond!

I think we may want to make a mention of how to fetch JS elements in the JavaScript documentation somewhere. I'm going to assume, this will also impact any third-party panels that have some JS that looks for elements in the DOM? That may make things a bit tricky to support backwards compatibility for a version or two 🤔 What do you think?

[federicobond]

@tim-schilling I think we could take this approach:

Phase 1: Update the built-in JS in this version to support both approaches and add a note for custom panel developers to query elements from the root using the new getDebugElement function from utils.js. While we are here, we could add an option for early adopters to opt-in to shadow DOM.

Phase 2: Make Shadow DOM the default but allow users to opt-out if they experience broken custom panels.

This would give panel developers plenty of time to make their panels compatible with a shadow DOM toolbar and allow us to get feedback from early adopters.

[tim-schilling]

I like it. That sounds like it'll work well. I think the last area of concern is CSP. We'll need to do some investigation into that too.

[federicobond]

Cool! I went ahead and wrote some more changes to support opt-in shadow DOM via the USE_SHADOW_DOM setting.

As for CSP, I tested a CSP config with "default-src": [CSP.SELF, CSP.NONCE] which worked correctly with shadow DOM. The way the scripts and styles are loaded does not change whether we are using shadow DOM or not so it makes sense, but I'm not an expert on CSP.

Btw, we might want to get that CSP config into the example app to ease compliance but not sure how we would like to handle older Django versions in CI.