Skip to content

Content scrolls down by container's padding on load for pages without an autofocused input #14838

Closed
#14854
Closed
Content scrolls down by container's padding on load for pages without an autofocused input#14838
#14854
Assignees
jaygeorge

Description

@helloDanuk
helloDanuk
opened on Jun 18, 2026

Bug description

On every Control Panel page that (a) has no auto-focused input and (b) whose content overflows the viewport, the content area scrolls down by the top padding of .main-content (8px from sm:p-2`) right after load. It looks like a small "layout jump."

For example: This happens on the dashboard if it has a few widgets, or on an utilities page.

The cause is in the focus-management in resources/js/pages/layout/Layout.vue. focusMain() focuses the content wrapper as an accessibility convenience:

if (!autofocusInput) {
document.querySelector('#content-card')?.focus();
}

#content-card is a full-height wrapper (min-h-full, tabindex="-1") at the very top of the scrollable #main-content container, which has sm:p-2 padding. Calling .focus()without{ preventScroll: true } makes the browser scroll the overflowing container to bring the focused element into view, offsetting it by the 8px top padding.

This is why it only shows on input-less, overflowing pages (Dashboard, custom utility views). Listing pages (Collections, Assets, Users, …) are unaffected only as a side effect: their search field uses <Input :focus="true">, so an input is already focused when focusMain() runs and it returns early via the first branch — #content-card is never focused.

Bildschirmaufnahme.2026-06-18.um.16.27.54.mov

How to reproduce

  1. Open a CP page with no auto-focused input and enough content to overflow the viewport (e.g. Dashboard, or a custom Utility view).
  2. Make the browser window short enough that #main-content scrolls.
  3. Reload.

Expected: Content stays at scrollTop: 0.
Actual: Content scrolls down ~8px after load.

Quick console confirmation on such a page:

const mc = document.querySelector('.main-content');
mc.scrollTop = 0;
document.querySelector('#content-card').focus();
mc.scrollTop; // 8 (expected: 0)

Note: I could strangely reproduce this behaviour even on the empty state dashboard page from a fresh installation. But not always…

Suggested fix

Pass preventScroll when focusing the content wrapper in focusMain():

document.querySelector('#content-card')?.focus({ preventScroll: true });

Focus still moves to the content for keyboard/screen-reader users (the accessibility intent of focusMain() is preserved), but the browser no longer scrolls the container. The autofocus-input branch (autofocusInput.focus()) may want the same treatment for consistency.

A CSS-only workaround that confirms the diagnosis is .main-content { scroll-padding-top: 0.5rem; }, but { preventScroll: true } is the proper fix.

So far, this is what Claude has told me. I could fix it with for myself with this:

.main-content {
scroll-padding-top: 0.5rem; /* = p-2 / 8px */
}

Logs

Environment
EnvironmentLaravel Version: 13.16.1PHP Version: 8.4.19Composer Version: 2.9.5Environment: localDebug Mode: ENABLEDMaintenance Mode: OFFTimezone: UTCLocale: enCacheConfig: NOT CACHEDEvents: NOT CACHEDRoutes: NOT CACHEDViews: CACHEDDriversBroadcasting: logCache: fileDatabase: sqliteLogs: stack / singleMail: logQueue: syncSession: fileStoragepublic/storage: NOT LINKEDStatamicAddons: 0License Key: Not setSites: 1Stache Watcher: Enabled (auto)Static Caching: DisabledVersion: 6.21.0 PRO
Installation
Fresh statamic/statamic site via CLI
Additional details
No response
Metadata
Metadata
Assignees
Labels
No labels
No labels
Type
No type
Projects
No projects
    Milestone
    No milestone
    Relationships
    None yet
    Development
    No branches or pull requests
    Issue actions
    
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Add copy buttons to all 
     blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Content scrolls down by container's padding on load for pages without an autofocused input · Issue #14838 · statamic/cms · GitHub
    Skip to content
    Content scrolls down by container's padding on load for pages without an autofocused input #14838
    Closed
    #14854
    Closed
    Content scrolls down by container's padding on load for pages without an autofocused input#14838
    #14854
    Assignees
    jaygeorge
    Description
    @helloDanuk
    helloDanuk
    opened on Jun 18, 2026
    Bug description
    On every Control Panel page that (a) has no auto-focused input and (b) whose content overflows the viewport, the content area scrolls down by the top padding of .main-content (8px from sm:p-2`) right after load. It looks like a small "layout jump."
    For example: This happens on the dashboard if it has a few widgets, or on an utilities page.
    The cause is in the focus-management in resources/js/pages/layout/Layout.vue. focusMain() focuses the content wrapper as an accessibility convenience:
    if (!autofocusInput) {
document.querySelector('#content-card')?.focus();
}

    #content-card is a full-height wrapper (min-h-full, tabindex="-1") at the very top of the scrollable #main-content container, which has sm:p-2 padding. Calling .focus()without{ preventScroll: true } makes the browser scroll the overflowing container to bring the focused element into view, offsetting it by the 8px top padding.
    This is why it only shows on input-less, overflowing pages (Dashboard, custom utility views). Listing pages (Collections, Assets, Users, …) are unaffected only as a side effect: their search field uses <Input :focus="true">, so an input is already focused when focusMain() runs and it returns early via the first branch — #content-card is never focused.
    Bildschirmaufnahme.2026-06-18.um.16.27.54.mov
    How to reproduce
    1. Open a CP page with no auto-focused input and enough content to overflow the viewport (e.g. Dashboard, or a custom Utility view).
    2. Make the browser window short enough that #main-content scrolls.
    3. Reload.
    Expected: Content stays at scrollTop: 0.
    Actual: Content scrolls down ~8px after load.
    Quick console confirmation on such a page:
    const mc = document.querySelector('.main-content');
