Topic on Talk:Structured Discussions

Jump to navigation Jump to search

paste with wikitext locks up the browser tab

8
Alsee (talkcontribs)

I suspect this latest breakage is caused by Phabricator T155861: Migrate Flow to use the integrated VE/WT editor widget when it exists.

Steps to reproduce:

  1. Go to United States or any of the other 500 articles listed here.
  2. Edit source.
  3. Copy all. (CTRL-A CTRL-C)
  4. Click reply or create a new Flow post in wikitext mode. (Visual mode seems to be equally affected, but I only tested it once.)
  5. Paste. (CTRL-V)
  6. The browser tab locks up completely. Wait. Wait. Wait. In one case I tried waiting over 15 minutes.
  7. Kill the browser tab to escape.

Expected results:

  • Functionality and performance which is not catastrophically inferior or broken compared to existing talk pages. That includes, but is not limited to:
    • On a Talk page the entire sequence from clicking-edit, loading the editor, pasting any article text, clicking preview, and receiving that preview, can ALL be completed in under ten seconds in my experience. Taking twice as long might be a tolerable downgrade, but generating browser time-out popup errors is obviously unacceptable breakage.
    • On a Talk page, pasting any wikitext and previewing provides a correct wikitext render (and of course a correct preview-render of the wikitext). Flow's wikitext support is unacceptably broken, but that's been broken from day Flow was built.


Tip: When the WMF finally gets around to admitting Flow is never going to be accepted, and potentially starts a new project from scratch to address Talk pages, the #1 requirement for design development and testing is to copy paste various articles into it and make sure you're not breaking anything. Any project to replace/improve talk pages is NEVER going to be accepted if the team isn't treating that as a #1 MVP requirement from the start. Talk pages are not chatboards. Talk pages are a wiki-workplace, and editors have this odd expectation that we can copy-paste anything from anywhere to anywhere as part of our work. Any project ignoring that fact is just going to be a black-hole waste of staff-time and donor-money.

197.218.88.227 (talkcontribs)

This is likely worse in a firefox browser. On a chrome browser it loads in a few seconds, less 40. This might be due to performance optimizations that chrome has.

No matter how desperately people want to blame developers. The simple fact is that the textarea input box isn't a magic bullet either. Pasting content equivalent to the maximum bytes (2MB) that can be saved, will mean the browser will also take a few seconds to load it. This might not be an issue for a sufficiently powerful computer, but it certainly will be a massive issue on older and less performant platforms like mobile devices, tablets etc.

Bad performance is quite simply an inherent design flaw of web-based development. Bad editing performance on the web in general isn't going to change in near future, unless editors are redesigned to either use plugins like flash or use "native" web based applications that aren't based on the DOM model or someone comes up with a way to overcome those deficiencies.

Anyway, one way to deal with pastes in general is simply to defer it when it is massive. Instead of pasting the whole content, it could paste enough to fill 3 or 4 screens , and asynchronously load the rest as needed.

197.218.88.227 (talkcontribs)

Indeed, apparently it is an issue that has affected browsers (for years ) using = the "plain" wikitext editor.

https://bugzilla.mozilla.org/show_bug.cgi?id=190147

https://bugs.chromium.org/p/chromium/issues/detail?id=109587

In fact, there are claims that at some point firefox only allowed 64K in a textarea:

https://stackoverflow.com/questions/1600398/large-text-in-textarea-freezes-computer/7584116

Alsee (talkcontribs)

The WMF was informed that Flow had fatal design flaws even before the prototype was built. Three of the most important wikis now have explicit consensus to refuse delivery of the defective product, other major wikis would also surely refuse refuse it if the WMF attempted to move forward on it.

The NewWikitextEditor was effectively built in secret, and as soon as the prototype was made available the WMF was informed that it had fatal design flaws. The biggest wiki has an explicit consensus refuse delivery of the defective product, and other major wikis would surely also refuse delivery if the WMF tried to move forward with it.

I come here pointing out that that the latest move to combine the two mis-designed products causes them to burst into flames, and your response is:

  1. List fictional problems that aren't affecting anyone.
  2. Tell me that Bad performance is quite simply an inherent design flaw of web-based development, which is quite absurd when our pre-existing tools have excellent performance.

I am *this* close to just reverting the two IP posts instead of replying.

There isn't a programming problem. There's a design problem, a strategy problem, and an ignoring-end-user-feedback problem.

Jdforrester (WMF) (talkcontribs)
I am *this* close to just reverting the two IP posts instead of replying.

Please do not blank other people's discussions just because you disagree with them. Such behaviour will likely get you blocked from this (or any) wiki.

Alsee (talkcontribs)

JDF, don't worry. It wouldn't even cross my mind to delete other people's discussions just because I disagreed with them.

But since you're here, perhaps you could make a content-relevant reply? Either on:

  1. The immediate issue of paste into Flow locking up the browser tab apparently due to integration of the 2017Editor; or
  2. preferably on the broader issue of the WMF explicitly disregarding community feedback on Flow and major multi wiki rejection of Flow + the WMF effectively building 2017Editor in secret and disregarding community feedback on 2017Editor and community rejection + the WMF just rolling forwards on both projects and making them go from bad to "kill the browser" worse. I'd really love for us all to work together better new and better wikisoftware, but there seem to be ongoing problems of strategy-conflict with the community and an isolationist approach to design.
Jdforrester (WMF) (talkcontribs)

Sorry, I don't feel I can answer your question. It seems to be based on a set of facts with which I am not familiar.

This post was hidden by Clump (history)
Reply to "paste with wikitext locks up the browser tab"