Numerous buttons have an extremely light background set but neglect to set a foreground. he text may be unreadable if the default color scheme for the browser is light on dark. The foreground should be specified instead of assuming it'll just match the non-default background. "Submit Bug" and "Remember values as bookmarkable template" buttons on new bug page, and "Save Changes" button when adding a comment to an existing bug are all affected by the block on lines 65-67 of (the second included) global.css: form input[type="submit"] { background-color: #eee; } This is a simple fix which sets the foreground to the assumed default: form input[type="submit"] { background-color: #eee; color: black; } I cannot help but notice that the "Add and attachment"/"Don't add an attachment" button uses a completely different style, and that once used that exposes a completely unstyled "Choose File" button. The attachment button specifies both foreground and background, but with insufficient contrast to be easily readble although enough to not be invisible like the others. BZ194106 is likely caused by this issue but that was closed without resolution. Hopefully providing an example correction will get this addressed. It is disappointing the style was never checked with a light on dark color scheme.
(In reply to matthew from comment #0) > Numerous buttons have an extremely light background set but neglect to set a > foreground. he text may be unreadable if the default color scheme for the > browser is light on dark. The foreground should be specified instead of > assuming it'll just match the non-default background. > > "Submit Bug" and "Remember values as bookmarkable template" buttons on new > bug page, and "Save Changes" button when adding a comment to an existing bug > are all affected by the block on lines 65-67 of (the second included) > global.css: > > form input[type="submit"] { > background-color: #eee; > } > > This is a simple fix which sets the foreground to the assumed default: > > form input[type="submit"] { > background-color: #eee; > color: black; > } The body{} section in global.css should define color: #000;, but as it seems, I messed it up by overriding the body{} section. Fixing this should render the detailed adjustment of yours (thanks for that) obsolete. While here, body{} also should explicitly set the background-color: #fff; to comply to the foreground. > I cannot help but notice that the "Add and attachment"/"Don't add an > attachment" button uses a completely different style, and that once used Right, I missed to override it. Thanks for noticing. > that exposes a completely unstyled "Choose File" button. The attachment > button specifies both foreground and background, but with insufficient > contrast to be easily readble although enough to not be invisible like the > others. "invisible" seems to be a browser-related issue. As soon as I swap the colors (foreground always white, background always white), the form input elements of the browser are completely ignored (at least in Firefox, yet to be checked in others). The attachment button itself is not a button (form input element), but a link on a dark background. Depending on your contrast and color scheme settings, its appearance may vary. If the style is not overriden, they are rendered based on the underlying style of the system UI toolkit (Win32 forms, Gtk+, etc.), which looks like a browser issue rather than a CSS issue to me. I'm not sure, if anything can be done about that.
Created attachment 149728 [details] QtWebKit rendering of New Bug page
Created attachment 149729 [details] QtWebKit rendering of currrent bug page
Sorry to keep you waiting with this. There are some things to be noticed regarding the browsers: * as written in comment 1, the current style of certain UI elements (such as real buttons, drop downs, etc.) is based on the toolkit styling, you use and controlled outside of the scope of the CSS. Yes, all elements could be styled to fit to the layout, but this is not the case right now. * testing the layouts is rather complex, if the behaviour is not fully controlled within the browser or CSS itself. To improve the situation for dark themes or swapped palettes, I'd like to get as close to your environment as possible. Could you provide more information about * your chosen browsers * pointers to the themes for them * pointers to the UI themes of yours (GTK, QT, etc.) * any (addition) palette/color/font/... customizations, you did on your browsers? Thanks!
@Marcus, I'm planning to bundle all existing and some new template / usability / UI issues under a meta issue. Do you want to keep this assigned or can we unassign then re-assess once that's complete?
(In reply to Marcus von Appen from comment #4) Sorry, I never noticed the last request until I dug up this old bug when mentioning a usability issue to koobs. Browser: QupZilla (-qt4 and -qt5 versions behave identical) Browser Theme: Linux Default (uses Qt with whatever style/theme is set for the system ) Environment: KDE4 with QtCurve controlling appearance of Qt4, Qt5 and Gtk+2 apps System Color Scheme: Krita blender (this is the important part, what sets light on dark appearance for all apps)
Reset