You have a CSS rule on .Title-module__heading--upUxW of font-weight: 500;. This isn't enough for fonts with only "regular" and "bold" variants to flip to the "bold" variant – you need to use at least font-weight 600 for that ("bold" is 700).

+1

@ndren @david-crespo @PatchMixolydic @Siedlerchr @markerikson @sersorrel @arthurscarpin this should now be fixed, thank you for your patience and involvement! ❤️

Ok , now i have something to do when I back i wll take a pictures for where can this page lead you!!
Excuse me

@samlh @jcready Thank you for reaching out, I believe we addressed the issue that caused this. Are you still experiencing this?

Sadly, it just happened again for me a moment ago on Firefox desktop, after a rather long streak of not reproducing. Unfortunately, I'm not sure what help I can give tracking it down given how rarely it happens...

@alondahari

Ah, good(?) news - I was able to repro it a 2nd time by:

• Navigate to https://github.com/rust-lang/rust/issues from a different issue
• Select Hang: type_alias_impl_trait rust-lang/rust#132797
• Hover stuff, use github in other tabs, etc
• Use mouse back button to go back to the issues list

Expected: I can see the list of issues
Actual: The list of issues is missing (similar to screenshot above)

EDIT: calling this the blank issues list issue

However, after trying similar steps again, I can't repro a 3rd time...
EDIT: See repro notes in my next comment

I did notice a different issue when trying to reproduce, though:

