System themes with light-on-dark tooltip coloring cause some Scrapbook X UI elements to display poorly

[ferdnyc]

I noticed that after performing a search in Scrapbook X, there's no easy way to clear away the search-results listing and return to the full scrapbook tree.

The search text can be manually deleted from the search box, yes, but that feels like something there should be a one-click way to achieve. Perhaps, either:

• A "broom"/clear icon in the search field, when it's non-empty (which I believe is how the other Scrapbook extensions do it), or
• A close-icon "x" on the search results summary bar (the one that reports "N Results Found", above the search results listing), to dismiss the results.

...Or even both, really.

[danny0838]

Do you mean a filtering search or a fulltext search?

[ferdnyc]

Sorry — a filtering search, one that presents results in the Scrapbook X sidebar. It's returning to the full (unfiltered) tree listing from there that's the difficulty.

[danny0838]

Doesn't the [x] button near the search result message work? (see below figure)

[ferdnyc]

Interesting!

I don't seem to have that [x]. Or, maybe I do, but it's not visible because (at least running Firefox 40.0.3 from the Fedora Linux distro packages) the message bar is formatted as white-text-on-black (or "dark").

Let me restart with other extensions disabled, to make sure it's not interference or something Stylish is applying, and experiment a little. I'll get back to you with the results. Thanks.

On Wed, Sep 2, 2015 at 8:26 AM, Danny Lin notifications@github.com wrote:

Doesn't the [x] button near the search result message work? (see below figure)

[image: 1] https://cloud.githubusercontent.com/assets/531417/9631025/af052a6a-51b0-11e5-9e34-f549d9908c4a.jpg

— Reply to this email directly or view it on GitHub https://github.com/danny0838/firefox-scrapbook/issues/66#issuecomment-137055106 .

[ferdnyc]

Aha! Yes, indeed, the issue is one of styling/visibility. This is what I see in Firefox 40.0.3 (Build identifier: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0), from the offiical Fedora Linux distro package for Fedora 22 (firefox-40.0.3-1.fc22.x86_64.rpm):

