Bug 195045 - Some elements impossible to read due to incomplete styling
Summary: Some elements impossible to read due to incomplete styling
Status: Open
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Some People
Assignee: Bugmeister
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2014-11-15 19:06 UTC by Matthew Rezny
Modified: 2017-01-23 22:15 UTC (History)
0 users

See Also:


Attachments
QtWebKit rendering of New Bug page (99.65 KB, image/png)
2014-11-22 19:21 UTC, Matthew Rezny
no flags Details
QtWebKit rendering of currrent bug page (250.29 KB, image/png)
2014-11-22 19:22 UTC, Matthew Rezny
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Rezny freebsd_committer 2014-11-15 19:06:04 UTC
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.
Comment 1 Marcus von Appen freebsd_committer freebsd_triage 2014-11-19 20:21:24 UTC
(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.
Comment 2 Matthew Rezny freebsd_committer 2014-11-22 19:21:58 UTC
Created attachment 149728 [details]
QtWebKit rendering of New Bug page
Comment 3 Matthew Rezny freebsd_committer 2014-11-22 19:22:28 UTC
Created attachment 149729 [details]
QtWebKit rendering of currrent bug page
Comment 4 Marcus von Appen freebsd_committer freebsd_triage 2014-12-18 15:23:42 UTC
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!
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-05 15:23:04 UTC
@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?
Comment 6 Matthew Rezny freebsd_committer 2016-01-05 15:33:09 UTC
(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)
Comment 7 Rene Ladan freebsd_committer 2017-01-23 22:15:58 UTC
Reset