Discourse will not work correctly if you block individual Javascript APIs or features


#1

When you disallow sites to get/set your browsers history entries, this site is not very comfortable to use, since everything (clicking on site-local links) is done via XHR. In youtube for example, I can force the loading of a whole new page by blocking XHRs. Here I just get an error statement, if I try.

It would be great, if the site had a workaround for unavailability of XHRs.

I’m using Pale Moon. The relevant settings are:

  • browser.history.allowPopState
  • browser.history.allowPushState
  • browser.history.allowReplaceState

Bad enough, that those settings default to true, I just learned in Firefox you don’t even have a choice. That’s like [ADMIN: edit to remove a metaphor that was a little too graphic]… I better stop there.

Thanks. Have fun.

ADMIN: Edited to remove a graphic metaphor that didn’t feel quite right for our community - @jesse 2017-11-09


(Jesse) #2

That description is…a little bit more explicit than I’d like here, even though you stopped where you did. Would you mind editing it to stop…about six words earlier (or rephrasing it)?

What you’re writing about isn’t strictly XMLHttpReqeust, but browser history state. The best place to ask about this is on meta.discourse.org. If there’s a standardish feature we can enable to get you an optional ajax-free experience, I’d be happy to look at enabling it.


(Jesse) #3

Ok. Discourse’s policy is, roughly, “to be able to browse, it’s ok to disable Javascript. To be able to use the site fully, you must enable Javascript.”

This bit is explicit: “If you partially block JavaScript, that’s on you.”


#4

Sorry, if the metaphor was too expressive. What I wanted to express was, that it feels way too intimate to me to generally allow sites access to my browser tab’s history stack.
I personally think, that shouldn’t be a thing in the first place. Of course, that part regards todays internet rather than just Discourse.


(Jesse) #5

No worries. I understand where you’re coming from. I’m still trying to figure out the right balance here, but I’m definitely erring on the side of being a little more family friendly.

Discourse is the first forum software I haven’t hated. It certainly would be nice for them to have a no-js interface. I do understand being unwilling to support…custom javascript runtimes with some features disabled and I understand why you’re not a fan :wink:


#6

When I block XHRs, I don’t get a blank page, but

So I’ve got it a bit wrong. I do end up with a proper page request (see url bar), but the content doesn’t get loaded successfully.
Hm, strange thing is, when I open a link in a new tab it works, XHRs blocked or not, and when I open a blank new tab and paste the url it works, too. Just not, when XHRs are blocked and I try to follow a link within the current tab.

I guess, I have to further investigate. I’ll have a look at Discourse’s meta, too.

And thanks for your reply.

P.S.: Without XHRs I cannot send replies. I might need to add some monkey grease, it seems.


(Jesse) #7

I sometimes find site specific browsers useful for specific web apps.


(Gergely Nagy) #8

An alternative would perhaps be to just not use the web interface, and read & write through email. In my experience, that works remarkably well, and is easier to use than with half-disabled JavaScript.


#9

Hm, I rather leaning towards one general web-browser with hundreds of open tabs :slight_smile:

I didn’t know, you can answer to such a forum via email. Would have to setup my email client accordingly to end up with something structured and useful. Not my speed.

I tried to identify the mechanics behind the link clicking behaviour to put my own event handler in front of the queue to break the event handling chain or to replace the responsible function by an empty one vie userscript, but either my developer tools add-ons have become broken with browser updates or I seriously lost my skill. Need to find out how I did the diagnostics on the last site, I did it with. … Later maybe.