Unable to type inside the input/textarea of the Lists' modals in repository pages.

[LittleOddBoy]

Select Topic Area

Bug

Body

The issue

This issue will appear in the modal when I'm in the repo page, you may ask what? let me show you.

So everything is perfect whenever I wanna create a List, in the for example Home page:

Or even, the Explore page:

But things go wrong, when ever I'm into a repository. For example, now I'm in the neovim/neovim repo, and it looks pretty cool for me so I decided to create a new List for this and the similar ones. I go for it and boom!

You may say "hey man u just need a click!", and well clicking on them is NOT useful and has no impact.

The helps

Recently, I dropped another discussion for this problem, and I've got some really gorgeous help from someone #136649:

But trust me, none of them works!

Environment

I've tried this in Brave and Firefox (actually the developer edition...) with a Windows 10 on my tiny laptop. I've deleted cache several times, I know what does ctrl + r will do, and I don't have any specific extension that blocks something. Oh important to mention that I've got a very interesting message inside the console log, when I click on the + Create List button and the modal shows up:

(The text inside the image: Autofocus processing was blocked because a document already has a focused element.)

That's all I know, by the way thank u for this beautiful feature, hope you do well=)

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[raelorne]

I get this too on the latest MS Edge. I noticed the Lists drop-down remains focussed even though the Create List dialog is shown.

As a workaround, you can press Esc to dismiss the drop-down in the background. It's then possible to click the text boxes in the create list dialog.

[LittleOddBoy]

So I will mark this as an answer, just because Lists are frequently used by all devs, so it may solve their issue as mine. But I think GitHub guys should do something about it.

A huge thanks to @raelorne

[johnnyasantoss]

I don't think this answers/fixes the problem at all. I'm seeing the same bug and the only way it works for be is doing this weird workaround, but this isn't proper UX.

[johnnyasantoss]

btw, it happens to me on the latest firefox on mac. Sorry for the spam

[LittleOddBoy]

hell yeah. it's not a very good fix if we want to consider the UX, but my first priority was to give a point to do something so someone that needs this feature a lot can have it with this even weird fix. but the problem could be fixed very easy if they just disable the focus of the previous element and move the focus on the newer one. however, as I said, I marked that just for solving others problem, for a while.

I hope GitHub guys consider this problem and prepare something for it.
special thanks to @johnnyasantoss to mention a very good point

[mollycarroll]

The high level reason seems to be that on repo pages, something else is already "focused" in terms of CSS hierarchy (I'm fuzzy on CSS so that might be a paraphrase). I made a screen recording w/ devtools showing the issue. I imagine it would be a straightforward frontend fix for the "repo main page" but it depends on the reason the repo page always has something "focused".

gh_ui_newlist_modal.mov

BTW, I'm on Chrome. Seems to be happening regardless of browser though.

[LittleOddBoy]

I appreciate your comment, this brings the idea to check the devtool for me (yeah, kina stupid that didn't check it first!). Definitely, this is a Front-end side issue. After checking the devtool, I've got some vision about how GitHub is managing the focus under different elements: via autofocus HTML attribute, which in my head is the major problem. I thought that they're handling this with JavaScript code, that why I didn't check the devtools...

Anyway. When every modal/menu things appear on the screen, they (the GitHub coders) bring an overlay thing (which is a :before) and then they put the element they want to add beside that overlay with an upper z-index which is kind of weird for the menus... However, there's no absolute autofocus attribute in any element inside the Lists menu. (I should note that I have not talked about anything in the Lists modal, yet!) But things goes weird when I see this:

There's an element called dialog-menu that has a weird dataset called data-focus-trap. If you want my opinion, it's something that is related to our case, to trap the focus. But you may say on what? well, from your video I saw an search bar for longer lists of Lists (oh gosh) that I think it's for that search bar.

The other sit would be for the inputs that has some hotkey things...

I firmly believe that if you handle the focus by your hand, the problem would be disappear.

And again, a huge thanks to you @mollycarroll

[LittleOddBoy]

Sorry but I'm not a native English speaker, could you please make your comment a little bit more clear?

[xdannyrobertsx]

I'm running into this as well on Firefox 130.0.1 (64-bit)

[Randygreene1]

Fix,tokens

[ResistanceIsUseless]

This is really annoying and happens for me in Safari 18 and Firefox 130.0.1 on Sequoia. Please fix it.