There is a close button present on the "N Results Found." bar, however due to the dark background it is completely invisible. (Can't even be detected by hovering, you have to just click blindly, and if you hit the correct spot then with no warning the search filtering will disappear.)

I see that the results bar is styled using the CSS2 System Color values 'InfoBackground' and 'InfoText', which according to MozDev's <color> documentation define the background and text colors (respectively) for tooltips. Firefox shows tooltips for me in white-on-transparent-black, probably in keeping with Fedora 22 / GNOME 3's dark system theme, so that checks out.

Long and short, it appears that the tooltip styling can't be relied upon to always provide light background / dark text. It may be better for Scrapbook X to define its own colors for those elements in its CSS.

Alternately, the close-button could be updated so that it's visible on either light or dark backgrounds, either by using an image with internal contrast (black 'x' with a white/light outline), or by explicitly styling a light background color behind the dark 'x' image.

[danny0838]

Currently the [x] button is using a transparent png image (see .sb-header-exit in chrome://scrapbook/skin/scrapbook.css), which unfortunately has the identical color with your system-defined background color. Using an image with internal contrast doesn't seem viable since it would make the button look bad in a system which already has suitable background color. We probably need another solution.

[ferdnyc]

Using an image with internal contrast doesn't seem viable since it would make the button look bad in a system which already has suitable background color.

I'm not sure that's necessarily the case. The following are all examples of duotone (contrasting) close buttons that look good against either a light or dark background. (In all three, the light-colored center areas are actually solid white, not transparent. However, they could also be 40-50% transparent white, or a light shade of any other color.)

(These are 256x256 PNGs, which I realize is massively oversized for the need, but the concept applies... in fact, a couple of these look OK as-is even when scaled down to 16x16.)

But barring a new close icon, I guess the alternatives would either be to style .sb-header wth explicit colors instead of relying on the tooltip styling

/* Perhaps... */
.sb-header {
  background-color: rgb(255,255,225);
  color: black;
}

or to set the backgorund-color of .sb-header-exit, the box containing just the close button, to provide contrast.

[danny0838]

We'd consider a thorough UI rework for such problem, but since I'm a poor artist, the process could be slow. By the way, have you noticed similar problems for other UI icons?

[ferdnyc]

I hadn't, so I decided to survey the issue empirically.

I used a combination of grep and zipgrep to scan over the source of my main Firefox profile's 44 installed extensions (I know, I have a problem), looking for any occurrences of "InfoBackground". (Case-insensitively.)

Other than the expected Scrapbook X CSS, the only places where InfoBackground appeared were:

• The Firebug code, but that turned out to be a red herring. InfoBackground/InfoText are present in the keywords list for the CSS debugging functionality, but they're not used in the extension's own styling.
• Our old friend All-In-One Sidebar again — you may remember that extension from my bug #64.

In AIOS it's only used when viewing the Add-ons manager in the sidebar (a feature I don't personally use), when styling the updates-available notification #updates-container. Sure enough, when I opened up the sidebar Add-ons manager:

...Looks a bit weird, but at the same time there's no close button, so it doesn't affect functionality.

So, it seems other extensions (at least, the very small sampling of the ones I use) don't tend to rely on InfoBackground/InfoText for styling much, at least not anymore. I know there was a time when it was suggested / used in example code as a method of creating notice-type messages, but I don't see much of it anymore.

In the main Firefox UI itself, the theming changes that made tooltips light text / dark background have caused some reported issues. I refer you to this Mozilla bug report: [GTK3] infotext and infobackground CSS colors are white with Ubuntu Ambiance & Radiance themes (which provide a background-image but no background-color for tooltips), causing e.g. notification bars are unreadable. There, one of the commenters (comment 4) even notes, 'However the "close" button is not visible until I hover it.'.

I tried to examine the test case for that bug on my system, but my Firefox build doesn't try to display the notification bar in question even in a new profile. Regardless, the issue there was that the active GTK theme didn't set background-color for tooltips, so they were getting white-on-white messages, a problem I'm not having. They also worked around it by creating a new -moz-appearance style -moz-gtk-info-bar for notification bars, which doesn't really do Scrapbook X any good. (The Ubuntu bug to add background-color to the GTK theme in question is still open and unresolved.)

In my explorations I did locate one other place where InfoText/InfoBackground are causing trouble, but it's also in Scrapbook X. On the Scrapbook Info Bar, the source URL is styled color: infotext, which actually works out especially badly because the toobar is ignoring the background-color: infobackground set in chrome://scrapbook/skin/overlay.css. (Possibly because it's overridden by the -moz-appearance: toolbar it picks up by virtue of being a toolbar?) This seems to happen in all cases (I can't recall the Info Bar's background ever being light yellow), but since infotext is normally dark it doesn't usually matter that the URL is being styled with it. However, on my system, it causes this:

[ferdnyc]

I thought I'd just update this report to note/show how this is handled in the original Gomita Scrapbook extension.:star:

As I half-remembered in my original report, that extension (which doesn't offer the handy "N results found" bar in the search results display) includes a "clear" icon in the search text field. Which is a clean way of avoiding this problem (and not incompatible with the result-count bar or its close [x]).

:star: – (This comes because I've switched back to Gomita's for the time being... not over this issue, IIRC, but over a problem where the Scrapbook X "Output as HTML" index pages won't load in my mobile browser, Dolphin for Android. They just load as a blank page. The ones generated by Gomita's extension load fine. I've been meaning to file a separate, detailed report about that, and will try to find time to do so. Debugging page-load issues with mobile browsers is so incredibly tedious, though, because they don't provide access to any useful debugging output or tools. For the moment, I just needed something that was working properly for me.)

[danny0838]

Besides the exit button, the "show in sidebar" button is also affected:

Unfortunately, we still don't have a nice idea for this issue currently. Icons with internal contrast is a good idea, but it doesn't look good for computers that already shown infoBackground in light color. We need a better artist for a good redesign.

[danny0838]

We decided to deal with this issue by adding a little white margin to the original icons.

Here's a stimulation of the dark-background case (using color #333). We can see that the expander and exit icons are invisible:

After this modification they are visible on the dark background:

When they are on the light background, their white margin is very insignificant, making they seem almost as same as before:

We'll apply this change in the next release if no other "contraindication".

[danny0838]

Done in 2958b821f899cb925e87d6df26b0ab6b27f6427a.