Page MenuHomePhabricator

<nowiki>~~~~</nowiki> in discussiontools is changed to <span data-dtsignatureforswitching="1"></span> when switching from source to visual mode
Open, Needs TriagePublicBUG REPORT

Description

List of steps to reproduce (step by step, including full links if applicable):

  • Open the discussiontools (reply or new topic)
  • Select source mode
  • enter <nowiki>~~~~</nowiki>
  • Change to visual mode

What happens?:
<span data-dtsignatureforswitching="1"></span> appears in the editor. When changing back to source, code is:

<nowiki><span data-dtsignatureforswitching="1"></span></nowiki>

What should have happened instead?:
~~~~ should appear instead. When changing back to source, it should be the original

<nowiki>~~~~</nowiki>

Event Timeline

For context: we use Parsoid for switching between visual and wikitext mode, and Parsoid doesn't support the "pre-save transform" (T247110), which is where signature syntax is parsed. This bug is caused by a messy workaround for that in our code.

I spent some time working on this (probably too much time). I came up with some alternative solutions, but it turns out that they have different issues, probably worse than the one we're trying to fix.

Our current approach is that we replace ~~~~ with a special marker in the wikitext before PST and passing it to Parsoid. As you discovered, this has incorrect results when the tildes are wrapped in nowiki, pre, or some other tags.

The two things I tried are:

  • Alternative approach 1 is that we disable PST in our current code, which lets Parsoid pass-through the tildes unchanged, and then we detect the tildes in the resulting HTML and mark them to be rendered as signatures instead in the visual mode. However, disabling PST will also disable the parsing of other syntax, like the pipe trick, and will look incorrectly in visual mode, causing similar issues to T139159 (and probably cause some <nowiki> tags to be incorrectly added).
  • Alternative approach 2 is that we apply PST and parse using Parsoid, and then we run our signature detector on the resulting HTML (the same code that we use to find comments on the page and give them reply links). However, that may not exactly match the fragment generated by the signature, particularly when it has "prefixes" as described in T245220#5883641 – the prefix would probably be duplicated every time you switch modes.

More ideas that I didn't try because they seemed bad, but worth writing down:

  • Alternative approach 3 is that we remove our current code causing the issue, and accept that when you switch from wikitext to visual, the signature will be turned into normal links and text. Notably, the timestamp will "freeze" on the time of the switch, and may not match the time when the comment is saved. Also, we will add a duplicate signature, since our code won't be able to detect the eixsting one.
  • Alternative approach 4 is that we add more special cases to the current approach, to detect when the tildes are wrapped in nowiki. This will still fail in some cases, although perhaps rarer and more complicated. To do it perfectly correctly, we'd have to port a large chunk of wikitext parser to our JS code (Preprocessor_Hash.php).

I also have some ideas that seem to actually be good, but they will need support from the Parsing team:

  • Alternative approach 5 is that we wait for them to resolve T247110. It seems like a large architectural change, so we probably can't help much.
  • Alternative approach 6 is that we modify the old parser to separate the current PST into signatures and everything-else, and then only use the everything-else part in our code. Then we can do approach 1 but without the drawbacks. It seems feasible to implement, but I'm not sure how they feel about such changes to the old parser, and I'd like them to review the patch.

To summarize: the only good solution that I can see (approach 6 above) requires us to coordinate with the Parsing team, and I'm not sure if it's worth both their and our time.