Discourse forums no longer allowing me to log in Topic is solved

[Tharthan]

As of a day or two ago, I have been unable to utilise the "Log In" button on Discourse forums. I have, therefore, been unable to log in.

Attempting to press the "Log In" button now results in no response.

I imagine that there has been a coding alteration.

[Moonchild]

I'm sure they will keep being a moving target and breaking regularly. Because Discourse obviously thinks shinies >> compatibility/accessibility

[VA1DER]

I'm sure they will keep being a moving target

I don't understand exactly what the modify http response plugin's filter is actually doing. Clearly a clever search-and-replace... is it blocking the running of a browser detect script, or editing the script's code mid-stream?
EDIT2: Ok, I've parsed the filter and can see that it is both blocking a browser detect script and editing the script stream to script operators that Pale Moon doesn't support. It's a very clever job of editing a script mid-stream to make it compatible.

Is there any way Pale Moon can simply support the necessary script operators? ||=, &&=, and ??= ?

[Moonchild]

Is there any way Pale Moon can simply support the necessary script operators? ||=, &&=, and ??= ?

We do (since 32.2.0). You're looking at old data.
See release notes: https://www.palemoon.org/releasenotes.shtml#v32.2.0

[mmouse]

I'm sure they will keep being a moving target and breaking regularly.

Sadly this happened this morning to me. A forum I use (forum.duplicati.com) updated to 3.1.0.beta6 (Discourse version from 2 days ago) and the 'Login' button has no effect (it don't even seems to visibly click), while openwrt.com at least gives an answer when clicking 'Login' - forum.openwrt.com is at 3.1.0.beta5 (about one month ago). Strangely enough, the 'Login' button can be activated on the Nvidia forums while they are using beta6.

[back2themoon]

Why would they even use a beta version is beyond me but hey, I guess they know better.

We do (since 32.2.0). You're looking at old data.

Does that mean the extension should no longer be required? In theory at least.

[Moonchild]

Does that mean the extension should no longer be required? In theory at least.

Correct, but you may now need it for their next beta shiny usage

Question by the way, why are people using beta revisions of discourse on production sites? I'd certainly report this new issue to discourse if it broke between beta 5 and beta6 -- they should be able to home in on the offending commit quickly enough.

[back2themoon]

Just tried all four related websites I use with the extension disabled, but unfortunately all display the "your browser is unsupported..." message. So, I guess it's still needed.

Don't know if all of these use a potentially buggy beta version.

[Tharthan]

Question by the way, why are people using beta revisions of discourse on production sites? I'd certainly report this new issue to discourse if it broke between beta 5 and beta6 -- they should be able to home in on the offending commit quickly enough.

Rather than bother to fix their bad code, aren't they more likely to say∶

"Wait a moment. Why are you using the Pale Moon browser? How are you using the Pale Moon browser to access Discourse forums? We don't support the Pale Moon browser, and in fact you ought to be being locked out from using any Discourse forums in the first place."

...Then perhaps they end up taking further adverse action, nullifying the workaround efforts that have been worked on to this point?

[VA1DER]

We do (since 32.2.0). You're looking at old data.

I was just looking at the filter and noticing the operators it was parsing and replacing. Thank-you for the update! I pulled out the ||=, &&=, and ??= operator replacement parts from the the filter and it still seems to work on older Discourse sites.

updated to 3.1.0.beta6 (Discourse version from 2 days ago) and the 'Login' button has no effect

So it seems there are three things that were going on.

1. Problem: Discourse uses a browser-detect script to detect browsers it doesn't like and gives a broken, unusable version of the web site to those browsers with a nastygram message.
   Remedy: Filter the browser-detect script
   Current Status: This seems to work on all Discourse implementations except for the forum hosted at meta.discourse.org, which can still detect Pale Moon
   
2. Problem: ??=, ||=, and &&= ECMAScript operators were unimplemented
   Remedy: Update the filter, or upgrade to 32.2.0
   Current Status: Since 32.2.0 no issues should be arising from these operators, and the relevant portions of the filter can be removed.
   
3. Problem: Unknown issue but possible ECMAScript interpretation incompatibility that is rendering the "sign up" and "login" buttons on the latest beta of Discourse sites inoperable
   Remedy: None known. The cause of the incompatibility is not yet known.

Surmise: Whatever unknown incompatibility is being seen in problem #3 is likely what is being used on Discourse's own meta.discourse.org site to detect unwelcome browsers, since that appears to be the only Discourse site that still can detect unwelcome browsers.

[Moonchild]

"Wait a moment. Why are you using the Pale Moon browser? How are you using the Pale Moon browser to access Discourse forums? We don't support the Pale Moon browser, and in fact you ought to be being locked out from using any Discourse forums in the first place."

...Then perhaps they end up taking further adverse action, nullifying the workaround efforts that have been worked on to this point?

In that case they can expect quite a bit of negative PR.

[VA1DER]

...Then perhaps they end up taking further adverse action, nullifying the workaround efforts that have been worked on to this point?

Blocking a browser because it genuinely lacks support for scripting elements used on the site may be valid. Blocking a browser because you just don't want that particular browser there is something called "tortious interference" and it's eminently actionable. It's not like all the individual Discourse sites are choosing to block Pale Moon. It's a decision that is being made for them by Discourse and being disted out. That's Discourse using it's position to interfere with Pale Moon.

That said, there appears to be genuine incompatibilities remaining.

After pulling out the ??=, ||=, and &&= replacement elements from Adoxa's filter, I did find some small issues with OpenWrt's forum. Re-adding those parts of the filter caused the issues to vanish. Could that indicate an issue with the implementation of one of those operators?

[Moonchild]

Re-adding those parts of the filter caused the issues to vanish. Could that indicate an issue with the implementation of one of those operators?

It could, but our implementation passes all functional tests that were performed on it, so that's very unlikely. It is possible however that the script causes other side effects that works around other scripting issues (it's a pretty blunt search and replace after all)