• Navigate to https://github.com/rust-lang/rust/issues
• Click Closed to switch to the list of closed issues
• Click one of the closed issues ([ICE]: error performing operation: fully_perform rust-lang/rust#132691)
• Use mouse back button to go back

Expected: The url and input box contains "state:closed", and I should see the list of closed issues
Actual: The url and input box contains "state:closed", but I see the active issues list instead

EDIT: calling this the active instead of closed issue

Sadly, this issue also can't be reproduced easily

Seeing this on Firefox 132.0.1 (64-bit) on Windows 10
Potentially relevant extension: Ublock Origin 1.60.0

And another repro of the blank issues list issue (repro no.3):

when in this state, I can go forward to go to the issue again:
rust-lang/rust#132759

And press use browser toolbar back button or mouse back button to see the blank closed issues list:
https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aclosed

... as many times as I want

Opening the dropdown menus work just fine:

(From previous repros: refreshing or going back from the issues list to the previous page unsticks things again.)

There are no errors in the browser console.

From the browser dev tools:
2024-11-08 - samh - saved dom from devtools.html.txt

EDIT: The trick for reproducing the blank issues list issue seems to be leaving the browser open on the issues list for a while (go off and do something else), and when you come back, click an issue, then use the browser back button.

It appears to happen more often than not that I hit the issue when leaving the tab alone for a while and then come back to it.

Steps:

• Open an issues list (e.g. https://github.com/rust-lang/crates.io/issues)
• Navigate to some issues and back for a bit (not sure if needed)
• Leave the tab alone for some time (5 minutes?)
• Click on an issue
• Use the browser back button

Browser info:

• Firefox 132.0.1
• Potentially relevant extension: Ublock Origin 1.60.0

Related(?) issue (EDIT: calling this author filter not removed on back button issue)

Selecting an author from the authors dropdown successfully loads their issues, but pressing browser back then does not return me to the full list:

• Open https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aclosed
  • NOTE: initial repro based on duplicating the tab reproducing the other issue (blank issues list), but also able to repro when opening a fresh tab and pasting in the link
• Select Author, select the first user in the list
• Notice the issues list for the author shows up (https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aclosed%20author%3AaDotInTheVoid)
• Press back
• Notice the browser url updates correctly back to https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aclosed

Expected: the complete list of closed issues is displayed
Actual: the filtered list of issues for the previously selected user is still displayed

Unlike the blank issues list issue and the active instead of closed issue:

• This issue I can repro every time
• Pressing forward and then backwards again fixes things

I'm hoping some part of the info above will be helpful for tracking down the issues - please let me know if there's any other info that might be helpful

Thanks for looking into this!

EDIT to add: On a positive note, the overall experience is quite nice, even with the occasional hiccups around browser back/forwards - thanks for the hard work!

@samlh thank you for the detailed report 🙏🏼

• blank issues list issue: I was able to replicate and we'll investigate!
• author filter not removed on back button issue: we have work lined up that will fix the issue
• active instead of closed issue: We were also not able to replicate this one, but we'll keep our eyes peeled. Our fix for the back button issue will probably be a cleanup of navigation handling for the index page, so hopefully this one will also be taken care of.

The search bar matching the background color is the biggest one for me.

@gameboycjp curious about your feedback, do you feel the search bar isn't highlighted enough in the new UI?

@sunnyi101 Yeah. Maybe my eyes are bad, but it looks like the inside of the search box is the same color as the background.

Yeah, this input box definitely needs a different background color:

Yes. The most confusing thing is that the line just below the search bar is highlighted (open, closed, etc.) which makes the search box less visible.

Agreed, also edits are shown in the far right making it difficult to identify them.

New edits UI:

Old edits UI:

While the new UI aligns with the edits identification in the GitHub discussions UI here, I think it is better in both places to make the comment/thread better identifiable that it was edited.

Thank you both for the feedback! We are currently working on some fixes for these 👍

Having the avatar outside of the comment "bubble" made it much easier to find related messages by the same user.
Having it inside the title now is the main friction I experience with the new design.

Also, since the avatar was outside of the comment bubble, it was on the same relative position to the "add comment" section, which made it look more integrated to the rest of the page.
In the new design the "add comment" section feels more disconnected from the rest of the page.

Thank you for the feedback!

What's broken on mobile?

Thanks so much for the feedback! 🙌 @egorikftp Would you be able to share the OS and browser from your desktop screenshot? We can see some unintended alignment/spacing

@peterloveland
macOS 15 and Google Chrome (Version 128.0.6613.138 (Official Build) (arm64))

I find out that the reason of this issue is this plugin 🙁

https://chromewebstore.google.com/detail/github-emoji/ecldoejhjmekemajgjjalfgkhgmfjgcl

Yes. I got it

    But the Discussions' implementation would make most people unable to notice which:
    https://github.com/orgs/community/discussions/139935#discussioncomment-11046492

@matthchr we added back the timestamp with sort:updated-asc, we are currently working on including this option in the sort quick filter.

As of yesterday this appears to have flipped. Now when you sort by last updated you only get the opened date/time, and not the date/time when it was last updated.

@ianjoneill you're right! That's a regression from recent work we did probably. We'll get a fix out asap!

@ianjoneill Thanks again for the heads-up, this is now fixed 🙏🏼

Thanks for the feedback - we are looking into how we manage this with both sub-issues and checkboxes at the moment and will make sure to take this into account

Would be great if sub-issues had a checkbox for whether to show them in the main list or not. I like the idea of subdividing larger issues but I feel like I'm forced into repeating the title of the parent issue because it only makes sense in that context, at which point it's just polluting the main issues list.

'Saved views' (with a customisable default) is somewhere we would like to go in the future which could help here?

'Saved views' (with a customisable default) is somewhere we would like to go in the future which could help here?

That would be definitely be nice!

@xlenstra Thank you for the feedback. We will look into this!

Thanks for the feedback @nakoyasha - how are you finding the loading in general? The performance of the /issues page is still something we are working on

Aside from that, I think it's okay (haven't tested it with a ton of issues yet so can't really say)

    In general: Less verbosity = More readability
    Form follows function.
    All elements must serve real purpose; or they shouldn't exist.

    But beware over-reduction alike:
    https://github.com/orgs/community/discussions/139935#discussioncomment-10851722

    Also this doesn't mean thoughtlessly clipping everything disregard.

    See also:
    https://github.com/orgs/community/discussions/139935#discussioncomment-10931953
    https://github.com/orgs/community/discussions/139935#discussioncomment-11002547
    https://github.com/orgs/community/discussions/139935#discussioncomment-11103944

We are working on a change for this

Came here to also comment on the 0 comment counters.

To add some thoughts that might help with why this feels like a bad change: it is very difficult to scan the list of issues and determine which ones have active discussions or not. On the old version, when there was no comments there was no icon so it was immediately obvious that there were no comments (if you knew that there was no icon). Now they are all visually similar.

An alternative might be to recolour the icons/text when there are no comments to a more washed out colour (that is to say closer to the background colour). This way they are visually distinct even though they are both now shown.

I see this has been fixed, thanks :D

Yes, we just fixed this. Thanks for raising this issue!

Thank you for the feedback!

Good spot - we will get that fixed

Fixed!
Thanks again for reporting and helping us provide a better experience! ❤️

Thanks for sharing @DavidVentura - we will take a look

Hi @DavidVentura, thanks for sharing this feedback! Couple of follow-up questions:

• Are there other issues you're looking for in that repo that include upgrade in the title or is it in the body of the issue?
• Are the issues you're searching for open or closed issues?
• Are the issues you're searching for already added as sub-issues to another issue?

This will help us inform how to improve the search functionality!

• Upgrade is in the title, and yes there are more issues
• Open
• No

Initially the dropdown contained ~10 items (out of 21), and as I started picking them, each item got removed from the list, but a new item did not take its place; so the dropdown shrunk item by item until it was empty.

Typing #issuenumber on the dropdown does show the issue, containing upgrade in the title

I’m having similar issues. I’m looking at an issue (an “epic”), trying to add a sub-issue using “Add existing issue”. The issue I want to add is titled “Record a project:view:embedded event from analytics script”. The issue search seems to fail if my query has a partial word or if it has a colon. “project:view:embedded” was the first thing I searched for and it led me to believe there were no issues with that in the title.

Query	Screenshot
record a projec
record a project
record a project:
project:view:embedded
18453

Agreed. When there wasn't an "edit Issue types" button, I first looked in the repo settings but found nothing. After looking up and reading the documentation I learned that it was under organization settings, which makes sense now, but was not an option I would have tried on my own.

It gets noisier when I add many sub issues.

@jeremytenjo thanks for the added context. I believe you can collapse the sub issues, right?

@alondahari Oh I did not notice that. It would be awesome if we could collapse the activity list as well.

    Somewhat comparable to those in habit of adding random comments there... (i.e. "spam")
    The proper solution would be to "refactor" the commits. (not unconditional hide)
    https://github.com/orgs/community/discussions/4983#discussioncomment-10815730

It would be awesome if we could collapse the activity list as well.

I'd be open to this. But, personally, I like having the full Issue activity history in that sidebar since it tells more of the issue's story than the description/comments alone.

@mak448a thanks from bringing this to our attention, we'll take a look!

Ah damn, I did Ctrl+F for it but didn't find this comment somehow.

Unfortunately, one of the many UI problems in github issues is that long threads (I guess what constitutes "long" was defined when the Internet used modems) don't load all the comments and instead you get a message "134 hidden items, load more" in the middle of the list comments, where it is hard to find (it's not in the beginning!), and even clicking it doesn't open all hidden items - just a few more, and you need to find the "hidden items" link again. And again. And again. All of this makes ctrl-F useless in github issues, until you click on all those "hidden items" links repeatedly and then use ctrl-F.

It seems (see also their reply to my old report) they fixed it in a strange way. Now when I got to a search box with existing text and try to add an opening quote before some word and ending quote at the end - it works fine and doesn't get doubled. But if at the end I accidentally type a space and then a quote, then I get two of them :-) That's very odd, but for some reason they did it deliberately (and mentioned it in their reply) - I don't know why.

Ah, it seems their 'fix' also doesn't consider that - is something I might want to escape, so when I put my cursor before a - I still get two quotes for the price of one.

All of this makes ctrl-F useless in github issues, until you click on all those "hidden items" links repeatedly and then use ctrl-F.

I'm doing this right now to see if my suggestion has already been mentioned in this discussion. It's pretty tedious.

For additional context, this organization is small-ish and puts all Issues into a single GitHub Project board.

I suspect the full wizard functionality I mentioned is harder to generalize to organizations with many GitHub Project boards.