Affected versions

• Firefox 65.0.2
• Firefox Beta 66.0b13
• Firefox Nightly 67.0a1

Affected platforms

• Windows 10 (x64)
• macOS 10.12

Prerequisites

• Have an update for the browser made first, in order to trigger update data to show in Update History button.

Steps to reproduce

1. Start Firefox
2. Go to about:preferences
3. Scroll down to Firefox Updates in the General Section
4. Click on Show Update History...

Expected result

• The Details button is visible

Actual result

• The Details button is barely visible.

Regression range
I don't think a regression can be done, as the issue requires an update first in order to have an update history data shown.

This looks a bit dumb, but I'm not sure what the best solution would be. There are easy workarounds, and this is tertiary UI or something, so let's mark this P5.

Hi, I am willing to work on it, please assign it to me :)

(In reply to Jawad Ahmed [:jawad] from comment #2)

Hi, I am willing to work on it, please assign it to me :)

Well, how would you intend to fix it? I'm actually not sure how myself...

(In reply to :Gijs (he/him) from comment #3)

(In reply to Jawad Ahmed [:jawad] from comment #2)

Hi, I am willing to work on it, please assign it to me :)

Well, how would you intend to fix it? I'm actually not sure how myself...

Yes, you are right, it looked easy, i thought of changing some CSS, but i saw its getting the OS specific colors.

(In reply to Jawad Ahmed [:jawad] from comment #4)

(In reply to :Gijs (he/him) from comment #3)

(In reply to Jawad Ahmed [:jawad] from comment #2)

Hi, I am willing to work on it, please assign it to me :)

Well, how would you intend to fix it? I'm actually not sure how myself...

Yes, you are right, it looked easy, i thought of changing some CSS, but i saw its getting the OS specific colors.

Well, we could force the links in this document to have the same foreground colour as the rest of the text using color: inherit, that would at least make them visible? If we also underline them, that'll look reasonably like a link...

Another approach for fixing this issue could be using the same colors for hover and selection like it's in Options and Add-ons Manager.

(In reply to Jawad Ahmed [:jawad] from comment #10)

Created attachment 9050482 [details]
Link Color

This seems OK to me.

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #6)

Another approach for fixing this issue could be using the same colors for hover and selection like it's in Options and Add-ons Manager.

This seems like a bigger change. Perhaps something we want to do in the future, though it also seems like this dialog isn't very high on the priority list anyway (and that's probably right - it's not that usual to need to look at it).

Gijs, any reason why we can't make the items non-selectable with -moz-user-focus: none; on the richlistbox ? We could also add a bottom border to each richlistitem to make them look separated. I don't really see any reason to make the items selectable...

(In reply to Tim Nguyen :ntim from comment #13)

Gijs, any reason why we can't make the items non-selectable with -moz-user-focus: none; on the richlistbox ? We could also add a bottom border to each richlistitem to make them look separated. I don't really see any reason to make the items selectable...

The items are already selectable, so we're not "making" them selectable. Given we have a patch in hand that fixes the issue, and that this UI isn't actually super important, I don't think there's any reason not to take it. If you feel strongly that the items shouldn't be selectable, please file a follow-up bug and figure out the details (e.g.: if there's no focus on the richlistbox, how do keyboard users scroll the box?).

The items are already selectable, so we're not "making" them selectable.

I was saying that they didn't need to be selectable in the first place, but I don't feel that strongly TBH. Keyboard a11y is a good point.

Given we have a patch in hand that fixes the issue, and that this UI isn't actually super important, I don't think there's any reason not to take it.

Could we scope the current fix only to the updates dialog as you originally suggested? Right now, it's fairly easy to forget to remove this bit of CSS if/when we remove this dialog and it's quite unlikely that other richlistboxes are currently affected...

(In reply to Tim Nguyen :ntim from comment #16)

Could we scope the current fix only to the updates dialog as you originally suggested? Right now, it's fairly easy to forget to remove this bit of CSS if/when we remove this dialog and it's quite unlikely that other richlistboxes are currently affected...

Are there plans to remove the dialog? Also not sure I agree that strongly with "quite unlikely".

TBH, a more cohesive styling for richlistboxes probably wouldn't go amiss, but that would need to live somewhere else and is outside of the scope of this issue. Feel free to file a follow-up, but this has landed and I don't think the concerns you've raised warrant backing out this change.

https://hg.mozilla.org/mozilla-central/rev/7f3c70bce7e8