Some gadgets/scripts, like huwiki’s warning.js, do a two-phase processing, where the user initiates the workflow in read mode, enters some data (clicks a button, types some text etc.), after which the script redirects them to the edit mode, passing the data in arbitrary GET query parameters, and in edit mode it modifies the text box’s content according to the parameters. If DiscussionTools, unaware of these parameters, takes over the request, the second phase of processing doesn’t happen, which practically results in data loss (technically the data is still in the query parameters, but the user is unlikely to be able to extract from there). (This particular gadget always opens up the whole page for editing, i.e. it uses no section=new, but it could, and actually that would probably result in a better UX in a pre-DT world. For testing, you can simply insert a section: 'new' field in the object in lines 402–406; it results in the templates sometimes inserted at wrong places, but that doesn’t matter if you just want to test how it works together with DT.)

The gadget example is (essentially) preload. It's reimplementing its own take on it rather than using the actual preload parameter, I think, but...

Yes, it’s essentially a preload, but we can’t (easily) replace it with the preload= URL parameter: the URL parameter expects a page title, while this script passes an internal identifier, based on which it assembles the text on its own. I could assemble this in the read view (except that its length may exceed HTTP path limits), but I can’t pass the assembled message in a standard way, and there’s no page title that could be used in the standard parameter. (I could create one, of course, but that would limit its reuseability: it’s written in a way that it can be imported on any wiki, only a local configuration file is needed. If I rewrote it to use a preload parameter and created a template on huwiki for that, it’d be suddenly broken everywhere else.)

@Tacsipacsi Oh, sorry, I was relying on some implicit context from a meeting I was in: we'd discussed that for the preload case we should probably just fall back to the existing wikitext-editor experience for now. We'd also discussed creating a parameter that'll explicitly suppress the new discussion tool, which might be sufficient for a gadget like this -- just adding dtenable: 0 (or similar) into the object you mentioned would enforce its current behavior regardless of the user's settings.

Maybe we should just fall back to the existing editor when any URL parameters other than ?title=...&action=edit&section=new are provided. Right now (in the limited solution implemented in T277371: Take over gadgets/templates which create additional links to "Add a new topic") we only fall back if any of editintro, preload, preloadparams, preloadtitle is provided, and other parameters are ignored.

In T282204#7240673, @matmarex wrote:

Maybe we should just fall back to the existing editor when any URL parameters other than ?title=...&action=edit&section=new are provided.

As long as it only acts when clicking a link, it looks good, but once it will act on page load as well (T282205 will need acting on page load, won’t it?), allowing some basic, safe parameters would be useful: debug, uselang, useskin etc. They won’t be used by any gadgets anyways (at least I very much hope so), but they may be useful to debug the new discussion tool itself.

@Tacsipacsi Okay, you're correct again, I wrote my last comment quickly without thinking it through. So, right now I think that the new topic tool should only fall back to the normal wikitext editor if any of editintro, preload, preloadparams, preloadtitle is provided – and in a gadget like the warning.js one you linked, you could add &dtenable=0 to the query parameters to disable the new topic tool and fall back (this is what @DLynch proposed).

If you think something different would be better, say how it should work and I'll make it so. Right now, I think that this approach will cause the least amount of problems with existing tools and workflows, and any problems will be easy to fix on-wiki by just adding the parameter.

And now, let me talk about how do we actually take over the action=edit&section=new URLs.

I started looking int our options, and it feels like I'm doing something wrong, because it's more complicated than it should be. I think we have to take over the action=edit&section=new URL to display an almost-normal page view (with the new topic tool open at the bottom), instead of the normal edit form. If there's some obvious nice way to do it, or if we should take a completely different approach, I'm all ears.

I had one idea that did not work out:

• Use onCustomEditor hook like in VisualEditor, and display a page view ourselves. This mostly works, but the problem is that the rest of MediaWiki and gadgets still think we're in edit mode, because Action::getActionName( ... ) (in PHP) and mw.config.get( 'wgAction' ) (in JS) still return 'edit'.

Another approach looks promising:

• Add a hook in Action::getActionName that allows us to return 'view' on these URLs. This should work, but it's a very low-level thing, and maybe there is some reason why there isn't a hook there already?

Change 708537 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Add a hook 'GetActionName' to allow overriding the action name

https://gerrit.wikimedia.org/r/708537

Change 708538 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Avoid conflicts between 2017 wikitext editor and DiscussionTools new topic tool

https://gerrit.wikimedia.org/r/708538

Change 708539 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Allow the new topic tool to handle URLs like action=edit&section=new

https://gerrit.wikimedia.org/r/708539

Some interesting interactions that came up when I started testing it:

