Can no longer click "Create Pull Request"

There are actually several buttons that seem to have stopped working. Both “Commit Changes” and the “Authorize[sic]” button I had to click to join this forum were disabled by default and never activated, but these can be bypassed by deleting the disabled attribute in “Inspect Element”. However, “Create Pull Request” is not disabled by default, yet does nothing when clicking on it.

No console errors, no network requests made and rejected, just nothing. There are two maybe relevant errors when loading the page:

Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://github.githubassets.com”). Source: call to eval() or related function blocked by CSP.  (unknown)
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://github.githubassets.com”). Source: (function(a,B,u,V){let n,m,b,w,H,y,S,G,e....

I’m on Waterfox 2020.08.1, and this used to work - I’ve made probably hundreds of PRs, the most recent one being just two days ago:

I don’t know what’s changed since then, but I can tell you it wasn’t my browser.

2 Likes

I just tried going about it a different way, via “New pull request” from the base repo, but in there no branches are listed.

From my fork (can only put one media item per post):

From the base (can only put one media item per post):

Turns out “Merge pull request” doesn’t work either.

Me too, I get a lot of 404 on the network requests tab.

This started happening on Thursday I think? Possible GitHub Javascript bug.

Microsoft Edge 44.19041.423.0
Microsoft EdgeHTML 18.19041

1 Like

I’m also experiencing a lot of problems like this in Waterfox Classic. I’ve contacted GitHub and they basically say “Tough luck, GitHub is only compatible with 4 browsers”.

Hey @Y-Less :wave:

Thank you so much for raising this and your other post:

And thank you to @tigerw and @endolith for also sharing your experiences.

Just based on these threads, I can sense some frustration around not only the experience, but the expectation of functionality with the tools/browsers that you’re using.

It is not an easy conversation after:

Tough luck, GitHub is only compatible with 4 browsers

…being the experience you’ve felt you had with our Support team.

The reality is, that we do have a documented list of supported browsers:

…and Waterfox is not one of them. We cannot guarantee smooth operation and 100% functionality with untested browsers.


Specifically speaking to:

This started happening on Thursday I think? Possible GitHub Javascript bug.

Microsoft Edge 44.19041.423.0
Microsoft EdgeHTML 18.19041

…the version of Edge that you mention is very out of date:

…and I would highly encourage you to upgrade your version of Edge, if you’re able to! However, I do understand if perhaps there are security concerns and requirements that may be imposed on you, to stick with an older version.

For EdgeHTML, I believe this is now entirely discontinued. Please, correct me if I’m wrong.

However, on Edge Version 86.0.622.51 (Official build) (64-bit) – I have been unable to reproduce any of the above mentioned problems, myself.

I also acknowledge:

I don’t know what’s changed since then, but I can tell you it wasn’t my browser.

…but I request that you attempt to reproduce this behavior on one of our supported browsers, that I’ve linked to above. If you are able to reliably reproduce this behavior in an up-to-date, and supported browser, then there’s much more ground to stand on from a support perspective.

This does not mean that we are not interested in your feedback, but that for now, we can’t commit to following up on issues in (currently) unsupported browsers.

Please submit feedback about your interest in using Waterfox on GitHub via our form, here:

These submissions go directly to our Product Management team for review and consideration. I encourage anyone in this thread, and anyone reading this thread who feels similarly, to submit your feedback. The more voices we have on a single request, the better!

I thank each of you again, and apologize for the frustrating experience you’ve noticed over the past ~week or so.

Please do followup with anything that adds to the story of this experience.

:bow:

1 Like

But why? Other websites don’t have problems like these, or browser whitelists. What are you doing that it only works in certain browsers? This is the website for the “largest community of developers in the world”, but you can’t make a button that does things when we click on it? :face_with_raised_eyebrow: These aren’t issues with fancy bleeding edge functionality, they’re just basic things like clicking a link and having content unfold from it. There are lots of other websites with much fancier features that work perfectly fine in Waterfox.

These submissions go directly to our Product Management team for review and consideration. I encourage anyone in this thread, and anyone reading this thread who feels similarly, to submit your feedback. The more voices we have on a single request, the better!

I’ve already submitted different issues there in January, February, August and another one last week, and the response is always “Too bad, use a different browser, issue closed”. :expressionless:

But why?

Welcome to the wonderful world of JavaScript :yum:

@nethgato, @endolith thanks for the replies, here’s what I’ve found so far:

404 spam issue

This seems to be caused by sourcemaps. The source map files GH delivers look something like

{..."file":"repositories.js","sources":["app/assets/modules/github/repositories/branch-filter-element.ts"...}

However app/assets/modules... aren’t accessible, probably they’re GH internal addresses. This would explain the 404’d requests to all the TypeScript files, I assume they are GH source code.

Interestingly Chromium/Firefox don’t appear to report these in the network tab, I guess they don’t make the sourcemap request until you actually try to open a minified JS file. In any case this was a red herring.

Possible cause

It looks like basically the entire site is driven by JavaScript; on Chromium I’m seeing lots of event handlers attached to various elements in the DOM:

Chromium event handlers

However on Edge I note most are gone, notably the click handler:

Edge handlers

This would explain why almost no buttons work. I’m still trying to figure out why.

1 Like

You’re awesome! Here are the other issues I’ve reported to GitHub Support:

On gist.github.com, clicking this does nothing:

image

Trying to add images to a Gist comment no longer works:

image

On editing an existing Gist, “Add file” button does nothing:

image

Sometimes the timeline bar across the top will load slowly and then stop loading:

(I’m not sure if that’s really a Waterfox issue, but in the support request they just said “use a different browser”.)

In Notifications beta [https://github.com/notifications]

  1. When I click “Select all”, nothing happens. This used to work a few days ago.
  2. When I click “Done” on a specific notification, the browser navigates to a blank page with URL https://github.com/notifications/beta/archive . If I go back, the notification has been correctly archived, but it didn’t go to a weird blank page in the past.

While trying to sign into this support forum, there was an “Authorize your account to access this thing” button that didn’t work

In a long Pull Request like https://github.com/scipy/scipy/pull/4607 clicking these “Load more” links doesn’t work:

It takes me to a blank page with URL https://github.com/_render_node/MDExOlB1bGxSZXF1ZXN0MzA2OTYzMTY=/timeline/more_items

1 Like

Hm. My best guess right now is GH had an internal change (some ?) weeks ago that bumped their minimum browser versions. For example I’m seeing references to window.customElements in their JS files, which is an API not yet supported by EdgeHTML/Waterfox. Since customElements returns undefined it probably causes some sort of cascade of errors that leaves none of the event handlers registered.

I also feel the list of supported browsers should be expanded, especially given transpilers nowadays can automatically polyfill unsupported APIs. Certainly, Edge remains supported by Microsoft, (and GH is owned by MS, so…)

Nevertheless and not without a touch of irony GitHub.com isn’t open source, so any fix will have to be up to GH themselves.

1 Like

If new features didn’t work on certain browsers, that would somewhat make sense - they’ve not been tested. But these are features that worked fine for years, then suddenly stopped. That means you broke something that previously worked, and clearly can work on those browsers. This is not some super bleeding-edge feature we’re talking about; this is clicking a button and viewing some text… Why does that need certain browsers? It should work in anything from Lynx up.

1 Like

OK, I just noticed another thing that no longer works:

image

That’s quite a serious issue - I now can’t add someone to the code.