Double-scrollbar for editing

[AtmoFX]

Select Topic Area

Product Feedback

Body

When reading e.g. a md file, the vertical scrollbar of the page entirely controls the scrolling of text displayed on screen.

In comparison, when editing the file, there are 2 scrollbars:

• one for the edition area.
• and, because that edition area does not fit on screen, another for the page.

It is not possible to scroll throughout the text, be it in Edit or in Preview mode without moving both (which is not smooth to say the least).

Tested with Chrome, Firefox, Edge with any level of zoom.

Supporting screenshots (here, Firefox):

In edit mode, the last few lines won't appear unless the page scrollbar is moved.
.

In preview mode, the page scrollbar can go so low the entire edit area goes out of screen (I stopped midway for the below screenshot).

[ghostinhershell]

Hey there @AtmoFX,

Thanks so much for writing and sharing your feedback in the Accessibility community. I'll share this feedback with the Accessibility team so that they can take a look.

[AtmoFX]

Thanks for that, I will wait for the news then 😃

I suppose your accessibility team would figure it out without the following details but just in case..., I had forgotten to mention that unlike viewing mode where the header sticks to the top of the screen, the header in editing mode disappears with sufficient scrolling, rendering the following buttons/switches harder to access:

• Cancel/Commit change.
• Edit/Preview + Spaces/indent size/wrap.
  
  In the case of these buttons and on my computer at least, the amount of available scrolling in Edit mode is not enough to see them disappear, but the scrollbar Preview mode is.

[cehfisher]

Hello @AtmoFX - thank you for providing this feedback! We wanted to follow up on this reported bug. We were unable to replicate this issue in our review. Is this an issue you can replicate currently? If the original issue is resolved, could you please close this out? If it is not resolved, could you supply more detailed instructions to reproduce your issue and include screenshots and/or URLs, if applicable. Thank you!

[AtmoFX]

Hi @cehfisher, I can very much confirm this is still an open issue.

TBH, I do not know what to say: when I click on the pencil button (Edit this file) on any markdown file in my repository (https://github.com/AtmoFX/bigint/), be it the README file or any of the files I saved under the documentation folder, I get 2 scrollbars; I really do nothing special.

I have made a capture in the below file (from Firefox on my relatively new Windows11 computer so the scrollbars look different).
I hope this will illustrate how I'm really not doing anything special.

For size's sake, the capture is done on a Windowed browser but the very same thing occurs when I'm on full screen (be it only Firefox on full screen or the page on full screen with F11).

[cehfisher]

Thank you for the extra context and screen capture! I have sent your issue over to the accessibility team for further review. They should have an update for you soon.

[ericwbailey]

Hi, @AtmoFX. I'm a member of the GitHub accessibility team, and I've been assigned to help out with this report.

The double scrollbar treatment is by design. The second scrollbar's presence is to allow the editing area's content to be scrolled independently of the rest of the page's content. The editing area's horizontal size is user-resizable, so this provides a mechanism for a user to navigate past the editor if the user sets the editor to be taller than their browser's viewport.

I have also passed along your comments about the controls' behavior in the header in editing mode being different/more difficult to access to the appropriate internal teams.

Additionally, I wanted to say thank you for taking the time to report this. Feedback like this helps us both directly and indirectly improve the product.

[AtmoFX]

Hi @ericwbailey

On the good side, the interface was a bit improved since my report last year: I cannot reproduce having a huge blank area when in preview mode, even though that does not fully correct what is, IMHO, an accessibility issue.

TBH, there is very little I understood in your previous comment.

1. I get the header will be reviewed though but for the scrollbar, I usually understand "this is by design" as "we are not going to correct it" (I unfortunately work with that kind of service providers).
   Am I right to understand the above regarding the scrollbar?

2. The second scrollbar's presence is to allow the editing area's content to be scrolled independently of the rest of the page's content.
   I suppose the page itself can indeed be scrolled but the only thing it scrolls to on my computer is blank space.
   In particular, there is nothing under the always visible footer of the editor. Even the file tree has its own scrollbar when one is needed so the page scrollbar is not for that.
   -> As you noted, the read mode (with only 1 scrollbar) solves the problem by making the top of the reading aread sticky leaving the extra buttons always accessible + some more (button to return to the top of the page in 1 click).

3. The editing area's horizontal size is user-resizable
   I failed to understand that point.
   The file tree is resizable and collapsible, and that mechanically has an impact on the right part of the page.
   To my knowledge, the editing area which is not the right part of the page (it only resides in it) cannot, itself, be resized horizontally, nor do I see a reason why I would want to do that.

4. [...] mechanism for a user to navigate past the editor if the user sets the editor to be taller than their browser's viewport.
   I do not see any height change of the editor when changing its horizontal size (by expanding the file tree) but then again, I have not understood the previous point...
   Then, at the risk of repeating myself, I see nothing past the editor to navigate to.

Could you please provide more information about the points above?
After all, if the scrollbar has a special purpose I missed, which cannot be replaced by the tricks used for the reading mode, I'd probably want to know.

---

All in all, what I feel I get from having 2 scrollbars instead of 1 is:

• Making the interface inconsistent: the reading mode does not have the same scrollbars as the editing mode (the former is more convenient thanks to the sticky header with extra button)
• Providing no benefit: the page scrollbar scrolls to nowhere but blank space.
• Not balanced in terms of screen real-estate: the space where the cursor must be for the page scrollbar to be the one active is just a few pixels around the editor.
• Making some buttons less accessible: in preview mode, the page scrollbar allows for the Cancel Changes / Commit Changes buttons (they may be the 2 most important buttons on the page BTW) to go out of screen.

[ericwbailey]

Sorry if my reply was phrased poorly here. What I'm attempting to communicate is that we need a mechanism for scrolling the page in situations when the comment editor is taller than the height of your screen. Double scrollbars enable that.

[AtmoFX]

I may have gotten mysellf carried away on the page scrollbar yesterday. The issue up to your answer 2 days ago was not specifically about it but about having 2 scrollbars, and:

1. being unable to scroll to the bottom of the text in edit mode without scrolling them both down (but that part seems to have been changed since my initial report).
2. having reduced access to the Cancel changes / Commit changes since it is possible to scroll them out of screen (also improved since my initial report as it only occurs in preview mode now).

Right now, what I am reading is that you need to be able to scroll to the bottom of the editor.
I am not denying it but does this need two?

I am no web developer but I see 2 ways forward:

• AFAICT, the editor fits on screen right now, and cannot be made to grow. The page scrollbar exists because of the blank area (= botton margin?) under it.
  Compromising on the editor's size so that the bottom margin fits in the viewport would make the page scrollbar disappear.
  That would require the editor to show fewer lines, thus creating a bit more additional scrolling inside it but it looks like a good deal to me as I get to manage only 1 scrollbar (the editor's) and am guaranteed to keep the Cancel/Commit buttons on screen, even in preview mode.
• Alternatively, the edit mode could be made closer if not identical to the reading mode (area that shows all the text inside it).
  With a tall editor in which all the content fits without a scrollbar (it would need to grow with every new line/word wrap added to it and shrink when text is removed) + sticky div containing the file path and cancel/commit buttons (same as in reading mode), that would incur less compromises: 1 scrollbar (the page's), more of the edited text shown on screen (thanks to the page header would going out of screen) and less scrolling overall.

[AtmoFX]

@ericwbailey Any remarks on my last comments?

[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. ⭐

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[AtmoFX]

None of this applies and the question should not be labelled as dormant, whatever it means in practice.

[cehfisher]

Thank you for your feedback, and we genuinely appreciate your input. Our team has reviewed your request and we want to be transparent about our priorities. This particular request is not currently being actively worked on. This doesn’t imply that we’re not considering it in the future, but for now, it is not on our development roadmap.

We encourage you to check our public roadmap to get insights into the projects we are currently focusing on for the upcoming year. Please note that smaller fixes may not always be listed explicitly but can often be addressed when related work is in progress.

As a valuable GitHub user, your feedback in this Discussion space, accompanied by appropriate tags and examples, plays a crucial role in shaping GitHub’s development. While we can’t guarantee immediate action on every piece of feedback, rest assured that we are attentive to your suggestions and always striving to enhance the GitHub experience.

Once again, thank you for taking the time to share your thoughts with us, even if the particular request is not currently in active development. Your input is valuable and contributes to the continuous improvement of GitHub!

[AtmoFX]

Hi @cehfisher

You are in control in your roadmap and I trust you take accessibility issues seriously.

As my point was: an extra scrollbar leads nowhere, especially since I cannot reproduce a situation where the editor is too tall for the screen but hides important buttons (cancel/save), though for some reason only in preview, I feel the answer can only be:

• The extra scrollbar is removed.
• The editor's height is changed in edit/preview mode to match the edit/edit mode, in which the available scrolling is not enough to hide the important buttons outside the screen.
• The important buttons are sticky to the top of the screen.

Let me know the conclusion.