Thank you for reporting this. We can reproduce the issue, and are currently looking into it.

Hi @mcanouil, we've rolled out the fix for this. Please let us know if you still encounter any issue.

Thanks, it works!

@mcanouil Just wanted to update you that we have addressed one of your feedback items related to the display of the Issue Template. Now, you will see the chosen template in the Issue Creator and even have the option to change it while creating the issue, in case you change your mind.

Please let me know if it works as expected :)

Thanks, that's great.
It simplifies the workflow to switch between templates in case of miss-click.

@karlhorky thanks for flagging this again! We are aware of this issue but we are working through a large backlog of ideas and suggestions and this particular fix has not yet reached the top of the priority list. We do consider every piece of feedback that comes from the community so please keep highlighting anything that could be improved - it truly helps!

Oh nice. Thank you! We'll give it a try.

@boazreicher This feature has now regressed with the new "modal". It now always shows a modal even if there's only one issue template.

Thanks for reporting @MichaReiser, we'll take another look at this.

@MichaReiser this has been fixed now. Please verify.

Please verify.

Still doesn't work, can be seen eg. here.

@janbrasna Thank you for sharing your feedback and I'm sorry to hear you did not find our communications clear. It's one of the largest public previews in recent GitHub history touching many parts of the Issues experience and whilst we strive our best to communicate clearly, there is always scope to do better and we take your comments on board.

Regarding the scope of the release, it impacts virtually every part of the Issues experience. We focused on improving the performance and usability of the new issues experience whilst keeping it as similar as possible to the classic Issues experience that our users know and love. In addition, we have added three completely new features: sub-issues, issue types and advanced search.

I will respond to the two specific pieces of feedback in their respective discussion threads.

Oh no worries Tadas, I'm just probably not wired to navigating the discussions space for feedback purposes;) and failed to find the appropriate threads instead of submitting new ones. Hopefully it's relevant to what you've been working on — thanks for taking a look, appreciate what you do here!

we have added three completely new features

Great job with those major features, hat tip!

What specific improvements does the user suggest for better clarity in announcements or feedback threads?

Funnily enough, it's e.g. hard to tell apart content from GH staff, compared to others once it gets a bit noisier like here — so if this inquiry comes from a Hubber I'd be happy to elaborate a bit more if you're interested, nonetheless I see no sign that this particular user is "staff" to begin with.

(E.g. I'd like to unsubscribe from all other notifications from other comment threads, and only get pings for the reply threads on comments I've participated; and/or only staff responses instead of getting pings throughout the day of everyone adding to the feedback etc. — but there's definitely more, happy to share a user's PoV from the experience of several years using the discussion space as a landing page for feedback from GH UX preview opt-ins…)

"this editor" refers to the feature preview, I was trying to reference a chunk of code in a new issue in a private repo whilst this feature preview was enabled for me and the big textbox was empty

I'm also experiencing this on a public repo -- "Reference in new issue" flow is totally broken.

Previously, "Reference in new issue" would pre-populate some fields, especially copying over a perma-link to the highlighted code. That was the core appeal of that feature, otherwise I would just "copy permalink" and click the "New issue" button myself.

cc @akenneth in case the above got lost in the noise, this flow is still totally broken. Thanks for your efforts & triaging!

Thanks @MasterInQuestion, glad it's fixed!

Are there any additional pieces of information you believe should be included in the timeline or sticky header to make the interface more useful?

Hi. If I am hitting the right thread here ¹, let me add that the repository name might be dearly missing!?

Currently, on the new issue detail view that is delivered as a semi-overlay, there is no way to know if I will be commenting on an issue located in a private repository or not, which is pretty important to know.

Please fix!

@amotl we are working on adding this! Will provide an update when this change is out but should be early next week 👍

Thank you very much for fixing so quickly.

Accessibility Is definitely an area we value heavily, so I really appreciate your feedback here. I'll file this and relay it to the team.

Thanks! I inspected the recording frame by frame and noticed: the numbers fly in from above, or move up and down; their labels move up and down; also the pills changing size and position, and the labels moving from their default positions to accommodate for longer number values after they are loaded; also while numbers invisible the filter dropdown labels next to it move left and right. That's a lot of movement!