mc.scrollTop = 0;
document.querySelector('#content-card').focus();
mc.scrollTop; // 8 (expected: 0)

    Note: I could strangely reproduce this behaviour even on the empty state dashboard page from a fresh installation. But not always…
    Suggested fix
    Pass preventScroll when focusing the content wrapper in focusMain():
    document.querySelector('#content-card')?.focus({ preventScroll: true });

    Focus still moves to the content for keyboard/screen-reader users (the accessibility intent of focusMain() is preserved), but the browser no longer scrolls the container. The autofocus-input branch (autofocusInput.focus()) may want the same treatment for consistency.
    A CSS-only workaround that confirms the diagnosis is .main-content { scroll-padding-top: 0.5rem; }, but { preventScroll: true } is the proper fix.
    So far, this is what Claude has told me. I could fix it with for myself with this:
    .main-content {
scroll-padding-top: 0.5rem; /* = p-2 / 8px */
}

    Logs
    Environment
    EnvironmentLaravel Version: 13.16.1PHP Version: 8.4.19Composer Version: 2.9.5Environment: localDebug Mode: ENABLEDMaintenance Mode: OFFTimezone: UTCLocale: enCacheConfig: NOT CACHEDEvents: NOT CACHEDRoutes: NOT CACHEDViews: CACHEDDriversBroadcasting: logCache: fileDatabase: sqliteLogs: stack / singleMail: logQueue: syncSession: fileStoragepublic/storage: NOT LINKEDStatamicAddons: 0License Key: Not setSites: 1Stache Watcher: Enabled (auto)Static Caching: DisabledVersion: 6.21.0 PRO
    Installation
    Fresh statamic/statamic site via CLI
    Additional details
    No response
    Metadata
    Metadata
    Assignees
    Labels
    No labels
    No labels
    Type
    No type
    Projects
    No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions
      
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Content scrolls down by container's padding on load for pages without an autofocused input · Issue #14838 · statamic/cms · GitHub
      Skip to content
      Content scrolls down by container's padding on load for pages without an autofocused input #14838
      Closed
      #14854
      Closed
      Content scrolls down by container's padding on load for pages without an autofocused input#14838
      #14854
      Assignees
      jaygeorge
      Description
      @helloDanuk
      helloDanuk
      opened on Jun 18, 2026
      Bug description
      On every Control Panel page that (a) has no auto-focused input and (b) whose content overflows the viewport, the content area scrolls down by the top padding of .main-content (8px from sm:p-2`) right after load. It looks like a small "layout jump."
      For example: This happens on the dashboard if it has a few widgets, or on an utilities page.
      The cause is in the focus-management in resources/js/pages/layout/Layout.vue. focusMain() focuses the content wrapper as an accessibility convenience:
      if (!autofocusInput) {
document.querySelector('#content-card')?.focus();
}

      #content-card is a full-height wrapper (min-h-full, tabindex="-1") at the very top of the scrollable #main-content container, which has sm:p-2 padding. Calling .focus()without{ preventScroll: true } makes the browser scroll the overflowing container to bring the focused element into view, offsetting it by the 8px top padding.
      This is why it only shows on input-less, overflowing pages (Dashboard, custom utility views). Listing pages (Collections, Assets, Users, …) are unaffected only as a side effect: their search field uses <Input :focus="true">, so an input is already focused when focusMain() runs and it returns early via the first branch — #content-card is never focused.
      Bildschirmaufnahme.2026-06-18.um.16.27.54.mov
      How to reproduce
      1. Open a CP page with no auto-focused input and enough content to overflow the viewport (e.g. Dashboard, or a custom Utility view).
      2. Make the browser window short enough that #main-content scrolls.
      3. Reload.
      Expected: Content stays at scrollTop: 0.
      Actual: Content scrolls down ~8px after load.
      Quick console confirmation on such a page:
      const mc = document.querySelector('.main-content');
mc.scrollTop = 0;
document.querySelector('#content-card').focus();
mc.scrollTop; // 8 (expected: 0)

      Note: I could strangely reproduce this behaviour even on the empty state dashboard page from a fresh installation. But not always…
      Suggested fix
      Pass preventScroll when focusing the content wrapper in focusMain():
      document.querySelector('#content-card')?.focus({ preventScroll: true });

      Focus still moves to the content for keyboard/screen-reader users (the accessibility intent of focusMain() is preserved), but the browser no longer scrolls the container. The autofocus-input branch (autofocusInput.focus()) may want the same treatment for consistency.
      A CSS-only workaround that confirms the diagnosis is .main-content { scroll-padding-top: 0.5rem; }, but { preventScroll: true } is the proper fix.
      So far, this is what Claude has told me. I could fix it with for myself with this:
      .main-content {
scroll-padding-top: 0.5rem; /* = p-2 / 8px */
}

      Logs
      Environment
      EnvironmentLaravel Version: 13.16.1PHP Version: 8.4.19Composer Version: 2.9.5Environment: localDebug Mode: ENABLEDMaintenance Mode: OFFTimezone: UTCLocale: enCacheConfig: NOT CACHEDEvents: NOT CACHEDRoutes: NOT CACHEDViews: CACHEDDriversBroadcasting: logCache: fileDatabase: sqliteLogs: stack / singleMail: logQueue: syncSession: fileStoragepublic/storage: NOT LINKEDStatamicAddons: 0License Key: Not setSites: 1Stache Watcher: Enabled (auto)Static Caching: DisabledVersion: 6.21.0 PRO
      Installation
      Fresh statamic/statamic site via CLI
      Additional details
      No response
      Metadata
      Metadata
      Assignees
      Labels
      No labels
      No labels
      Type
      No type
      Projects
      No projects
        Milestone
        No milestone
        Relationships
        None yet
        Development
        No branches or pull requests
        Issue actions
        
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Content scrolls down by container's padding on load for pages without an autofocused input · Issue #14838 · statamic/cms · GitHub
        Skip to content
        Content scrolls down by container's padding on load for pages without an autofocused input #14838
        Closed
        #14854
        Closed
        Content scrolls down by container's padding on load for pages without an autofocused input#14838
        #14854
        Assignees
        jaygeorge
        Description
        @helloDanuk
        helloDanuk
        opened on Jun 18, 2026
        Bug description
        On every Control Panel page that (a) has no auto-focused input and (b) whose content overflows the viewport, the content area scrolls down by the top padding of .main-content (8px from sm:p-2`) right after load. It looks like a small "layout jump."
        For example: This happens on the dashboard if it has a few widgets, or on an utilities page.
        The cause is in the focus-management in resources/js/pages/layout/Layout.vue. focusMain() focuses the content wrapper as an accessibility convenience:
        if (!autofocusInput) {
document.querySelector('#content-card')?.focus();
}

        #content-card is a full-height wrapper (min-h-full, tabindex="-1") at the very top of the scrollable #main-content container, which has sm:p-2 padding. Calling .focus()without{ preventScroll: true } makes the browser scroll the overflowing container to bring the focused element into view, offsetting it by the 8px top padding.
        This is why it only shows on input-less, overflowing pages (Dashboard, custom utility views). Listing pages (Collections, Assets, Users, …) are unaffected only as a side effect: their search field uses <Input :focus="true">, so an input is already focused when focusMain() runs and it returns early via the first branch — #content-card is never focused.
        Bildschirmaufnahme.2026-06-18.um.16.27.54.mov
        How to reproduce
        1. Open a CP page with no auto-focused input and enough content to overflow the viewport (e.g. Dashboard, or a custom Utility view).
        2. Make the browser window short enough that #main-content scrolls.
        3. Reload.
        Expected: Content stays at scrollTop: 0.
        Actual: Content scrolls down ~8px after load.
        Quick console confirmation on such a page:
        const mc = document.querySelector('.main-content');
