DisucssionTools quick topic adding does not fallback when javascript is not running
Closed, InvalidPublicBUG REPORT
Actions

Assigned To

Authored By

	Xaosflux
	Jul 18 2022, 5:21 PM

Description

Steps to replicate the issue (include links if applicable):

Go to a project that has DisucssionTools
Enable "Enable quick topic adding" and optionally "offer to add a new topic" subsetting in editing preferences
Use a browser that does not have javascript working

What happens?:
Attempting to start a new section or start a new discussion on a new page results in no action.

What should have happened instead?:
Fall back to the non-js powered editor

Software version (skip for WMF-hosted wikis like Wikipedia):
WMF production

Other information (browser name/version, screenshots, etc.):
Originally reported on enwiki in https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1099028171#New_section_tab_not_working_when_JavaScript_is_disabled

Event Timeline

Xaosflux created this task.Jul 18 2022, 5:21 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 18 2022, 5:21 PM

I'm not sure if this is a bug in implementation (that fall back should occur) or design (that a dead-end workflow is present).

Expect this is being noticed now after this setting was forced-on for users.

Perhaps the message discussiontools-preference-summary should warn that these tools may be breaking if javascript is missing? (e.g. https://en.wikipedia.org/wiki/MediaWiki:Discussiontools-preference-summary where this is presumptive right now)

No, they should just work. Since the New Topic Tool is available to logged-out users as well, who can’t edit their preferences, forcing non-JS users to turn off a preference is a no-go.

As a quick and dirty solution, there could be a banner that points to the &dtenable=0 URL (this always loads the non-JS editor), hidden when the <html> element has js class. However, this is a quick and dirty solution, which is useful in case nobody comes up with a better idea quickly, but we shouldn’t force users do extra clicks in the long term.

With JS disabled, it does seem to fall back correctly? I click "add topic", and it goes to the non-DT new-section editor (without all the JS-powered toolbars, etc).

Here's a very quick video showing what I did: https://www.youtube.com/shorts/wJdn3ce6iTc

Does this fallback use <noscript>? The original reporter noted that they use NoScript, which by default ignores <noscript> tags, if I remember correctly (because many sites abuse them).

If this is only breaking when clients configure browser extensions that break things, I can't really blame us for it (may split of a FR to improve that preference label).

I think that it'll do noscript depending on your configuration -- if you've got a VE-based editor mode selected for source edits (as I do in that video, so the URL I'm reaching is https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&section=new&veaction=editsource), it'll take you to a placeholder page that'll attempt to start up the 2017 wikitext editor... and includes a <noscript><meta http-equiv=\"refresh\"> block that redirects you to the most-basic source editor.

However, as e.g. a logged out user on that wiki, "new section" goes to https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=edit&section=new which immediately gets you the basic editor without any <noscript> involved at all.

@Xaosflux Might be worth checking the reporter's beta features config and seeing whether they've got "New wikitext mode" enabled -- if so they're simultaneously running NoScript and explicitly requesting a JS-required editor, which seems like a poor combination even if we can fall back sometimes.

Rummskartoffel subscribed.Jul 18 2022, 7:21 PM

The tab used to work fine without JavaScript, but the underlying code must have changed recently and broke it for no-JavaScript editors.

Incidentally, the reason for this is that with "quick topic adding" enabled it changes the behavior of visiting that URL. It makes action=edit behave as if it were action=view because it expects to be able to show the regular talk page with the new topic tool. (And the place that generates the links has no way of knowing whether javascript is enabled on the client.)

I do think that we shouldn't do too much to adjust for people running extensions that're deliberately breaking page behavior. <noscript> exists for a reason, and we're using it correctly. If you're running something like NoScript you should expect that some pages will be broken by it, and might need you to configure per-site settings. In this case, I believe that the user could easily set a custom trust-level for wikipedia that enables noscript.

Seeing if any other comments on this, before just closing as invalid (is breaking client-side based on client extensions)

In T313246#8086424, @Xaosflux wrote:

Seeing if any other comments on this, before just closing as invalid (is breaking client-side based on client extensions)

@Xaosflux: do you think this ticket can now be closed?

• ppelberg moved this task from Backlog to Triaged on the DiscussionTools board.Jul 28 2022, 3:13 PM

Declining, the only user story for this so far is: a user installs and configures a browser extension that interferes with served javascript. "Don't do that"

Xaosflux closed this task as Invalid.Jul 28 2022, 4:15 PM

Xaosflux claimed this task.

DisucssionTools quick topic adding does not fallback when javascript is not runningClosed, InvalidPublicBUG REPORTActions

Description

Event Timeline

DisucssionTools quick topic adding does not fallback when javascript is not running
Closed, InvalidPublicBUG REPORT
Actions