CSS Regression from #7506 ?

[x12Mike]

For me, the issue within https://github.com/laurent22/joplin/issues/7506 is reoccurring within the latest pre-release. It had been resolved at one point but when I downloaded 2.11.9 and ran it, I noticed the same behavior in the notebook list.

I believe the PR for the issue is this? https://github.com/laurent22/joplin/pull/8126

Environment

Joplin version: 2.11.9 Platform: Linux (Using AppImage) OS specifics: Linux Mint 21.1

Steps to reproduce

1. Mouse over the notebook list and names alter between readable and unreadable

Describe what you expected to happen

All notebooks in the list should be readable at all times.

[laurent22]

@cas--, do you think your change could have caused this regression?

[cas--]

Hmm anything is possible :)

~Not seeing an issue here, is there any userchrome.css defined?~

So I setup some icons and all caps text and there a regression, not as much as OP, very strange...

[cas--]

It seems to be a subtle difference in the folder structure and icons can result in regression :disappointed:

@laurent22 When do you plan to release? I can have another look at improving the workaround

[laurent22]

I'd like to create a fixed release relatively quickly. Do you think it can be improved, or we simply revert? The previous fix wasn't perfect but at least it seemed to work consistently.

[cas--]

The issue is related to the note count label opacity coming into play. I thought that it would be tricky to fix but it turns out that we can replace opacity with text color opacity for the label instead.

A userchrome.css workaround:

.note-count-label {
  opacity: 1 !important;
  color: rgba(255,255,255,0.5) !important;
}

@x12Mike can you confirm this works for you?

For the actual fix I still need to get dev env setup to verify but this is the change:

packages/app-desktop/gui/Sidebar/styles/index.ts
@@ -100,9 +100,8 @@ export const StyledExpandLink = styled.a`
 `;

 export const StyledNoteCount = styled.div`
-       color: ${(props: any) => props.theme.color2};
+       color: ${(props: any) => props.theme.colorFaded2};
        padding-left: 8px;
-       opacity: 0.5;
        user-select: none;
 `;

[cas--]

@laurent22 Created a PR, although was quite tempted to revert to original 'opacity 1' workaround :smiling_face_with_tear:

[x12Mike]

Hmm anything is possible :)

~Not seeing an issue here, is there any userchrome.css defined?~

So I setup some icons and all caps text and there a regression, not as much as OP, very strange...

Just to update, I don't have any custom CSS defined. As I use Joplin across multiple machines tho, I have 2.11.9 installed on one of my Windows boxes and the issue doesn't persist. The Linux Mint laptop I took the screenshot on is now back to 2.10.19.

Is this perhaps a Linux only issue? Or maybe an issue of different Joplin versions across different platforms? I'm not privy to the innerworkings of how Joplin maintains Notebook and Icons across platform but maybe that comes into play?

My apologies if none of the above helps. These are just my hypotheses and figured the added info may be relevant.

[x12Mike]

The issue is related to the note count label opacity coming into play. I thought that it would be tricky to fix but it turns out that we can replace opacity with text color opacity for the label instead.

A userchrome.css workaround:

.note-count-label {
  opacity: 1 !important;
  color: rgba(255,255,255,0.5) !important;
}

@x12Mike can you confirm this works for you?

I can confirm that on Mint with the laptop I was using, the above modification to the userchrome.css does appear to have fixed it.

[cas--]

It's a known Linux Intel GPU issue with Electron/Chrome. I tweaked the previous workaround since it was working well with me but it didn't quite resolve everything as you reported, which is good to catch before a release 🙂

Thanks for confirming the new fix will work