Slow page load with Safari browser

Been trying all day to debug it, but even xdebug gets stuck :/ What I managed to figure out is that if you disable the 'view_main', in ProfileViewBuilder, the page at least loads again.

    return [
      'view_sidebar_buttons' => $view_sidebar_buttons,
      'view_main_tabs' => $view_main_tabs,
      'view_sidebar' => $view_sidebar,
      'view_main' => [], //$view_main,
    ];

Bit deeper, it's the 'layers' island. If you leave that out, page loads normal.

I had Claude AI have a go at this. After applying it's suggested solution, now the page loads again although still slow. Before it wouldn't load at all. So there might be something else still involved.

Here's the complete Claude AI Diagnosis:

The freeze is not the keydown handler — it is the sl-show handler in assets/js/keyboard.js:41-52. It has three defects that together produce a synchronous re-entry loop on Safari at initial page load, especially when the Layers island is present (which adds more Shoelace tooltip surface inside the same builder container).

1. Overly broad target check (line 42). event.target.querySelector('[data-island-action="help"]') returns truthy whenever the help button exists anywhere in the subtree of the element that fired sl-show, not only when the fired element is the help tooltip. On load, several Shoelace components inside the builder emit sl-show (tooltips on toolbar buttons, dropdowns, dialogs, drawers). The guard fails to filter them out.
2. Wrong tooltip selection (line 45). event.target.querySelector('sl-tooltip > div') returns the first inner
   
   in the subtree. In the toolbar this is typically the highlight or fullscreen tooltip, not the help tooltip. Writing keyboard help markup into it is a bug, and the mutation causes Shoelace to react.
3. Innerhtml mutation triggers Shoelace slotchange → repositioning → possibly another sl-show. Shoelace tooltips reflow when their content slot changes. On WebKit, the tooltip's anchor recomputation with the newly mutated content can emit another sl-show when the tooltip's popup is re-attached to the DOM (Safari re-fires the event on shadow-DOM host attachment). That re-fires the builder-level listener, and step 1 repeats.
4. Chrome/Firefox do not always re-fire sl-show after a slot mutation, which is why the freeze is Safari-specific.
5. The user said "when the Layers island is enabled" — that fits because Layers is a large view island whose panel contains many <sl-card> / <sl-details>-based db-layer elements. When the Layers panel opens, all of those Shoelace components can emit sl-show as they mount. Each one bubbles to builder, the handler runs, mutates a tooltip, that mutation cascades — loop.

Proof / cross-check

• The // @todo add debounce comment on line 101 is next to the keydown handler, showing that the module author already knew there's a re-entry problem in this file. The same class of bug exists in the sl-show handler above, but was never guarded.
• Every other sl-show listener in the module has a very tight event.target?.id === or event.target.id === 'db-first-drawer' guard (see db_drawer.js:275, db_drawer.js:290, db_drawer.js:389, theme_menu.js:68) — the keyboard.js one is the odd one out because it uses a descendant query instead of an identity check.
• keyboard.js is loaded via display_builder:display_builder (the top-level component), so the listener attaches for every builder. When Layers island renders, more Shoelace elements exist under .display-builder — so the "matching descendant" grows, and the frequency of sl-show bubbling matches increases dramatically.

Possible Fix

Tighten the sl-show handler so it only reacts to the help tooltip firing its own sl-show, and does not mutate DOM inside other tooltips. Two safe minimal changes:

1. Restrict to the exact help element by identity, not descendant match:
   

   builder.addEventListener('sl-show', (event) => {
     // Only react when the help tooltip itself opens.
     const helpButton = event.target.closest?.('[data-island-action="help"]')
       || event.target.querySelector?.(':scope > [data-island-action="help"]');
     if (!helpButton) return;
   
     const helpTooltip = helpButton.closest('sl-tooltip')
       || helpButton.querySelector('sl-tooltip');
     if (!helpTooltip || !helpTooltip.contains(event.target)) return;
   
     const helpKeyboard = helpTooltip.querySelector(':scope > div[slot="content"], :scope > div');
     if (!helpKeyboard) return;
   
     const nextHTML = `<ul class="db-keyboard-help">${Object.values(keyboardHelp).map((item) => `<li>${item}</li>`).join('')}</ul>`;
     if (helpKeyboard.innerHTML === nextHTML) return; // idempotent guard, cuts the loop
     helpKeyboard.innerHTML = nextHTML;
   });

2. At minimum, an idempotent write (the smallest possible patch that will stop the freeze in Safari today):
   

   const nextHTML = `<ul class="db-keyboard-help">${...}</ul>`;
   if (helpKeyboard.innerHTML !== nextHTML) {
     helpKeyboard.innerHTML = nextHTML;
   }

   The idempotence check means the second and subsequent bubbled sl-show events do not mutate the DOM, so Shoelace does not react and the loop cannot sustain.

3. Optionally, ignore non-trusted / retriggered events at the top of the handler:
   if (!event.isTrusted && event.target === lastTarget) return;
   Combining #1 and #2 is the robust fix. #2 alone is enough to stop the current Safari freeze without changing behavior for other browsers.

Verification steps

• In Safari, load a page with a .display-builder that has the Layers island enabled. Freeze should reproduce with current code.
• Apply the idempotent-write guard in assets/js/keyboard.js.
• Reload. Page should load normally. Hovering the help button should still show the keyboard shortcuts list including the y binding for Layers.
• Rerun Playwright: tests/src/Playwright/Tests/layers.spec.ts and tests/src/Playwright/Tests/toolbar.spec.ts should pass unchanged.