Skip to content

[BUG] hiding header or footer does not extend workspace view appropriately #522

Closed

Description

@Byolock

Environment

Self-Hosted (Docker)

Version

2.0.3

Describe the problem

Hiding the footer or header does not lead to the iframe of the selected app extending into the free space, instead the background of the selected theme is visible.

Steps to reproduce

  1. add
   "hideComponents": {
      "hideSearch": true,
      "hideHeading": true,
      "hideNav": true,
      "hideSettings": true,
      "hideFooter": true
    },

to your configuration
2. apply configuration
3. switch to workspace view
4. select any app

Tested with Firefox and Brave Browser.
Probably also relates is the fact that hiding header and not footer leads to the footer not beeing at the bottom of the site.
I attached screenshots for both problems.

Additional info

[Background Image from the Adventure theme can be seen below the iframe]
dashy

[Footer is floating if hiding header]
dashy2

Please tick the boxes

Activity

  1. added
    🐛 Bug[ISSUE] Ticket describing something that isn't working
    on Mar 2, 2022
  2. lissy93 commented on Mar 28, 2022

    @lissy93
    Owner

    Heya @Byolock
    Thanks for the bug repot, and apologies for the delay in implementing this.
    It should now be fixed in #557 / 2.0.6
    Feel free to reach out if you need anything else :)

    If you are using a custom theme, and experience a similar issue in the future, then you can adjust the --footer-height CSS variable

  3. Byolock commented on Mar 28, 2022

    @Byolock
    Author

    @lissy93 No worries for the delay. Thanks for the change, however it seems to not fully fix my issue. The footer is now at the bottom but the iframe does still not extend all the way to the bottom of the window :
    dashy-workspace

    I tried to change --foother-height that didn't do anything, but im also not sure which value would be right. Tried to change from 128px to 64px and then to 256px and didn't see any visual difference.

  4. liss-bot commented on Apr 28, 2022

    @liss-bot
    Collaborator

    This issue has gone 6 weeks without an update. To keep the ticket open, please indicate that it is still relevant in a comment below. Otherwise it will be closed in 5 working days.

  5. lissy93 commented on Apr 28, 2022

    @lissy93
    Owner

    /keep-open

    This issue isn't resolved. I think I need to approach it differently to get the solution

  6. added
    📌 Keep Open[ISSUE][PR] Prevent auto-closing
    and removed
    ⚰️ Stale[ISSUE] [PR] No activity for over 1 month
    on Apr 28, 2022
  7. Byolock commented on Sep 3, 2022

    @Byolock
    Author

    @lissy93 Maybe this is something that raises some new ideas ?

    I finally had some time trying different css changes to see if I would get the the iframe to fit properly. I set the height of the iframe to calc(100% - var(--header-height) + var(--footer-height)). That change made the iframe fit nearly correctly (it is a few pixels to high but barely noticable). header-height value is 6.3rem footer-height value is 4rem. My guess is this is nearly working by pure chance or does that make any sense to you?

    Using calc(100% - var(--footer-height)) uses more space than the default calc(100% - var(--header-height) but still misses a fair bit of space.

    I did wonder, I have "hide header" enabled in the configuration, so why is the header height necessary to determine the height of the IFrame in the first place?

    Some further experimenting got me to the idea that calc(100% - var(--footer-height)) is probably correct and the missing space is because I can still see a small header even though I disabled it in the configuration. The header class has a padding property of 0.5rem. A look on the footer class revealed a padding of 0.25rem. That got me to 0.75rem, so I changed the Iframe height to : calc(100% - var(--footer-height) + 0.75rem). That wasn't correct either but it was obvious this change used up exactly half of the remaining space which should be used by the iFrame, so I changed it to calc(100% - var(--footer-height) + 1.5rem).
    This change made the iFrame now exactly as high as it should be. The interresting thing is, 1.5rem is exactly the margin-top property of the footer class. So maybe the correct solution to this problem is to take '100% height minus the height of the footer without its margin-top property' for the height of the IFrame?

    My understanding of CSS and the terminology is very limeted so I hope what i've written makes any sense.

  8. CrazyWolf13 commented on Feb 24, 2024

    @CrazyWolf13
    Collaborator

    #1463 Seems related

  9. added a commit that references this issue on Feb 27, 2024
    a155e2c
  10. liss-bot commented on Mar 3, 2024

    @liss-bot
    Collaborator

    The fix for this issue has now been released in 2.1.2 ✨

    If you haven't done so already, please update your instance to 2.1.2 or later. See 2.1.2 for full info.

    Feel free to reach out if you need any more support. If you are enjoying Dashy, consider supporting the project.

  11. alanmilinovic commented on Sep 3, 2025

    @alanmilinovic

    I my case this is not fixed.

  12. TheAzureWizard commented on Jul 29, 2026

    @TheAzureWizard

    This is not fixed.
    Brand new docker container, never used Dashy before.
    Great app, working well except this bug.

    It seems that the height of the extra space at the bottom is proportional to the number of hidden items.
    i.e. it's larger when 'hide header' is selected.

    With 'Hide Header'
    Image

    with nothing hidden (still some space missing)
    Image

    Options showing nothing hidden:
    Image

  13. lissy93 commented on Jul 29, 2026

    @lissy93
    Owner

    Sorry about that, lemme re-open
    I'm gonna totally re-do a lot of the workspace view when I come to fixing #2172, so will cover this off at the same time.

    Thank you for the screenshots @TheAzureWizard - that's really helpful

  14. liss-bot commented on Oct 23, 2026

    @liss-bot
    Collaborator

    Hey @Byolock, this has now been implemented in #2404, and will be released shortly in 4.8.13 😇
    We're sorry this one took so long 😔

  15. added
    ✅ Fixed[ISSUE] Auto-Assigned to Tickets whose fix has been deployed
    on Oct 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

✅ Fixed[ISSUE] Auto-Assigned to Tickets whose fix has been deployed🐛 Bug[ISSUE] Ticket describing something that isn't working📌 Keep Open[ISSUE][PR] Prevent auto-closing🔨 Fixed🛩️ Released 2.1.2🛩️ Released 4.8.13Included in release v4.8.13

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions