Content of commits and many other lost without javascript

[mowgli]

Select Topic Area

Product Feedback

Body

Since some weeks github does show only the main page without Javascript but after clicking to one of the links, the content is gone.

This is especially an impact for people with some limited abilities but also for people seing javascript as security problem.

The change is done for no need. This was one of the important features for me in the past that kept me on Github. Now it is gone and Github joined company to unusable git solutions out there.

[skiks]

Hey mowgli,

I totally get where you're coming from. I've noticed the same thing with GitHub lately, and it's a bit of a bummer. I don't have any control over what GitHub does, but I can share a few things that have helped me out.

JavaScript Whitelisting: If you're worried about security, there are browser extensions that let you pick and choose which sites can run JavaScript. That way, you can keep it on for GitHub and off for other sites.

GitHub API: If you're okay with doing a bit of coding, the GitHub API is pretty handy. It lets you access a bunch of data from GitHub, including commit content. You can use command-line tools like curl or httpie to interact with the API, so you don't have to enable JavaScript in your browser.

Git Clients: There are a bunch of Git clients out there that let you view commit content and other repo data without needing to use a web browser. Some examples are GitKraken, Sourcetree, and the good old command-line git tool.

And don't forget, you can always let GitHub know what you think through their feedback form. They might not realize how these changes are affecting us users, and your feedback could help them make better decisions in the future.

[mowgli]

Am Di den 1. Aug 2023 um 13:04 schrieb skiks:

And don't forget, you can always let GitHub know what you think through their feedback form. They might not realize how these changes are affecting us users, and your feedback could help them make better decisions in the future.

Well, I searched for it but was unable to find it. Regards

[skiks]

https://support.github.com/request?tags=dotcom-footer

[q3cpma]

Same here, markdown and folders rendering (traditionally served as static files) not having any fallback without JS is extremely damaging to the usability and performance; long commit being truncated/JSified is an old "problem" that isn't as important. Even more when GH provides nice Atom feeds whose contents might be read in simple browsers that only handle HTML+CSS.

Please provide a solution, even something akin to Reddit's old subdomain would work.

[ghostinhershell]

Hey @q3cpma, really appreciate you chiming in here. I'm routing this feedback to our Web and Accessibility teams and want to make sure that I have all of the details I need. Can you provide an example of specific page(s) where you're seeing this issue?

[ghostinhershell]

Hey @mowgli 👋🏾 thanks so much for reaching out here with this feedback. I'm routing this feedback to our Web and Accessibility teams and want to make sure that I have all of the details I need. Can you provide an example of specific page(s) where you're seeing this issue?

[DanH42]

Tagging @ghostinhershell just in case you didn't see the mowgli's response earlier.

This issue affects nearly every page on GitHub. For example, here's https://github.com/github/.github/blob/main/profile/README.md:

The parent directory listing, https://github.com/github/.github/tree/main/profile, looks exactly identical to the screenshot above. The only way to tell the difference between the two pages is to check the address bar.

Before the new IDE view was fully rolled out, these pages loaded fine everywhere, regardless of browser version, settings, or uncaught script errors that made it into production. Even just being able to easily access the raw view for a file would help a bunch, but the button to get there is also now rendered using Javascript, which makes getting there a lot more difficult.

[DanH42]

Another lingering accessibility issue that was brought up by multiple people while this change was still an optional beta is that with Javascript enabled, the new "code editor posing as a viewer" swallows nearly all keystrokes, rendering most keyboard shortcuts for navigation useless. Instead, it displays an insultingly obvious message:

Some browser native navigation, like using Home/End to scroll to the top/bottom of the page, is also broken by this update. I'm personally much more inconvenienced on a daily basis by this specific regression than the letter-key shortcuts, and a JS-free code view would by nature also not interfere with this sort of basic functionality that I expect to be consistent across all pages.

[mowgli]

Hi, Am Mi den 6. Sep 2023 um 23:28 schrieb Sarto Jama:

Hey @mowgli ???????? thanks so much for reaching out here with this feedback. I'm routing this feedback to our Web and Accessibility teams. Can you provide an example of specific page(s) where you're seeing this issue?

It is all over the place. For example, the main page of https://github.com/BestImageViewer/geeqie shows the readme below. But if I look at a file https://github.com/BestImageViewer/geeqie/blob/master/version.sh, it doesn't show the content anymore. And when I go to a sub dir, https://github.com/BestImageViewer/geeqie/tree/master/doc, it doesn't show the content at all. Or, for example https://github.com/BestImageViewer/geeqie/blob/master/CODING.md. By the way, some days ago, even on the main page, https://github.com/BestImageViewer/geeqie, the dates of the files starts to overflow to the right side bar. Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen ***@***.***> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C