[adoxa]

meta.discourse.com uses cloudfront, so adding that to the host fixes unsupported browser; there's a missing bracket in a closest expression that causes a syntax error, which is what prevents sign up/log in.

Code: Select all

[["/discourse|^discuss|^community\\.|^forum\\.|cloudfront|resource\\.dopus\\.com/",["/browser-detect-/",["/.*/g",""]],["/discourse-[0-9a-f]{4}/",["(.d-modal-legacy\"","(.d-modal-legacy)\""]]]]

I did have to replace one ?? with ||, that might be the issue with openwrt. Can you tell me where you see it? Main page and viewing a post seems okay.

[VA1DER]

adding that to the host fixes unsupported browser

Thank-you. I didn't perceive they used cloudfront, which is why I couldn't get it to work.

issue with openwrt

The only place I have ongoing issues at OpenWrt now is in the message editor. Many of the toolbar items are non-functional:

• Quote whole post
• Bold
• Italic
• Pre-formatted text

[Tharthan]

Many of the toolbar items are non-functional:

• Quote whole post
• Bold
• Italic
• Pre-formatted text

Yes, but the situation of some buttons relating to formatting within the Discourse edit window not functioning is an issue that has existed for a long while now. It was mentioned earlier in the thread.

Since one can format one's posts manually, without using those buttons, it's hardly a dealbreaker. It's annoying, yes, but not something that can't be worked past.

Now, if the reply button weren't working, that would be a different story. There is no other way to submit a post other than by clicking the reply button*. Technically, if certain options are enabled for the particular forum that one is using, one might be able to make posts and create threads via e-mail message. However, not all Discourse forums have that functionality enabled, and I think that some of them only have it enabled for certain boards.

＊

Some time a while back, when there were compatibility issues even with the reply button, I tried using the hotkey for it in the hope that I could work around having to click on the actual reply button. However, the hotkey seems only to function when the reply button itself is operational.

I can put up with the formatting buttons not working. I, personally, have ceased to be particularly concerned about that particular bug.

[adoxa]

Fix the composer buttons/keys.

Code: Select all

[["/discourse|^discuss|^community\\.|^forum\\.|cloudfront|resource\\.dopus\\.com/",["/browser-detect-/",["/.*/g",""]],["/discourse-[0-9a-f]{4}/",["(.d-modal-legacy\"","(.d-modal-legacy)\"","document.execCommand(\"insertText\",!1,","this._textarea.setRangeText("]]]]

[adoxa]

The closest expression has been fixed (apparently Chrome/Firefox add it automatically).

[Moonchild]

apparently Chrome/Firefox add it automatically

Exactly why it's so difficult to have a standard web. In fear of breaking sites they just "guess" what the web dev meant instead of throwing an error/sticking to the spec.

[Tharthan]

Thank you, adoxa!

Everything is working better than ever with the new fix.