Thanks for the feedback @janbrasna! We are aware of this issue and I’ve logged your feedback against it.

We just shipped a fix for this @janbrasna - let me know what you think.

Hi @Timmmy-nlb, thank you for your feedback. I hear you (plural) and feel your frustration over this issue. I logged your feedback on our existing issue and will clarify what's our next steps here. 🙏🏼

THANK YOU - It works now!!!

Another minor issue that this video shows is the page title changes many times on a page load going through:

• Repo Issues
• GitHub - Where software is built
• Issues - Organisation/Repo

With the last being the one it settles on, and the useful one.

These are just side-effects of the client-side JS lazy-loading implementation which is always going to be flaky in the real world (say, not in the Gbit LAN many-core client dev/test environment). This is a critical piece of site functionality and enhancements should build on the existing functionality instead of replacing it.

@jfrost-mo This should now be fixed, could you verify? thanks again for bringing this to our attention! ❤️

The flashing is fixed, thanks!

The upon initial loading of the Issues list, the page title just goes through "GitHub - Where software is built" before settling on "Issues - Organisation/MyRepo", and only then if you do a hard reload (Ctrl-F5). However when changing page on the issue list the page title however now settles on "Repo Issues", after going through "Issues - Organisation/MyRepo". See the below video demonstrating this:

@jfrost-mo Thanks for the report, I added it to our backlog and we'll take a look at that 💯

Testing in Firefox after you asked it appeared to be fixed:

However when I went to edge to test there, and it was still small:

And going back to Firefox after a Ctrl-F5 it is small again:

I'm running Firefox 134.0.2 (64-bit) and Microsoft Edge for Business Version 132.0.2957.115 (Official build) (64-bit) on Windows 11.

My CPU/GPU is an 11th Gen Intel(R) Core(TM) i5-1145G7

Relevent HTML:

Compared with a working bar editing an existing image, this one is missing the InlineAutocomplete-module__fullWidth--X6eXo class.

thank you for the additional info @jfrost-mo - passed this on to the team investigating this.

This appears to be fixed today. I've tested in Firefox and Edge, after various page refreshes, and with and without a template.

@mcanouil thanks for the suggestion! Would you mind sharing an example of how you would use this?

For example, in some repositories my client has a workflow based on labels: priority, difficulty, type (bug, enhancement, etc.), component (codebase, analysis, etc.).
It's used to assign to GitHub projects amongst other things.
Each time a sub-issue is created, they need to go to each of them to add the exact same labels, some times with slight change for priority/difficulty.

To me, it makes sense to have an inheriting behaviour by default rather than having issues with no labels, milestones, projects even though they are created from one with.

Note: the issue was also there with the "item-issue" before the preview, so not really a new problem.

We've discussed inheriting meta data as we were building the feature, and it's something that's come up before. You mentioned labels, milestones, etc. Is that what you would expect? Or just solely labels?

Mostly labels.
Milestones make also sense to me in the sense that if you added the parent to a milestone, it likely means your sub-issues are also in that milestone, but I don't have strong expectations on milestones.

To summarise in a concise way:

Thank you for your feedback @eishiya! I'm glad you are enjoying the new advanced search!

We take your comments on board regarding the layout changes. There is always a tight balance between keeping things tidy and introducing additional steps to accessing functionality.

Another usability gripe from me: When opening a link to a PR/commit from an issue via the "{user} closed this [...] in {PR}" text, it opens in a new tab, whereas before it opened in the same tab. Other links in posts in issues also open in the same tab. For consistency, and because it's much easier to force a same-tab link open in a new tab than to force a new-tab link to open in the same tab in most browsers, I think these and similar links should open in the same tab.

@PLTytus thanks for reporting! should be fixed now ❤️

It is good now. Thanks for quick fix.

Already being a purely proprietary platform, GitHub always has a very sensitive place in my list of tools, and every action taken is something I use to re-evaluate for what purposes I will use GitHub over other platforms like Sourcehut, Codeberg, or self hosting forgejo.

I'm sure I am far from the only programmer who is constantly making these re-evaluations.

