The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.This issue was identified in the Olivero issue queue, but seems to have a wider impact than just that theme.
When logged in to a fresh Drupal 10 installation, a fine thin line appears below the footer. This has been identified as the aria-live region, as needed by the admin toolbar. The visually-hidden class does not appear to adequately hide this element.
| Comment | File | Size | Author |
|---|---|---|---|
| #78 | Screenshot 2023-01-26 at 12.22.57 PM.png | 439.81 KB | andy-blum |
| #77 | Screenshot 2023-01-26 at 12.00.38 PM.png | 59.87 KB | andy-blum |
| #77 | Screenshot 2023-01-26 at 11.58.51 AM.png | 413.9 KB | andy-blum |
| #77 | Screenshot 2023-01-26 at 12.01.37 PM.png | 48.43 KB | andy-blum |
| #77 | Screenshot 2023-01-26 at 11.58.07 AM.png | 436.11 KB | andy-blum |
Issue fork drupal-3196976
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3196976-white-line-below
changes, plain diff MR !797
Comments
Comment #2
mherchelI'm unable to reproduce this.
Can you give me steps on how to reproduce?
Comment #3
aaron.ferris commentedI can reproduce this on a fresh install of Drupal, there is what appears to be a single pixel white line across the entire bottom of the site.
1. Pull fresh Drupal 9 build
2. Spin up local environment
3. Enable Olivero
4. Add a node with enough content to fill the viewport
5. Scroll to the bottom of the page
Ive added a red background to
<html>to showcase this more obviously.This is on Chrome Version 88.0.4324.192 - Mac OSx.
Edit: Change theme to Bartik - no white line.
Comment #4
aaron.ferris commentedI can't seem to see where this is coming from, Bartik has a background colour on the
bodywhich is why it doesnt show with that theme, although removing this property the white line shows in that theme as well.Further info: I can only recreate this when logged in, which seems to suggest it's related to the toolbar and the way the page is padded out when the toolbar is visible/active. Im still looking into it.
Comment #5
gauravvvv commentedComment #6
aaron.ferris commentedIsolated this to the
toolbarmodule. Uninstalling it and the white line disappears.At this point im unsure if this issue sits in the right place as the problem exists cross theme (masked by background colours on the body), but for my implementation i've just repositioned the footer 1px relatively, to cover the line. Yes its hacky and not the right way of fixing this, but at this stage it's an easy fix for the sake of a 1px line.
Attaching code snippet that resolves this for me:
Comment #7
bhumikavarshney commentedHi @aaron.ferris ,
After using your suggested changes the White line below footer issue is resolved.
Thanks
Comment #8
abhijith s commentedAdding patch based on #6.Please check
Comment #9
aaron.ferris commentedI’m not convinced it’s the right fix, but if we want to roll with it we will need to provide the pcss file as well.
I’ll do this later unless someone wants to jump in ahead of me.
Comment #10
aaron.ferris commentedComment #11
aaron.ferris commentedAttaching patch as above.
Comment #12
aaron.ferris commentedComment #13
aaron.ferris commentedMissed an '&'!!
Comment #14
aaron.ferris commentedComment #15
adalbertov commentedHello people, i have tried patch #13. The line was gone after the patch. The code also looks ok for me so I'm moving the issue to RTBC. I'm also adding a print of the result.
Comment #17
spokjePlease do not ask the testbot to try again until #3207086: [HEAD BROKEN] Consistent failure in MonthDatePluginTest is fixed.
Comment #18
spokje#3207086: [HEAD BROKEN] Consistent failure in MonthDatePluginTest was committed. Ordered retest and put this issue back to RTBC per #15.
Comment #19
spokjeComment #20
lauriiiTagging for subsystem maintainer review
Comment #22
rinku jacob 13 commentedpatch #13 successfully applied for 9.3.x-dev and 9.2.x-dev. thanks @aaron.ferris
Comment #23
chetanbharambe commentedVerified and tested patch #13.
Patch applied successfully and looks good to me.
Testing Steps:
# Install Olivero Theme
# Goto: Home Page
# Scroll down to footer -> User is able to see the white line below the footer
Expected Results:
# User should not see white line below the footer
Actual Results:
# User is able to see the white line below the footer
Looks good to me.
Can be a move to RTBC.
Comment #25
indrajithkb commentedHi @aaron.ferris thanks for the patch, it's helps to remove the white space under the footer, but it's adding a white space between layout-main-wrapper and footer
Attaching the SS after patch #13.
So am adding new patch with
margin-bottom:-1pxthis resolving the current issue. Please review my patch.Comment #26
manojithape commentedComment #27
manojithape commented@Indrajith KB: At the time of applying patch#25 getting an error and not able to apply the patch. Please refer attached screenshot. Due to this error moving this ticket to "Needs Work" status.
Comment #29
indrajithkb commentedComment #30
guilhermevp commentedPatch #30 works as intended. Not moving to RTBC because still needs subsystem maintainer review.
White line appears in clean 9.3.x.
Patch removes the line:
Comment #31
chetanbharambe commentedVerified and tested patch #25.
Patch applied successfully and looks good to me.
Testing Steps:
# Install Olivero Theme
# Goto: Home Page
# Scroll down to footer -> User is able to see the white line below the footer
Expected Results:
# User should not see white line below the footer
Actual Results:
# User is able to see the white line below the footer
Looks good to me.
Can be a move to RTBC
Comment #32
chetanbharambe commentedComment #33
lauriiiThis still needs subsystem maintainer review.
Comment #34
marcusvsouza commentedThe patch in comment #29 works fine and corrects the problem.
Comment #35
Agnesh Tank commentedVerified and tested applying patch 3196976-25 (Patch applied successfully and looks good )
Status: Reviewed & tested by Community
Testing Steps:
Expected Output:
Actual Output:
Comment #36
indrajithkb commentedHi @Agnesh Tank thanks for your time on working this issue, but for now we need to wait for subsystem maintainer review as mentioned in #33. So for now we can keep the issue with needs review status.
Right now you have uploaded the same patch of #25, i think you mistakenly done this.
When you are reviewing the patch then no need to upload the same patch, just attach SS if you have and please take care of above comments on the issues which you are planning to work on. I can see you are new to contribution, so i hope this will help you...!
I am confirming your account, Happy contributing...!!!
Comment #37
Agnesh Tank commentedHi @ Indrajith KB I went through the whole ticket and patch 25 was what i saw as patch.. so I applied and tested.. yes I am new to this getting use to this .. I am not aware of some term like "need to wait for subsystem maintainer review ".. So might have gone forward with testing. I uploaded the patch as evidence of the testing dine.. thanks for correcting will be taking note of this in moving forward.
Comment #38
mherchelComment #39
bnjmnmThe prior solutions will address the symptoms in some use cases, but I found the underlying cause, and that will address the issue altogether. It is due an element near the end of the page markup:
<div id="drupal-live-announce" class="visually-hidden" aria-live="polite" aria-busy="false"></div>This element exists for screenreaders and other assistive technology. There's no need to see it on a page. The
.visually-hiddenclass is intended to (suprise!) visually hide it from the page while keeping it present for assistive tech.The issue is due to
.visually-hiddenstyle not FULLY hiding the element.So this can be addressed by finding a different way to visually hide
#drupal-live-announce", or perhaps even improving the entire.visually-hiddenstyle to prevent future problems like this.Comment #40
roshanibhangale commentedVerified and tested patch #25 on the drupal 9.3.x-dev version. Patch applied successfully.
Testing Steps:
Expected Result:
Actual Results:
Please refer attached screenshot.
This is can be moved to RTBC.
Comment #41
roshanibhangale commentedComment #42
gauravvvv commentedProvided a patch as per the solution suggested in #39. Please review.
no need for interdiff as using different way for the solution.
Comment #43
gauravvvv commentedComment #44
radheymkumar commentedPatch #30 working fine
After patch while line below the footer has gone
for ref sharing screenshot
Comment #45
bnjmnmRe #44
There is no patch #30. Note that any patch prior to #43 is not worth testing as it's not a good approach to addressing the issue.
Since confirmation #43 changes the approach, another set of screenshots to prove it works may be useful... but once those are provided they do not need to be re-provided by other users. 25% of this issue is currently screenshots 😀. That last set of screenshots should include some area below the browser window so it is clear the line is gone and not just because the screenshot range cropped it out.
Comment #46
vikashsoni commentedApplied patch #43 working fine after patch white line in footer disappear
Thanks for the patch
Comment #49
Shubham Sharma 77 commentedApplied patch #43 applied successfully in drupal-9.5.x-dev
For ref sharing screenshots...
We can move this ticket to RTBC.
Comment #50
dishakatariya commentedi will review this issue.
Comment #51
dishakatariya commentedVerified and tested patch #43 on the drupal 9.5.x-dev version. Patch applied successfully.
Testing Steps:
1.Install Drupal 9.5.x-dev version
2.Set Olivero theme as admin and default theme (from Appearance)
3.Scroll down to the footer, observe that the user able to see the white line.
Expected Result:
The white line should not appear below the footer.
Actual Results:
User is not able to see the white line.
Please refer attached screenshot.
This is can be moved to RTBC.
Comment #52
bgreco commented#43 fixes the issue for me as well.
Comment #53
gauravvvv commentedComment #54
alexpottheight: 0;is not a good solution due to accessibility according to https://webaim.org/techniques/css/invisiblecontent - I think we should find a different solution.Comment #55
nikhil_110 commentedRe-rolled Patch #13. please review.
Comment #56
marcusvsouza commentedComment #57
asha nair commentedApplied patch #13. It removes the white line at the footer. Adding screenshots for reference
Comment #58
sakthivel m commented#58 Please review the patch
Comment #59
saman malik commentedComment #60
saman malik commentedVerified and tested patch #55 on the drupal 9.5.x-dev version. The patch was applied successfully.
Testing Steps:
1.Install Drupal 9.5.x-dev version
2. Set Olivero theme as admin and default theme (from Appearance)
3. Scroll down to the footer, and observe that the user can see the white line.
Expected Result:
The white line should not appear below the footer.
Actual Results:
White line visible.
Please refer attached screenshot.
After applying patch, Now is looking fine to me- no white line appear
This can be moved to RTBC.
Comment #61
alexpottA solution that uses #height won't work because of #54
Does the solution in #58 work? And is it correct - will it work for people using assistive tech?
Comment #63
Harish1688 commentedHi,
Found the issue in Drupal version 10.1 and tried the patch latest patch but that's not working with version, may be CSS could be changed in new version. please review the patch.
created a patch for this White-line-below-footer-3196976-61.patch, attached a screenshot.
Comment #64
Harish1688 commentedsorry missed the patch in last comment.
White-line-below-footer-3196976-61.patch
Comment #65
pradipmodh13 commentedHello @Harish1688,
I had checked this issue on Drupal 10.1 with fresh installation but didn't find this white line gap.
Can you share steps so i can reverify.
For reference attached screenshot.
Comment #66
nod_The patch in #64 is something else entirely.
What needs to be sorted out is the accessibility of the approach in #55 vs. #58 as asked in #61
Comment #67
saman malik commentedComment #68
gaurav-mathur commentedApplied patch #43 on Drupal 9.5.x-dev
The patch #worked perfectly issue got fixed
For Refer sharing screenshot.
Comment #69
gaurav-mathur commentedComment #70
heni_deepak commented#13 patch applied successfully.
Comment #71
andy-blumPer @bnjmnm in #39, this is not an Olivero issue, but a wider problem with the
visually-hiddenclass. As @alexpott points out in #54, we can't set the element to 0px by 0px.Based on the example provided in the A11Y Project website, I'm providing a patch to alter the visually hidden class.
This patch does the following:
.visually-hidden:where(:not(:focus, :focus-within, :active)). This keeps the selector specificity the same, but does not apply to any elements that have focus, or a child element with focus, or is an active link.clipproperty with theclip-pathproperty, which is supported for all D10 browsers (but not IE11, so don't backport this).inset: -100vh auto auto -100vw;to move the element fully off the page to the left and top, even if it's normal position would be fully bottom-left.white-space: nowrap;While the inset was not provided as part of the A11Y Project's example, it does appear to be necessary to remove this thin line, perhaps because it's the absolute last item on the page?
Comment #72
andy-blumComment #73
andy-blumComment #74
Ratan Priya commentedFixed failed custom command for comment #71.
Comment #76
Shubham Sharma 77 commentedFixed failed commands on #74 against 10.1.x
Attached reroll patch against Drupal 10.1.x
Comment #77
andy-blumPatch #76 causes some problems which seem to be related to using inset: 0;
On a fresh installation with patch #76, we now have a horizontal scrollbar, and visually hidden elements still have a width/height within the viewport. The element in the screenshot below is a contextual link that has some .visually-hidden rules overridden.
If we modify the inset values back to "-100vh auto auto -100vw", however, the horizonal scrollbar disappears, and our element no longer takes up space within the viewport.
Note: the second screenshot of the browser's styles has changed the overflow styles from "hidden" to "hidden !important". This has no effect as the style is only overridden with additional "hidden" values.
Comment #78
andy-blumDoing some additional digging, the exact element causing this overflow appears to be the contextual links button for the Olivero search block. That block has it's styles deliberately overriding position:relative, causing the contextual link button's offsetParent to be the header, and it's positioned absolutely at the edge of the viewport.
While this is an Olivero-specific issue, I still think we ought to be using patch #74 and adjusting the tests as needed.
Comment #79
bnjmnmPatch #76 should be ignored.
Working from #74, I reviewed a subset of the failing tests and they all appear to be due to .visually-hidden now being too hidden for our PHP tests to access. For example, I couldn't find any way to get
#drupal-live-announcecontents with a PHP call, but fortunately it's still available if we use JS to get it sostill gets us what we need. Methods such as
$page->find()or$assertSession->elementTextContains()were not able to find the element. It's possible there's a test method that can do this I'm not aware of, but the->evaluateScript()is an option I know will work.Given that our PHP tests can't see these .visually-hidden elements, we need to confirm they aren't hidden from Assistive Tech. I confirmed it is fine with Voiceover on all modern OSX browsers, but this will need to be checked with Narrator, NVDA, and JAWS on Windows too. A confirmation that Drupal.announce()/
#drupal-live-announcewill be sufficient.Comment #82
bnjmnm@VladimirAus I'm closing your merge request to avoid confusion that might arise from the assumption that the most recent activity is the most up-to-date, but in this case it's taking the solution back to an approach that was decided against over a year ago in #39. It's great to have people participating in issues, but if it's done without reading the full history of the issue (which can be a long read), the changes can be disruptive and hurt the chances of it ever being completed.
Comment #83
gauravvvv commentedComment #85
anupamkhosla1993@gmail.com commentedHi @bnjmnm, why don't we adopt Bootstrap 5's
margin: -1pxfix for `.visually-hidden` to prevent layout bugs? On focus, we revert to browswer default `margin: 0` so that things like 'skip to main content' behave like normal. If there could be things in legacy code or other themes that rely on original non margin values then we can at least target the `#drupal-live-announce` id and apply `margin: -1px` to it.Even in Drupal 11, for logged users, we have this recurring layout issue where the `#drupal-live-announce` element causes a 1px white line (gap) at the bottom of the page in themes like Olivero. Even though the element is `position: absolute`, it contributes to the Scrollable Overflow of the document because it sits at the end of the (Static Position). This forces the browser to extend the canvas by 1px, creating a visible gap below the footer.
Why do we have this bug, as far as I have researched:
https://www.w3.org/TR/css-position-3/
> see § 4 Absolute Positioning Layout Model. It can overlap in-flow content or other absolutely positioned elements, and is included in the scrollable overflow area of the box that generates is containing block. This positioning scheme is called absolute positioning.
The word 'scrollable overflow' is key here. Combine this with the following fact from the docs, https://www.w3.org/TR/CSS2/visudet.html 10.6.4 Absolutely positioned, non-replaced elements - point 2
> 2. 'top' and 'bottom' are 'auto' and 'height' is not 'auto', then set 'top' to the static position,
That leaving top/bottom/left/right to auto makes the absolute posiitioned element act like kind of static. If we apply bottom: 0 it fixes the 1px white line gap, but it is not a good solution.
The Solution We should align Drupal's .visually-hidden utility with Bootstrap 5 (and HTML5 Boilerplate) by adding margin: -1px.
Bootstrap 5 Source: View on GitHub
Proposed Patch We should update core/modules/system/css/components/hidden.module.css to include the negative margin, while ensuring we reset it during interaction states.
Proposed css:
PHPUnit Tests: Ran FunctionalJavascript/ModuleFilterTest.php.
Result: PASS.
The screen reades should work fine too.
Comment #87
marksmith commentedPrecise root cause and fix
Building on #39 and #85, here is another detailed explanation of why
#drupal-live-announcecreates the 1px white strip and scrollbar, and a targeted fix.Root cause
#drupal-live-announcehasposition: absolutewith no top, bottom, left, or right set. Per the CSS spec, when an absolutely positioned element has top: auto, it is placed at its static position - the position it would occupy in normal flow. Because this element is near the end of the , its static position lands at or beyond the bottom of the page content (in testing: top: 1401.11px, matching 100vh exactly).The browser's scrollHeight is computed as ceil() of the maximum layout extent of all content, including absolutely positioned elements that fall within the scrollable overflow of their containing block. ceil(1401.11) = 1402, while clientHeight = 1401 -> 1px of scrollable overflow -> scrollbar + 1px white strip visible at max scroll.
This happens regardless of zoom level or viewport size, because the element's static position always tracks the end of the page content, which itself is driven by min-block-size: 100vh (a fractional CSS pixel value at any non-integer device pixel ratio).
Fix
Change
#drupal-live-announcetoposition: fixed; top: 0. Fixed elements are explicitly excluded from scrollable overflow calculations, so they can never contribute to scrollHeight. Without top: 0, the element retains its auto-computed position which can still leak into scroll calculations. The element is already visually hidden via clip and overflow: hidden, so this change has zero visual or functional impact. Screen readers access aria-live regions regardless of their CSS positioning.css
This is more targeted than modifying the entire .visually-hidden class, which risks regressions in other components as discussed in #54, #79, and requires no changes to PHP tests because the element remains in the DOM and is still accessible via JS as document.querySelector('#drupal-live-announce').textContent.