• When you open a action=edit&section=new URL, and you close the new topic tool, should the URL be updated? And should it be updated the opposite way when you open the new topic tool without navigating to a URL?
  • I think the answers are "yes" and "yes, but…", I only implemented the first half
  • Updating the URLs like that means that we should also handle back and forward navigation using the browser. This adds some complexity, especially because we might want to prevent this navigation, because we want to first display the dialog to warn the user about discarding their input. We've solved that for VisualEditor in the past, and that solution can be adapted, but I'll have to re-learn how it works.
  • (It might be worthwhile to turn this into a reusable library, but that becomes a bigger project. We already have a similar library called 'oojs-router', but it only handles changing the fragment part of the URL #.... There are various open source router libraries as well, but from a quick googling, they mostly only support changing the path part of the URL /..., and not the query ?..., which we need here.)

• When you open a action=edit&section=new URL, the "Add topic" tab in page navigation will be active (instead of "Read"). When you close the new topic tool, should the active tabs be updated? And should they be updated the opposite way when you open the new topic tool without navigating to a URL?
  • I think the answers are "yes" and "yes", I implemented that

Test wiki created on Patch Demo by Matma Rex using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/014e812f6d/w/

Demo page with more ways to add a new topic than you thought possible: https://patchdemo.wmflabs.org/wikis/b21a61fdeb/wiki/Talk:New_section

(old demo: https://patchdemo.wmflabs.org/wikis/014e812f6d/wiki/Talk:New_section)

(Apparently you can't post the new topics on the demo, or view the page while you have topic subscriptions enabled – you'll get a fat red error. This is an unrelated problem, now filed as T287611. Sorry, I didn't notice that earlier.)

Test wiki created on Patch Demo by DLynch (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/b21a61fdeb/w/

(Rearranged the tickets so that the three former subtasks are parent tasks instead. The features described there are blocked on this being implemented, not the other way.)

In T282204#7252677, @ppelberg wrote:

@ppelberg to review both cases @matmarex explains in T282204#7243340 using this patchdemo prototype:

https://patchdemo.wmflabs.org/wikis/b21a61fdeb/wiki/Talk:New_section

@matmarex, a couple of questions for you after reviewing the above...

• Can you describe what handling, "...back and forward navigation using the browser." would involve? Here's the flow that came to mind after reading the scenario you posted in T282204#7243340...
  • 1. Visit: https://patchdemo.wmflabs.org/wikis/b21a61fdeb/w/index.php?title=Talk:New_section
  • 2. Click ⌘ (mac) + Add topic
  • 3. Notice a new browser tab opens (https://patchdemo.wmflabs.org/wikis/b21a61fdeb/w/index.php?title=Talk:New_section&action=edit&section=new) and the New Discussion Tool is open within that tab/window
  • 4. ✅Click the browser's ← button
  • 5. ???
• To be doubly sure, when you said "Active" here [i], were you referring to the state of the Add topic tab that's shown below?
  • If "yes," then I agree with what you've implemented:
    • 1) "When you open a action=edit&section=new URL, the Add topic tab in page navigation will be active"
    • 2) When you close the New Discussion Tool, the Read tab should enter an active state
    • 3) "1) and "2)" should be implemented regardless of the method used to initially open the New Discussion tool.
      

i.

In T282204#7243340, @matmarex wrote:

When you open a action=edit&section=new URL, the "Add topic" tab in page navigation will be active (instead of "Read"). When you close the new topic tool, should the active tabs be updated? And should they be updated the opposite way when you open the new topic tool without navigating to a URL?

Change 708537 merged by jenkins-bot:

[mediawiki/core@master] Add a hook 'GetActionName' to allow overriding the action name

https://gerrit.wikimedia.org/r/708537

Change 708538 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Avoid conflicts between 2017 wikitext editor and DiscussionTools new topic tool

https://gerrit.wikimedia.org/r/708538

Change 708539 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Allow the new topic tool to handle URLs like action=edit&section=new

https://gerrit.wikimedia.org/r/708539

In T282204#7253158, @ppelberg wrote:

• To be doubly sure, when you said "Active" here [i], were you referring to the state of the Add topic tab that's shown below?

Yes.

In T282204#7253158, @ppelberg wrote:

• Can you describe what handling, "...back and forward navigation using the browser." would involve? Here's the flow that came to mind after reading the scenario you posted in T282204#7243340...
  • 1. Visit: https://patchdemo.wmflabs.org/wikis/b21a61fdeb/w/index.php?title=Talk:New_section
  • 2. Click ⌘ (mac) + Add topic
  • 3. Notice a new browser tab opens (https://patchdemo.wmflabs.org/wikis/b21a61fdeb/w/index.php?title=Talk:New_section&action=edit&section=new) and the New Discussion Tool is open within that tab/window
  • 4. ✅Click the browser's ← button
  • 5. ???

Here are the steps to reproduce what I'm thinking of, and videos. I don't mean Cmd-clicking (or Ctrl-clicking) to open a new tab, just using the links within one tab.

1. Visit that page, in view mode
2. Open one of the editors, by clicking: a) "Edit" tab b) "Add topic" tab c) "Add topic" link next to "Internal link" in the table
   1. This should change the URL in the address bar in the browser, so that if you clicked reload in the browser, you'd see the same page
3. Click "Cancel" to close the editor
   1. This should change the URL in the address bar in the browser again
4. Click back in your browser
   1. This should open the editor again
5. Click back in your browser again
   1. This should open the view mode again
   2. And you can also click forward to go to the editor again, and keep clicking back and forward as much as you like

I think it would probably be good if the behavior was the same in a), b) and c). However, with the current implementation:

• In a) it works as described above (in wikitext editor shown here, and also in visual editor)
• In b) the address bar does not change, and you can't click back or forward because the button is disabled
• In c) you can click back only once and it skips directly to view mode, and you can't click forward

(Actually, QA should be handled in the parent tasks, which have the details about expected behavior in each case.)

Test wiki on Patch Demo by DLynch (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/b21a61fdeb/w/

Test wiki on Patch Demo by Matma Rex using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/014e812f6d/w/