mc.scrollTop = 0;
document.querySelector('#content-card').focus();
mc.scrollTop; // 8 (expected: 0)

        Note: I could strangely reproduce this behaviour even on the empty state dashboard page from a fresh installation. But not always…
        Suggested fix
        Pass preventScroll when focusing the content wrapper in focusMain():
        document.querySelector('#content-card')?.focus({ preventScroll: true });

        Focus still moves to the content for keyboard/screen-reader users (the accessibility intent of focusMain() is preserved), but the browser no longer scrolls the container. The autofocus-input branch (autofocusInput.focus()) may want the same treatment for consistency.
        A CSS-only workaround that confirms the diagnosis is .main-content { scroll-padding-top: 0.5rem; }, but { preventScroll: true } is the proper fix.
        So far, this is what Claude has told me. I could fix it with for myself with this:
        .main-content {
scroll-padding-top: 0.5rem; /* = p-2 / 8px */
}

        Logs
        Environment
        EnvironmentLaravel Version: 13.16.1PHP Version: 8.4.19Composer Version: 2.9.5Environment: localDebug Mode: ENABLEDMaintenance Mode: OFFTimezone: UTCLocale: enCacheConfig: NOT CACHEDEvents: NOT CACHEDRoutes: NOT CACHEDViews: CACHEDDriversBroadcasting: logCache: fileDatabase: sqliteLogs: stack / singleMail: logQueue: syncSession: fileStoragepublic/storage: NOT LINKEDStatamicAddons: 0License Key: Not setSites: 1Stache Watcher: Enabled (auto)Static Caching: DisabledVersion: 6.21.0 PRO
        Installation
        Fresh statamic/statamic site via CLI
        Additional details
        No response
        Metadata
        Metadata
        Assignees
        Labels
        No labels
        No labels
        Type
        No type
        Projects
        No projects
          Milestone
          No milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Content scrolls down by container's padding on load for pages without an autofocused input · Issue #14838 · statamic/cms · GitHub
          Skip to content
          Content scrolls down by container's padding on load for pages without an autofocused input #14838
          Closed
          #14854
          Closed
          Content scrolls down by container's padding on load for pages without an autofocused input#14838
          #14854
          Assignees
          jaygeorge
          Description
          @helloDanuk
          helloDanuk
          opened on Jun 18, 2026
          Bug description
          On every Control Panel page that (a) has no auto-focused input and (b) whose content overflows the viewport, the content area scrolls down by the top padding of .main-content (8px from sm:p-2`) right after load. It looks like a small "layout jump."
          For example: This happens on the dashboard if it has a few widgets, or on an utilities page.
          The cause is in the focus-management in resources/js/pages/layout/Layout.vue. focusMain() focuses the content wrapper as an accessibility convenience:
          if (!autofocusInput) {
document.querySelector('#content-card')?.focus();
}

          #content-card is a full-height wrapper (min-h-full, tabindex="-1") at the very top of the scrollable #main-content container, which has sm:p-2 padding. Calling .focus()without{ preventScroll: true } makes the browser scroll the overflowing container to bring the focused element into view, offsetting it by the 8px top padding.
          This is why it only shows on input-less, overflowing pages (Dashboard, custom utility views). Listing pages (Collections, Assets, Users, …) are unaffected only as a side effect: their search field uses <Input :focus="true">, so an input is already focused when focusMain() runs and it returns early via the first branch — #content-card is never focused.
          Bildschirmaufnahme.2026-06-18.um.16.27.54.mov
          How to reproduce
          1. Open a CP page with no auto-focused input and enough content to overflow the viewport (e.g. Dashboard, or a custom Utility view).
          2. Make the browser window short enough that #main-content scrolls.
          3. Reload.
          Expected: Content stays at scrollTop: 0.
          Actual: Content scrolls down ~8px after load.
          Quick console confirmation on such a page:
          const mc = document.querySelector('.main-content');
mc.scrollTop = 0;
document.querySelector('#content-card').focus();
mc.scrollTop; // 8 (expected: 0)

          Note: I could strangely reproduce this behaviour even on the empty state dashboard page from a fresh installation. But not always…
          Suggested fix
          Pass preventScroll when focusing the content wrapper in focusMain():
          document.querySelector('#content-card')?.focus({ preventScroll: true });

          Focus still moves to the content for keyboard/screen-reader users (the accessibility intent of focusMain() is preserved), but the browser no longer scrolls the container. The autofocus-input branch (autofocusInput.focus()) may want the same treatment for consistency.
          A CSS-only workaround that confirms the diagnosis is .main-content { scroll-padding-top: 0.5rem; }, but { preventScroll: true } is the proper fix.
          So far, this is what Claude has told me. I could fix it with for myself with this:
          .main-content {
scroll-padding-top: 0.5rem; /* = p-2 / 8px */
}

          Logs
          Environment
          EnvironmentLaravel Version: 13.16.1PHP Version: 8.4.19Composer Version: 2.9.5Environment: localDebug Mode: ENABLEDMaintenance Mode: OFFTimezone: UTCLocale: enCacheConfig: NOT CACHEDEvents: NOT CACHEDRoutes: NOT CACHEDViews: CACHEDDriversBroadcasting: logCache: fileDatabase: sqliteLogs: stack / singleMail: logQueue: syncSession: fileStoragepublic/storage: NOT LINKEDStatamicAddons: 0License Key: Not setSites: 1Stache Watcher: Enabled (auto)Static Caching: DisabledVersion: 6.21.0 PRO
          Installation
          Fresh statamic/statamic site via CLI
          Additional details
          No response
          Metadata
          Metadata
          Assignees
          Labels
          No labels
          No labels
          Type
          No type
          Projects
          No projects
            Milestone
            No milestone
            Relationships
            None yet
            Development
            No branches or pull requests
            Issue actions
            
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Content scrolls down by container's padding on load for pages without an autofocused input · Issue #14838 · statamic/cms · GitHub
            Skip to content
            Content scrolls down by container's padding on load for pages without an autofocused input #14838
            Closed
            #14854
            Closed
            Content scrolls down by container's padding on load for pages without an autofocused input#14838
            #14854
            Assignees
            jaygeorge
            Description
            @helloDanuk
            helloDanuk
            opened on Jun 18, 2026
            Bug description
            On every Control Panel page that (a) has no auto-focused input and (b) whose content overflows the viewport, the content area scrolls down by the top padding of .main-content (8px from sm:p-2`) right after load. It looks like a small "layout jump."
            For example: This happens on the dashboard if it has a few widgets, or on an utilities page.
            The cause is in the focus-management in resources/js/pages/layout/Layout.vue. focusMain() focuses the content wrapper as an accessibility convenience:
            if (!autofocusInput) {
document.querySelector('#content-card')?.focus();
}

            #content-card is a full-height wrapper (min-h-full, tabindex="-1") at the very top of the scrollable #main-content container, which has sm:p-2 padding. Calling .focus()without{ preventScroll: true } makes the browser scroll the overflowing container to bring the focused element into view, offsetting it by the 8px top padding.
            This is why it only shows on input-less, overflowing pages (Dashboard, custom utility views). Listing pages (Collections, Assets, Users, …) are unaffected only as a side effect: their search field uses <Input :focus="true">, so an input is already focused when focusMain() runs and it returns early via the first branch — #content-card is never focused.
            Bildschirmaufnahme.2026-06-18.um.16.27.54.mov
            How to reproduce
            1. Open a CP page with no auto-focused input and enough content to overflow the viewport (e.g. Dashboard, or a custom Utility view).
            2. Make the browser window short enough that #main-content scrolls.
            3. Reload.
            Expected: Content stays at scrollTop: 0.
            Actual: Content scrolls down ~8px after load.
            Quick console confirmation on such a page:
            const mc = document.querySelector('.main-content');