The website not working without JS enabled for the core functionality is one of those things that is hugely detrimental to my ability to ask others to collaborate with me on GitHub.

I know in the corporate world we don't talk about this a lot, but there is countless contributors outside of that who are taking their personal time to, out of interest and principle, build and share software. Functionality without JS enabled has a lot of importance for that.

@legobeat unfortunately, there are no plans to support a no-JS experience for Issues moving forward. Can I ask why it is important to you that the system works with JavaScript disabled?

@labudis Do you think there is any chance this will be resolved now that the feedback period is closed, or does this stand, meaning that the accessibility points laid out above are not at all of concern for GitHub? To me this looks like a significant shift from what we could read in the past about GitHub's supposed commitment to accessibility?

Hi @legobeat,

Thank you for sharing your concerns about accessibility with us—it’s something we take very seriously. We are continuously working to improve, and in the past three months alone, we’ve resolved 29 accessibility issues within the New Issues experience.

We truly believe it’s possible to provide an accessible experience, even within a system that relies on JavaScript. That said, we understand that individual needs can vary, and we want to ensure your voice is heard.

If there’s a specific accessibility issue that’s impacting you personally, please don’t hesitate to raise a support ticket. This will allow our team to investigate further and work toward a resolution that supports your needs.

Thank you again for bringing this up, and we’re here to help in any way we can.

@labudis you write that you have fixed 29 accessibility issues.

Where can I see accessibility related issues (opened and resolved)?

More generally, now that this feedback thread is closed, what is the best way to report other accessibility issues? (or other ones) What about the issues that have been reported in this thread?

@CyrilleB79 Thank you for your question. Unfortunately, we don't have a public list of all bug fixes. However, the best way to report any accessibility issues you are impacted by would be by raising a support ticket.

@CyrilleB79 I see what this is, it looks like the aria-label we generate takes the literal string from the title (including the <code> tags) - I'll log a bug here and get the accessibility folks to prioritise it for us. Thanks for the feedback!

There's an interesting additional consideration here - the screenreader won't tell you if it's a code block or not. I guess we could either accept this, or use to original text with backticks instead of the HTML tags: `ui. browseableMessage` - do you have a preference?

As a workaround, you could remove the backtick characters (`) from the title for now.

@CyrilleB79 just wondered if you had a few minutes to help us decide whether to filter out the <code> entirely or whether to display it with backtick characters?

@owenniblock sorry for not answering earlier.
IMO, totally skipping code block formatting in the aria label is acceptable, i.e. do not even keep backticks. In any case, the screen reader won't report formatting in focus mode; for this I need to switch to browse mode and use the suitable screen reader options.

Thanks @CyrilleB79 - I'll record this on the issue I've logged on our end.

@alexus37 the problem as I mentioned earlier is that we can no longer create issues by visiting https://github.com/aquasecurity/trivy/issues/new/ It simply redirects us to https://github.com/aquasecurity/trivy/issues/new/choose which is wrong.

Creating an issue from a discussion was just a workaround - I don't expect it to be the way to create new issues going forwards. If it is, it's highly clunky and requires additional work.

It's already been reported by @Haarolean here https://github.com/orgs/community/discussions/148713#discussioncomment-12576663 - disabling feature preview isn't an option anymore (at least for me) so we're simply stuck as we cannot create issues.

@simar7 Thanks for the additional info. I just checked the ISSUE_TEMPLATE/config.yml in your report and you have disabled blank issues therefore we redirect you to the choose page. If you want to allow blank issues you can flip that flag to true.

Yes but as a maintainer I should be able to create blank issues as I was before. To me this is a breaking change as previously I was able to create issue and not anymore.

@simar7, I've responded to @Haarolean in a separate thread but I think you are both experiencing the same issue.

The ability to create blank issues via the /new path when the blank_issues_enabled setting is off was a system defect. This allowed contributors to bypass the Issue Template configuration and create blank issues, which led to complaints about poor-quality issues. To address this, we have fixed the defect and now redirect users to the template picker instead.

That said, I understand the need for maintainers to create blank issues while still enforcing templates for contributors. I’ve logged your suggestion as a feature request, and our team will be considering a solution for this.