Repository navigation
[Broken Website] [Google Workspace enterprise] Google Meet chat breaks and has missing buttons #15953
Description
Prerequisites
- I searched for any existing report about this website issue to avoid opening a duplicate.
- I can reproduce this website issue in a new, unmodified web browser profile with Dark Reader installed as the only extension.
Website Issue Description
Google Meet chat breaks and you're missing buttons until you toggle it off and back on
Website Address
Steps To Reproduce
- Have dark reader enabled
- Join a google meet
- Observe the chat is broken and all the buttons are missing
- Toggle it off and on
- Observe the issue goes away
Screenshots
Operating System
Windows 11
Web Browser name and version
Firefox 155.0
Dark Reader version
4.9.130
Additional Context
No response
Activity
Myshor commentedon Sep 4, 2026
Hi @Fanatiikon,
Thanks for the report.
This specific chat interface (with rich text formatting, history controls, and attachment buttons) appears to be tied to a Google Workspace / enterprise account, which is not available on standard consumer Google accounts. On a regular account, the simplified chat input renders normally without these controls.
Since toggling Dark Reader off and on makes the buttons reappear, this looks like an asynchronous loading / timing issue where the dynamic engine calculates styles before the rich text toolbar finishes mounting into the DOM.
To help us pin down the cause without access to a Workspace test environment, could you provide:
display,opacity,visibility, orcolor/fillvalues).Once we have the DOM structure/classes, we can look into an appropriate fix.
Fanatiikon commentedon Sep 11, 2026
I couldn't find any script execution errors in the console.
Hopefully these help:
This seems to be the problem:
Disabling background color fixes it, but the moment I hover the buttons again they break. From what i can see background color re-enables itself.
Fanatiikon commentedon Sep 11, 2026
I checked a bit more it appears after toggling dark reader all 3 disappear and it works just fine, After i refresh they come back and it's broken.
Fanatiikon commentedon Sep 11, 2026
@layer {
html {
color-scheme: dark !important;
}
iframe {
color-scheme: dark !important;
}
input, textarea, select, button, dialog {
background-color: var(--darkreader-background-ffffff, #181a1b);
}
html, body, input, textarea, select, button {
border-color: var(--darkreader-border-4c4c4c, #736b5e);
color: var(--darkreader-text-000000, #e8e6e3);
}
a {
color: var(--darkreader-text-0040ff, #3391ff);
}
table {
border-color: var(--darkreader-border-808080, #545b5e);
}
mark {
color: var(--darkreader-text-000000, #e8e6e3);
}
::placeholder {
color: var(--darkreader-text-a9a9a9, #b2aba1);
}
input:-webkit-autofill,
textarea:-webkit-autofill,
select:-webkit-autofill {
background-color: var(--darkreader-background-faffbd, #404400) !important;
color: var(--darkreader-text-000000, #e8e6e3) !important;
}
scrollbar-color: var(--darkreader-background-b0b0b0, #454a4d) var(--darkreader-background-f1f1f1, #202324);
}
::selection {
background-color: var(--darkreader-background-0060d4, #004daa) !important;
color: var(--darkreader-text-ffffff, #e8e6e3) !important;
}
::-moz-selection {
background-color: var(--darkreader-background-0060d4, #004daa) !important;
color: var(--darkreader-text-ffffff, #e8e6e3) !important;
}
}
Pin pointed to here
Fanatiikon commentedon Sep 11, 2026
From what I could see it appears that the fallback rules are not being cleared after the page is done initialising.
Myshor commentedon Sep 13, 2026
Hi @Fanatiikon,
When you uncheck that
background-colorrule forbody :not(iframe), what other background rule in the Styles tab gets uncrossed (becomes active)?Please share a screenshot or paste that active rule and its selector from the Styles panel, so we can see what Google CSS is originally applied there.
Fanatiikon commentedon Sep 13, 2026
It seems to be from inline 17
To keep in mind when i toggle dark reader off and back to On it actually deletes all 3 Background-color/Color/Border-color
[-][Broken Website] Google Meet chat breaks and has missing buttons[/-][+][Broken Website] [Google Workspace enterprise] Google Meet chat breaks and has missing buttons[/+]Myshor commentedon Sep 14, 2026
Since this issue is specific to Google Workspace enterprise accounts, we cannot reproduce and debug it directly. The screenshots provided do not show the active DOM structure of the missing formatting bar.
Applying a global transparent background would break popups, tooltips, and modals across Google Meet, so we cannot merge a blind fix.
If you want this fixed, please reproduce the issue, right-click exactly where the missing button should be, select "Inspect", and copy the
outerHTMLof the button and its parent container. Otherwise, we are parking this issue until someone with a Workspace account can provide a working PR.Fanatiikon commentedon Sep 14, 2026
I uploaded the outerHTML of the chat container which is fully broken and not correctly displayed.
OuterHTML.txt
Myshor commentedon Sep 16, 2026
I have inspected the provided outerHTML snippet and analyzed the underlying styling logic.
The core issue stems from Dynamic mode forcing a dark
background-color. When you manually toggled that off, the inline rulediv { background-color: transparent; }kicked in. However, to systematically override Dark Reader's dynamic calculations via injected CSS fixes, we would have to enforcediv { background-color: transparent !important; }.Applying such a broad rule immediately causes major visual regressions: running a smoke test against standard Google Meet nodes instantly breaks dropdowns and pop-up menus, rendering them completely transparent and illegible.
A potential workaround would be using
IGNORE CSS URLtargeting the specific stylesheet responsible for these controls, or pinpointing the exact child node in the hierarchy to scope down the transparent background. However, doing this blindly based purely on an isolated outerHTML snippet without access to the live Google Workspace Enterprise stylesheets is pure guesswork. We cannot safely identify which exact element needs the override without risking regressions across the rest of the interface.Due to the lack of access to a live, reproducible environment with this specific UI, I am halting further work on this issue from my end.
Workarounds:
IGNORE CSS URL), and confirm no regression on modal menus, a PR is welcome.Leaving this open for community contributions.