mc.scrollTop = 0;
document.querySelector('#content-card').focus();
mc.scrollTop; // 8 (expected: 0)

            Note: I could strangely reproduce this behaviour even on the empty state dashboard page from a fresh installation. But not always…
            Suggested fix
            Pass preventScroll when focusing the content wrapper in focusMain():
            document.querySelector('#content-card')?.focus({ preventScroll: true });

            Focus still moves to the content for keyboard/screen-reader users (the accessibility intent of focusMain() is preserved), but the browser no longer scrolls the container. The autofocus-input branch (autofocusInput.focus()) may want the same treatment for consistency.
            A CSS-only workaround that confirms the diagnosis is .main-content { scroll-padding-top: 0.5rem; }, but { preventScroll: true } is the proper fix.
            So far, this is what Claude has told me. I could fix it with for myself with this:
            .main-content {
scroll-padding-top: 0.5rem; /* = p-2 / 8px */
}

            Logs
            Environment
            EnvironmentLaravel Version: 13.16.1PHP Version: 8.4.19Composer Version: 2.9.5Environment: localDebug Mode: ENABLEDMaintenance Mode: OFFTimezone: UTCLocale: enCacheConfig: NOT CACHEDEvents: NOT CACHEDRoutes: NOT CACHEDViews: CACHEDDriversBroadcasting: logCache: fileDatabase: sqliteLogs: stack / singleMail: logQueue: syncSession: fileStoragepublic/storage: NOT LINKEDStatamicAddons: 0License Key: Not setSites: 1Stache Watcher: Enabled (auto)Static Caching: DisabledVersion: 6.21.0 PRO
            Installation
            Fresh statamic/statamic site via CLI
            Additional details
            No response
            Metadata
            Metadata
            Assignees
            Labels
            No labels
            No labels
            Type
            No type
            Projects
            No projects
              Milestone
              No milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Content scrolls down by container's padding on load for pages without an autofocused input · Issue #14838 · statamic/cms · GitHub
              Skip to content
              Content scrolls down by container's padding on load for pages without an autofocused input #14838
              Closed
              #14854
              Closed
              Content scrolls down by container's padding on load for pages without an autofocused input#14838
              #14854
              Assignees
              jaygeorge
              Description
              @helloDanuk
              helloDanuk
              opened on Jun 18, 2026
              Bug description
              On every Control Panel page that (a) has no auto-focused input and (b) whose content overflows the viewport, the content area scrolls down by the top padding of .main-content (8px from sm:p-2`) right after load. It looks like a small "layout jump."
              For example: This happens on the dashboard if it has a few widgets, or on an utilities page.
              The cause is in the focus-management in resources/js/pages/layout/Layout.vue. focusMain() focuses the content wrapper as an accessibility convenience:
              if (!autofocusInput) {
document.querySelector('#content-card')?.focus();
}

              #content-card is a full-height wrapper (min-h-full, tabindex="-1") at the very top of the scrollable #main-content container, which has sm:p-2 padding. Calling .focus()without{ preventScroll: true } makes the browser scroll the overflowing container to bring the focused element into view, offsetting it by the 8px top padding.
              This is why it only shows on input-less, overflowing pages (Dashboard, custom utility views). Listing pages (Collections, Assets, Users, …) are unaffected only as a side effect: their search field uses <Input :focus="true">, so an input is already focused when focusMain() runs and it returns early via the first branch — #content-card is never focused.
              Bildschirmaufnahme.2026-06-18.um.16.27.54.mov
              How to reproduce
              1. Open a CP page with no auto-focused input and enough content to overflow the viewport (e.g. Dashboard, or a custom Utility view).
              2. Make the browser window short enough that #main-content scrolls.
              3. Reload.
              Expected: Content stays at scrollTop: 0.
              Actual: Content scrolls down ~8px after load.
              Quick console confirmation on such a page:
              const mc = document.querySelector('.main-content');
mc.scrollTop = 0;
document.querySelector('#content-card').focus();
mc.scrollTop; // 8 (expected: 0)

              Note: I could strangely reproduce this behaviour even on the empty state dashboard page from a fresh installation. But not always…
              Suggested fix
              Pass preventScroll when focusing the content wrapper in focusMain():
              document.querySelector('#content-card')?.focus({ preventScroll: true });

              Focus still moves to the content for keyboard/screen-reader users (the accessibility intent of focusMain() is preserved), but the browser no longer scrolls the container. The autofocus-input branch (autofocusInput.focus()) may want the same treatment for consistency.
              A CSS-only workaround that confirms the diagnosis is .main-content { scroll-padding-top: 0.5rem; }, but { preventScroll: true } is the proper fix.
              So far, this is what Claude has told me. I could fix it with for myself with this:
              .main-content {
scroll-padding-top: 0.5rem; /* = p-2 / 8px */
}

              Logs
              Environment
              EnvironmentLaravel Version: 13.16.1PHP Version: 8.4.19Composer Version: 2.9.5Environment: localDebug Mode: ENABLEDMaintenance Mode: OFFTimezone: UTCLocale: enCacheConfig: NOT CACHEDEvents: NOT CACHEDRoutes: NOT CACHEDViews: CACHEDDriversBroadcasting: logCache: fileDatabase: sqliteLogs: stack / singleMail: logQueue: syncSession: fileStoragepublic/storage: NOT LINKEDStatamicAddons: 0License Key: Not setSites: 1Stache Watcher: Enabled (auto)Static Caching: DisabledVersion: 6.21.0 PRO
              Installation
              Fresh statamic/statamic site via CLI
              Additional details
              No response
              Metadata
              Metadata
              Assignees
              Labels
              No labels
              No labels
              Type
              No type
              Projects
              No projects
                Milestone
                No milestone
                Relationships
                None yet
                Development
                No branches or pull requests
                Issue actions
                
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Content scrolls down by container's padding on load for pages without an autofocused input · Issue #14838 · statamic/cms · GitHub
                Skip to content
                Content scrolls down by container's padding on load for pages without an autofocused input #14838
                Closed
                #14854
                Closed
                Content scrolls down by container's padding on load for pages without an autofocused input#14838
                #14854
                Assignees
                jaygeorge
                Description
                @helloDanuk
                helloDanuk
                opened on Jun 18, 2026
                Bug description
                On every Control Panel page that (a) has no auto-focused input and (b) whose content overflows the viewport, the content area scrolls down by the top padding of .main-content (8px from sm:p-2`) right after load. It looks like a small "layout jump."
                For example: This happens on the dashboard if it has a few widgets, or on an utilities page.
                The cause is in the focus-management in resources/js/pages/layout/Layout.vue. focusMain() focuses the content wrapper as an accessibility convenience:
                if (!autofocusInput) {
document.querySelector('#content-card')?.focus();
}

                #content-card is a full-height wrapper (min-h-full, tabindex="-1") at the very top of the scrollable #main-content container, which has sm:p-2 padding. Calling .focus()without{ preventScroll: true } makes the browser scroll the overflowing container to bring the focused element into view, offsetting it by the 8px top padding.
                This is why it only shows on input-less, overflowing pages (Dashboard, custom utility views). Listing pages (Collections, Assets, Users, …) are unaffected only as a side effect: their search field uses <Input :focus="true">, so an input is already focused when focusMain() runs and it returns early via the first branch — #content-card is never focused.
                Bildschirmaufnahme.2026-06-18.um.16.27.54.mov
                How to reproduce
                1. Open a CP page with no auto-focused input and enough content to overflow the viewport (e.g. Dashboard, or a custom Utility view).
                2. Make the browser window short enough that #main-content scrolls.
                3. Reload.
                Expected: Content stays at scrollTop: 0.
                Actual: Content scrolls down ~8px after load.
                Quick console confirmation on such a page:
                const mc = document.querySelector('.main-content');