[ghostinhershell]

Thank you for your responses here @mowgli and @DanH42. I'll follow-up with our Web and Accessibility teams and update you here with their findings.

[ghostinhershell]

Hey there @mowgli, @DanH42, @q3cpma and @skiks 👋🏾

Server-side rendering (SSR) flag has been enabled for each of you. Can you take a look, click around and let me know if this has resolved some of the usability issues that you've reported here?

[DanH42]

First off, yes, this does seem to resolve the most significant problems caused by the recent updates. I'm able to view nearly all the content on pages, which wasn't the case before. Some content is still missing, like the most recent commit message above a file on /blob/ pages along with a lot of the right sidebar content on a repo's homepage that still wants to lazy-load for some reason, but the most important stuff is now usable. Pages also load slightly but noticeably faster, which is nice.

It's a little tricky to do a more thorough test, because I normally use GitHub while signed out, and the devices where I have the most trouble with the increased Javascript requirements don't have access to my password manager (nor should they), so I can't sign in on them. Also, when I sign now I'm getting forced over to the awful new low-contrast all-white UI update that I used to be able to opt out of, which makes navigating GitHub in general more difficult, and everything feels wrong whether it's actually broken or not. The older and more intuitive navigation is still available when signed out, but then I stop getting usable HTML again.

The most noticeable changes in behavior seem to be on the code viewer-editor page. With Javascript disabled, my display preferences are disregarded and the code view spans my entire browser window instead of staying confined to the main center area of the page. I'm not a fan of that, but it's easy enough to fix on my end with some custom CSS, which I'm going to need to spend a bunch of time rewriting anyway now that the new navigation can't be turned off anymore and a bunch of my custom scripts/styles have broken again as a result. Something else that would be nice to get working is the "Code" button on files that get rendered automatically, like .md files. However, now that the page loads more than not at all, the "Raw" button is a real link that's just one click away (for now, at least), which is usable as a workaround. Similarly, the "Blame" button doesn't work either, despite functioning mostly like a normal link to another page (except for working correctly with Ctrl+click or middle click, or being able to tell by hovering that it will take you to another page). Once I'm on either of those pages, I can disable JS and the page still loads fine. But that's not how I normally use a website; I either have working JS or I don't, and when I don't I'm generally unable to load it even if I wanted to, either for security reasons or because I'm using some non-Chromium browser that doesn't support all the new JS syntaxes GitHub has started using (most commonly object?.property, which is a syntax error in older browsers, breaking all other code in the script file).

There's one big improvement that I assume came as an unintended side-effect, which is that browser-native page navigation now works correctly on the code view page, because without Javascript it returns to actually being a code viewer instead of a bloated IDE in read-only mode. That means my Home/End keys work as expected, rather than simply moving a useless cursor left/right in an editor that was never going to let me edit anything anyway. This is huge, and kind of makes me want to use GitHub with Javascript disabled all the time -- the parts that aren't completely broken are mostly better than they are with JS enabled.

[ghostinhershell]

Hey @DanH42, thank you so much for the detailed feedback here! I'll share this with the team 👍🏾

[q3cpma]

On Thu Oct 12, 2023 at 4:30 PM CEST, Sarto Jama wrote: Hey there @mowgli, @DanH42, @q3cpma and @skiks 👋🏾 Server-side rendering (SSR) flag has been enabled for each of you. Can you take a look, click around and let me know if this has resolved some of the usability issues that you've reported here?

It works, here but only if logged-in, of course. Which defeats the point in my case, the switch to SSR should be done either with an URL query parameter or when lack of JS is detected on the client (or both). The dynamic JS sidebars are still present, even if doing nothing more than wasting space, though.

[ghostinhershell]

Thanks @q3cpma, I'll pass this feedback along to our web services team as well.

[tschmidtb51]

I would like to echo the issue: Javascript is filtered in (most) government networks. So we can't even view the content of Github repos from our machines anymore.

[chocmake]

Noticed today that a particular repo I came across doesn't load the Code tab's file list view or readme if Javascript is specifically disabled on githubassets.com, even if JS is enabled on Github.com per se.

I'm not sure what's special about this repo since other repos' Code pages function just fine without Javascript enabled. Just wanted to bring this to attention and this seemed the most recent, relevant topic.

---

Edit: apparently it's an issue specific to a particular browser addon's method of handling Javascript, since tested using uBlock Origin's Javascript toggle method in both Firefox and Chromium and the issue isn't present (file list and readme loads fine).