mc.scrollTop = 0;
document.querySelector('#content-card').focus();
mc.scrollTop; // 8 (expected: 0)

                Note: I could strangely reproduce this behaviour even on the empty state dashboard page from a fresh installation. But not always…
                Suggested fix
                Pass preventScroll when focusing the content wrapper in focusMain():
                document.querySelector('#content-card')?.focus({ preventScroll: true });

                Focus still moves to the content for keyboard/screen-reader users (the accessibility intent of focusMain() is preserved), but the browser no longer scrolls the container. The autofocus-input branch (autofocusInput.focus()) may want the same treatment for consistency.
                A CSS-only workaround that confirms the diagnosis is .main-content { scroll-padding-top: 0.5rem; }, but { preventScroll: true } is the proper fix.
                So far, this is what Claude has told me. I could fix it with for myself with this:
                .main-content {
scroll-padding-top: 0.5rem; /* = p-2 / 8px */
}

                Logs
                Environment
                EnvironmentLaravel Version: 13.16.1PHP Version: 8.4.19Composer Version: 2.9.5Environment: localDebug Mode: ENABLEDMaintenance Mode: OFFTimezone: UTCLocale: enCacheConfig: NOT CACHEDEvents: NOT CACHEDRoutes: NOT CACHEDViews: CACHEDDriversBroadcasting: logCache: fileDatabase: sqliteLogs: stack / singleMail: logQueue: syncSession: fileStoragepublic/storage: NOT LINKEDStatamicAddons: 0License Key: Not setSites: 1Stache Watcher: Enabled (auto)Static Caching: DisabledVersion: 6.21.0 PRO
                Installation
                Fresh statamic/statamic site via CLI
                Additional details
                No response
                Metadata
                Metadata
                Assignees
                Labels
                No labels
                No labels
                Type
                No type
                Projects
                No projects
                  Milestone
                  No milestone
                  Relationships
                  None yet
                  Development
                  No branches or pull requests
                  Issue actions