Remove 'visualeditor-enable' from $wgHiddenPrefs

classic Classic list List threaded Threaded
101 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Erik Moeller-4
On Tue, Jul 23, 2013 at 12:05 AM, Tim Starling <[hidden email]> wrote:
> I tried editing [[Argentina]] on my laptop just now, it took 45
> seconds of CPU time and 51 seconds of wall clock time before the
> percentage CPU usage began to drop. It's pretty slow.

Yes, that's why I said "performance on long pages can absolutely be
prohibitively poor", and I would qualify this 150K document as such.
:P About 30 seconds in Chrome on this system until I can start making
formatting changes, BTW.

For comparison, I'd also suggest copying the document into another
rich-text editing environment and observing performance
characteristics. Google Docs, which is generally regarded as
state-of-the-art in this regard, took about 40 seconds (with a "tab
crashed" warning) when attempting to paste this entire article in
before becoming responsive (it is significantly more responsive than
VE, although still sluggish, once the document is active). It also
throws a warning about too many images.

Point being, it's a legitimately hard problem. And, to be fair, the
equivalent of performing document-level operations within wikitext
(loading the whole page and previewing your changes before saving)
isn't exactly lightning-fast. An AJAX live-preview on that page takes
about 12 seconds to generate.

> Is there any estimate as to how much development time it might take to
> improve performance by an order of magnitude or so, as seems to be
> required?

I'm not sure that goal is fully attainable, but I'd suggest folks from
the VE team weigh in with some of their thoughts on performance
strategies. As I understand it, one of the near term improvements is
to target selective activation of the editing surface (in a manner
that's transparent to the user) which could reduce CPU and memory
footprint quite significantly for operations that don't span the
entire document.

Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Steven Walling
In reply to this post by Risker
On Tue, Jul 23, 2013 at 12:19 AM, Risker <[hidden email]> wrote:

> You pretty much had one chance at A/B testing, and it's done now.  You
> can't repeat the tests as long as VE is the default editor.
>

That's not correct at all. It's still entirely possible to deliver
different editing environments to randomized sets of new users, through the
magic of software. We should be replicating a similar A/B test of VE again
in my opinion.

This kind of testing isn't easy the first time you do it. What was supposed
to be a week-long test (the usual minimum amount of time we look at
editor-related features) had to be pared down to just three days of data,
which is unfortunate but not entirely unexpected considering we had never
done this kind of data collection with VE before.

Three days of data produced from a period where, as Erik noted, there were
major errors with the browser blacklist and other issues likely means that
the negative results were due to VE simply being buggy pre-launch in June.
Aaron says this in his draft conclusions: "As mentioned in the discussion
of Quantity of contribution, several known and unknown VisualEditor bugs
may have prevented newcomers from saving changes to articles. The decreased
probability of successfully saving an edit discussed above could be the
result of such bugs."[1] In the meantime, the VE team has responded by
fixing numerous bugs in the month following.

If you want to understand what the test results suggest, particularly
regarding the future steps in evaluating VE from a quantitative standpoint
should be, I believe Aaron is working on suggestions for further testing.

Steven

1.
https://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_registered_editors/Results#Summary
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Chad
In reply to this post by Steve Summit
On Mon, Jul 22, 2013 at 8:54 PM, Steve Summit <[hidden email]> wrote:

> Here's a thought experiment: if visual editing had existed (with
> reasonable functionality) since day 1, would there ever have been
> a way to disable it, let alone a hue and cry over a lack of a way
> to disable it?
>
>
This isn't a good analogy. Assuming we'd had visual editing since
day 1, I would presume we wouldn't have had source editing...a
better way would be to say "if we'd had VE since day one and we
were trying to add source editing, would there be an uproar?" Maybe,
but impossible to prove.

-Chad
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

John Mark Vandenberg
In reply to this post by Subramanya Sastry
On Tue, Jul 23, 2013 at 4:32 PM, Subramanya Sastry
<[hidden email]> wrote:

> On 07/22/2013 10:44 PM, Tim Starling wrote:
>>
>> Round-trip bugs, and bugs which cause a given wikitext input to give
>> different HTML in Parsoid compared to MW, should have been detected
>> during automated testing, prior to beta deployment. I don't know why
>> we need users to report them.
>
>
> 500+ edits are being done per hour using Visual Editor [1] (less at this
> time given that it is way past midnight -- I have seen about 700/hour at
> times).  I did go and click on over 100 links and examined the diffs.  I did
> that twice in the last hour.  I am happy to report clean diffs on all edits
> I checked both times.
>
> I did run into a couple of nowiki-insertions which
> is, strictly speaking not erroneous and based on user input, but is more a
> usability issue.

What is a dirty diff?  One that inserts junk unexpectedly, unrelated
to the user's input?

The broken table injection bugs are still happening.

https://en.wikipedia.org/w/index.php?title=Sai_Baba_of_Shirdi&curid=144175&diff=565442800&oldid=565354286

If the parser isnt going to be fixed quickly to ignore tables it
doesnt understand, we need to find the templates and pages with these
broken tables - preferably using SQL and heuristics and fix them.  The
same needs to be done for all the other wikis, otherwise they are
going to have the same problems happening randomly, causing lots of
grief.

I presume this is also a dirty diff

https://en.wikipedia.org/w/index.php?title=Dubbing_%28filmmaking%29&curid=8860&diff=565438776&oldid=565408739

In addition to nowikis, there are also wikilinks that are not what the
user intended

https://en.wikipedia.org/w/index.php?title=Ben_Tre&curid=1822927&diff=565439119&oldid=561995413
https://en.wikipedia.org/w/index.php?title=Celton_Manx&curid=28176434&diff=565439020&oldid=565436056

Here is three edits to try to add a section header and a sentence,
with a wikilink in the section header.
(In the process they added other junk into the page, probably unintentionally.)

https://en.wikipedia.org/w/index.php?title=Port_of_Davao&action=history&offset=2013072307&limit=4

A leading line feed in a parameter - what the?

https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&curid=39469556&diff=565437324&oldid=565416618

External links which should be converted to internal links:

https://en.wikipedia.org/w/index.php?title=Krishna_%28TV_series%29&diff=565437699&oldid=564621100

That is all in the last hour, and I've only checked ~100 diffs.

I appreciate that some of these are a result of user input, and the RC
feed of non-VE edits will have similar problems exhibited by newbies,
albeit different because it is the source editor.  And it is great to
see so many constructive VE edits.  But you're not going to get much
love by claiming that it is now stable and not causing broken diffs.
In addition, VE can crash a Google Chrome tab, and it can cause
(unsaved changes) dataloss in most browser configurations.

--
John Vandenberg

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tyler Romeo
In reply to this post by Erik Moeller-4
On Tue, Jul 23, 2013 at 2:35 AM, Erik Moeller <[hidden email]> wrote:

> On the first point, right now, we're approaching categories and
> similar page metadata from the point of view of the editing surface as
> an entrypoint. This makes sense if you simply try to map all aspects
> of markup (which is inherently positional, even where it carries no
> positional value like categories) into an editing interface. VE is at
> least providing a "Page Settings" dialog that gets rid of the
> positional context for categories, etc.
>
> However, from a user's standpoint, it still doesn't make a ton of
> sense to do it that way. If I just want to add a category, I shouldn't
> have to invoke an editing surface at all. Similarly, if I want to turn
> a page into a redirect, I shouldn't have to edit the page at all. As
> most of you know, some gadgets like HotCat already operate on a
> similar principle.
>

Why should VE be doing this if you're not entering the editor. HotCat (and
the future extension based on it) can handle categories just fine. The VE
team should focus on fixing its current issues before attempting to
introduce new features.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Denny Vrandečić
In reply to this post by MZMcBride-2
2013/7/23 MZMcBride <[hidden email]>

> What we need is for you and Erik to recognize that you're wrong and to
> make this right. Is there anyone besides you and Erik who agree with the
> position you're taking here?
>

They are not alone. I also agree with their position, and I sincerely hope
we are not alone.

E.g. here:

<http://insideintercom.io/product-strategy-means-saying-no/>



--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Derric Atzrott
In reply to this post by John Doe-27
<snip>
>Since the devs implemented resource loader it has become
>harder and harder to block the poorly developed bloat that has crept into
>mediawiki. I used to be able to isolate the JavaScript file causing the
>issues (I remember BITS geolocation being a major hog) and just block it.
>Now thats not possible any longer.
<snip>

Slightly off topic, but for this problem at least you could try using ?debug=true which will turn off that portion of Resource Loader.

Thank you,
Derric Atzrott


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Derric Atzrott
In reply to this post by Tyler Romeo
>> However, from a user's standpoint, it still doesn't make a ton of
>> sense to do it that way. If I just want to add a category, I shouldn't
>> have to invoke an editing surface at all. Similarly, if I want to turn
>> a page into a redirect, I shouldn't have to edit the page at all. As
>> most of you know, some gadgets like HotCat already operate on a
>> similar principle.
>>
>
>Why should VE be doing this if you're not entering the editor. HotCat (and
>the future extension based on it) can handle categories just fine. The VE
>team should focus on fixing its current issues before attempting to
>introduce new features.

I agree with Tyler here.  This should really be deployed as a separate extension that perhaps makes use of Visual Editor.  I also agree with the sentiment that we need to fix the current issues before we try to add more features, though looking towards the future is still reasonable.

Also I don't see why we can't work out that problem though when it arrives.  Currently we have a very immediate issue though of the masses politely requesting and then demanding that this option be added back.  If we need to remove it again later, I don't see why we can't.

There were a large number of us who argued that this deployment was inappropriate to begin with, and I personally still stand by that.  Visual Editor is not yet ready for the masses and the masses have made it clear that they don't want to use it (see source edits vs visual edits as discussed earlier).  We're not asking that you disable Visual Editor as the default editor, if you still feel that it needs to be the default in order to collect the data you need for bug testing, that's fine by me (though I continue to disagree with the decision), go ahead and do that.  For the people though that do not foresee themselves using Visual Editor anytime soon, it would be nice for them to have an option that isn’t a hack.

I know I'm repeating arguments here that have already been covered in previous posts, but I really think that adding the option back is the way to go.  I would go as far as to say enable the option and then continue the discussion as to whether or not the option is appropriate.  Every day that passes that it is not around is another huge PR hit for all of us developer types.

From what I have seen on this mailing list the past few days, please correct me if I am wrong, is that the community feels frustrated that the product team for Visual Editor is failing to acknowledge their needs.  Enabling this preference would likely clear the air a lot and allow us to have a much saner discussion as to the direction this project needs to go.

Thank you,
Derric Atzrott

ps. Really looking forward to when Visual Editor is done.  This has been the most exciting extension I've seen in a long time and I really do want it to succeed.  I've seen a large many people turned off by Wikitext, but we can't afford to create the rift we are making right now.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

John Doe-27
In reply to this post by Derric Atzrott
On Tue, Jul 23, 2013 at 10:28 AM, Derric Atzrott <
[hidden email]> wrote:

> <snip>
> >Since the devs implemented resource loader it has become
> >harder and harder to block the poorly developed bloat that has crept into
> >mediawiki. I used to be able to isolate the JavaScript file causing the
> >issues (I remember BITS geolocation being a major hog) and just block it.
> >Now thats not possible any longer.
> <snip>
>
> Slightly off topic, but for this problem at least you could try using
> ?debug=true which will turn off that portion of Resource Loader.
>
> Thank you,
> Derric Atzrott
>
> That would only work for a single page, the next link I click on the debug
flag is ignored. Such a method becomes unfeasible with any serious usage.

If Source editing is going to be supported for a long time, what reason is
there for not allowing users to turn off a broken piece of software? I just
did a quick look at bugzilla there are 618 open bugs for VE alone. The
community is demanding the ability to disable this. Ive lost count on the
number of pages that it has broken. It drives editors away and prevents new
users from editing. What are the real pros for VE right now? Other than a
few WMF staff saying *Because I said So* I haven't seen any real progress.
Just like with notifications This was poorly thought out and poorly
implemented long before it should have gone live.

Ive seen this posted elsewhere, but why wasnt this tested thoroughly and
rolled out slowly to ensure minimal impact and minimal site breakage. The
WMF shoved VE down everyone's throat at least 6 months before it should
have gone site wide. (Why? just to meet some artificial deadline that they
created themselves )

What should have happened was a scaled deployment process that slowly
rolled out to ensure minimal negative impact. Here is just one example of
how it should have been rolled out:

1 Closed Beta on major wikis (those who know the software can test it in an
actual environment that's not in a lab) 1-2 Weeks
2 Open Opt-In Beta At least 60 days
3 Step back all bugs reported
4 Enable for a small group of users who understand the wiki (AKA enable for
sysops) Minimal testing 60 days
5 Listen to feedback, fix bugs and address issues.
6 Incrementally roll out to larger sub groups in 2-3 weeks intervals
7 Once a working stable product without major issues has been developed
roll out to all registered users
8. Stop re-assess impact, feedback and issues associated with the project,
listen to users and resolve any outstanding issues.
9 Deploy to all users once a stable, bug free product is ready.

Until the time where you are going to force people to use VE and
discontinue support for the Source Editor there should be a method for
disabling VE. I know I am not alone stating that I hate to be someone's
guinea pig. Ill switch over to a new product when I feel it offers a better
product. I would rather not have stuff shoved down my throat and told its
good for you. (If its being shoved down your throat it is rarely a better
product)

John
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tyler Romeo
In reply to this post by Derric Atzrott
I just want to be absolutely clear, for the purposes of solving this
problem and staying on topic, we are *not* discussing:

* Whether VE is a good product or not (it clearly is)
* Whether VE should be deployed or not (it already is)
* Whether VE should have an option to be disabled (it already has)

The real root of this discussion is whether or not the method through which
VE is disabled is done as a Gadget or as a user preference. Both methods
are already implemented, it's just a matter of a configuration variable.

With that said, I'd like to see more points on what real motivation there
is to force users to have a gadget to do something that an existing user
preference already does.


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | [hidden email]


On Tue, Jul 23, 2013 at 10:59 AM, Derric Atzrott <
[hidden email]> wrote:

> >> However, from a user's standpoint, it still doesn't make a ton of
> >> sense to do it that way. If I just want to add a category, I shouldn't
> >> have to invoke an editing surface at all. Similarly, if I want to turn
> >> a page into a redirect, I shouldn't have to edit the page at all. As
> >> most of you know, some gadgets like HotCat already operate on a
> >> similar principle.
> >>
> >
> >Why should VE be doing this if you're not entering the editor. HotCat (and
> >the future extension based on it) can handle categories just fine. The VE
> >team should focus on fixing its current issues before attempting to
> >introduce new features.
>
> I agree with Tyler here.  This should really be deployed as a separate
> extension that perhaps makes use of Visual Editor.  I also agree with the
> sentiment that we need to fix the current issues before we try to add more
> features, though looking towards the future is still reasonable.
>
> Also I don't see why we can't work out that problem though when it
> arrives.  Currently we have a very immediate issue though of the masses
> politely requesting and then demanding that this option be added back.  If
> we need to remove it again later, I don't see why we can't.
>
> There were a large number of us who argued that this deployment was
> inappropriate to begin with, and I personally still stand by that.  Visual
> Editor is not yet ready for the masses and the masses have made it clear
> that they don't want to use it (see source edits vs visual edits as
> discussed earlier).  We're not asking that you disable Visual Editor as the
> default editor, if you still feel that it needs to be the default in order
> to collect the data you need for bug testing, that's fine by me (though I
> continue to disagree with the decision), go ahead and do that.  For the
> people though that do not foresee themselves using Visual Editor anytime
> soon, it would be nice for them to have an option that isn’t a hack.
>
> I know I'm repeating arguments here that have already been covered in
> previous posts, but I really think that adding the option back is the way
> to go.  I would go as far as to say enable the option and then continue the
> discussion as to whether or not the option is appropriate.  Every day that
> passes that it is not around is another huge PR hit for all of us developer
> types.
>
> From what I have seen on this mailing list the past few days, please
> correct me if I am wrong, is that the community feels frustrated that the
> product team for Visual Editor is failing to acknowledge their needs.
>  Enabling this preference would likely clear the air a lot and allow us to
> have a much saner discussion as to the direction this project needs to go.
>
> Thank you,
> Derric Atzrott
>
> ps. Really looking forward to when Visual Editor is done.  This has been
> the most exciting extension I've seen in a long time and I really do want
> it to succeed.  I've seen a large many people turned off by Wikitext, but
> we can't afford to create the rift we are making right now.
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Subramanya Sastry
In reply to this post by John Mark Vandenberg
Hi John and Risker,

First off, I do want to once again clarify that my intention in the
previous post was not to claim that VE/Parsoid is perfect.  It was more
that we've fixed sufficient bugs at this point that the most significant
"bugs" (bugs, not missing features) that need fixing (and are being
fixed) are those that have to do with usability tweaks.  My intention in
that post was also not one to put some distance between us and the
complaints, just to clarify that we are fixing things as fast as we can
and it can be seen in the recent changes stream.

John: specific answers to the edit diffs you highlighted in your post.  
I acknowledge your intention to make sure we dont make false claims
about VE/Parsoid's usability.   Thanks for taking the time for digging
them up.  My answers below are made with an intention of figuring out
what the issues are so they can be fixed where they need to be.

On 07/23/2013 02:50 AM, John Vandenberg wrote:

> On Tue, Jul 23, 2013 at 4:32 PM, Subramanya Sastry
> <[hidden email]> wrote:
>> On 07/22/2013 10:44 PM, Tim Starling wrote:
>>> Round-trip bugs, and bugs which cause a given wikitext input to give
>>> different HTML in Parsoid compared to MW, should have been detected
>>> during automated testing, prior to beta deployment. I don't know why
>>> we need users to report them.
>>
>> 500+ edits are being done per hour using Visual Editor [1] (less at this
>> time given that it is way past midnight -- I have seen about 700/hour at
>> times).  I did go and click on over 100 links and examined the diffs.  I did
>> that twice in the last hour.  I am happy to report clean diffs on all edits
>> I checked both times.
>>
>> I did run into a couple of nowiki-insertions which
>> is, strictly speaking not erroneous and based on user input, but is more a
>> usability issue.
> What is a dirty diff?  One that inserts junk unexpectedly, unrelated
> to the user's input?

That is correct.  Strictly speaking, yes, any changes to the wikitext
markup that arose from what the user didn't change.

> The broken table injection bugs are still happening.
>
> https://en.wikipedia.org/w/index.php?title=Sai_Baba_of_Shirdi&curid=144175&diff=565442800&oldid=565354286
>
> If the parser isnt going to be fixed quickly to ignore tables it
> doesnt understand, we need to find the templates and pages with these
> broken tables - preferably using SQL and heuristics and fix them.  The
> same needs to be done for all the other wikis, otherwise they are
> going to have the same problems happening randomly, causing lots of
> grief.

This maybe related to this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51217  and I have a
tentative fix for it as of y'day.

VE and Parsoid devs have put in a lot and lot of effort to recognize
broken wikitext source, fix it or isolate it, and protect it across
edits, and roundtrip it back in original form to prevent corruption.  I
think we have been largely successful but we still have more cases to go
that are being exposed here which we will fix.  But, occasionally, these
kind of errors do show up -- and we ask for your patience as we fix
these.  Once again, this is not a claim to perfection, but a claim that
this is not a significant source of corrupt edits.  But, yes even a 0.1%
error rate does mean a big number in the absolute when thousands of
pages are being edited -- and we will continue to pare this down.

> I presume this is also a dirty diff
>
> https://en.wikipedia.org/w/index.php?title=Dubbing_%28filmmaking%29&curid=8860&diff=565438776&oldid=565408739

Yes, this is a dirty diff where Parsoid reformatted a 2-line image
wikitext source into one by removing a line break.  Again, relative to
the # of edits being made, these are not frequent -- that was all that I
claimed, which I think is still true.  But that said, this is a
relatively minor and harmless change.

> In addition to nowikis, there are also wikilinks that are not what the
> user intended
>
> https://en.wikipedia.org/w/index.php?title=Ben_Tre&curid=1822927&diff=565439119&oldid=561995413
> https://en.wikipedia.org/w/index.php?title=Celton_Manx&curid=28176434&diff=565439020&oldid=565436056

You are correct, but this is not a dirty diff.  I dont want to claim
this is an user error entirely  -- but a combination of user and
software error.

> Here is three edits to try to add a section header and a sentence,
> with a wikilink in the section header.
> (In the process they added other junk into the page, probably unintentionally.)
>
> https://en.wikipedia.org/w/index.php?title=Port_of_Davao&action=history&offset=2013072307&limit=4

What is the problem here exactly?  (that is a question, not a
challenge).  The user might have entered those newlines as well.

> A leading line feed in a parameter - what the?
>
> https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&curid=39469556&diff=565437324&oldid=565416618

This is something I'll have to investigate.

> External links which should be converted to internal links:
>
> https://en.wikipedia.org/w/index.php?title=Krishna_%28TV_series%29&diff=565437699&oldid=564621100

This could be an enhancement to Parsoid.  Thanks for the bug report :-).

> That is all in the last hour, and I've only checked ~100 diffs.
>
> I appreciate that some of these are a result of user input, and the RC
> feed of non-VE edits will have similar problems exhibited by newbies,
> albeit different because it is the source editor.  And it is great to
> see so many constructive VE edits.

Thank you for acknowledging this!

> But you're not going to get much
> love by claiming that it is now stable and not causing broken diffs.

I did not make that specific claim, but it is possible that my tone was
more aggressive than I intended it to be.  Just so there is no
confusion, VE/Parsoid can still cause dirty/broken diffs, but I think
the claim is that at this time, the vast majority of ongoing edits do
not corrupt wikitext source and where there are diffs, we have narrowed
that down to a couple of causes (where VE/Parsoid inserts nowiki
wrappers) which are being fixed.

> In addition, VE can crash a Google Chrome tab, and it can cause
> (unsaved changes) dataloss in most browser configurations.

Subbu.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Derk-Jan Hartman

On 23 jul. 2013, at 18:06, Subramanya Sastry <[hidden email]> wrote:

>> A leading line feed in a parameter - what the?
>>
>> https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&curid=39469556&diff=565437324&oldid=565416618
>
> This is something I'll have to investigate.

This is probably actually desirable (lists starting at the beginning of the line). It should however have preserved the newline before the argument separator that is following this list value.

DJ


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Bartosz Dziewoński
In reply to this post by Bartosz Dziewoński
On a side note, I find it interesting how none of the actual VE and Parsoid developers replied here, apart from Roan, Chris and Subbu on off-topic technical issues (thanks for that).

--
Matma Rex

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Robert Rohde
In reply to this post by Subramanya Sastry
In the interest of gathering slightly larger statistics, I manually
reviewed 200 VE entries on recent changes.

I am classifying these as

* "Good" edit
* Test edits / newbie errors likely to happen in either editor (not VE's fault)
* Obvious vandal edit (not VE's fault)
* Damaged source that renders correctly (e.g. VE altering source
formatting that most source editors like to maintain, mostly involving
missing newlines)
* Test edits / newbie errors that occur with VE but were unlikely to
occur previously (e.g. people using lots of extra spaces / newlines to
visually "format" the positioning of content on a page)
* Corrupted page content that appears to be caused by the unfamiliar
UI (e.g. <nowiki>[[Foo]]</nowiki>)
* Corrupted page content that appears to be directly caused by VE /
Parsoid bugs (e.g. dirty diffs)

For the sake of simplicity, I'm counting any edit that is well-formed
and not obviously of destructive intent as "good" without
consideration of whether it satisfies Wikipedia content policies such
as NPOV, OR, etc.  There are inevitably many edits whose content isn't
appropriate or needs to be cleaned up, but I'm not worrying about
those.  In the rare case that an edit might fall in multiple
categories, I'm counting it towards the most severe of the categories
listed above (i.e. lower on the list).  This only applied a handful of
times.

Altogether, I rated the edits as follows:

* "Good": 157 (78.5%)
* Test / newbie edits (generic): 13 (6.5%)
* Obvious vandal: 7 (3.5%)
* Damaged source: 7 (3.5%)
* Test / newbie edits (VE oriented): 3 (1.5%)
* Corrupted page due to unfamiliar UI: 11 (5.5%)
* VE / Parsoid errors: 1 (0.5%) [This involved the editor spewing out
extra garbage when trying to save a page that started with malformed
table syntax.]

That's better than I would have guessed before going into this
exercise.  In particular, Subbu appears to be correct that the true
error rate for VE / Parsoid is relatively small (though I'd prefer the
error rate be too small to notice in a test like this).

The tendency of users to add nowikis and create other corruptions due
to the unfamiliar UI is still a concern though.  This is not at all
helped by the fact we have dozen of help pages that teach wiki syntax
like "[[Foo]]" which are now directly unhelpful to people using VE.
Over time, that will diminish somewhat as experienced users learn the
new system, though if it is truly to be useful for new users we
probably want to look carefully at the various ways new users may
misunderstand the new UI.  Also, I'm not thrilled by the examples of
VE manipulating the use of newlines so that template parameters,
categories, and other things sometimes run together in the source.

If the immediate goal is to ensure that using VE is not harmful for
people who know how to use it, then the developers are probably
getting pretty close.  Given the nowikis and such, VE probably still
causes higher levels of accidental harm when operated by unfamiliar
users than I would personally be comfortable with.  And of course,
there is still a long ways to go in terms of feature completeness and
usability before we can really discuss Erik's dream of having VE be
perceived as better than source editing.

-Robert Rohde

On Tue, Jul 23, 2013 at 9:06 AM, Subramanya Sastry
<[hidden email]> wrote:

> Hi John and Risker,
>
> First off, I do want to once again clarify that my intention in the previous
> post was not to claim that VE/Parsoid is perfect.  It was more that we've
> fixed sufficient bugs at this point that the most significant "bugs" (bugs,
> not missing features) that need fixing (and are being fixed) are those that
> have to do with usability tweaks.  My intention in that post was also not
> one to put some distance between us and the complaints, just to clarify that
> we are fixing things as fast as we can and it can be seen in the recent
> changes stream.
>
> John: specific answers to the edit diffs you highlighted in your post.  I
> acknowledge your intention to make sure we dont make false claims about
> VE/Parsoid's usability.   Thanks for taking the time for digging them up.
> My answers below are made with an intention of figuring out what the issues
> are so they can be fixed where they need to be.
>
>
> On 07/23/2013 02:50 AM, John Vandenberg wrote:
>>
>> On Tue, Jul 23, 2013 at 4:32 PM, Subramanya Sastry
>> <[hidden email]> wrote:
>>>
>>> On 07/22/2013 10:44 PM, Tim Starling wrote:
>>>>
>>>> Round-trip bugs, and bugs which cause a given wikitext input to give
>>>> different HTML in Parsoid compared to MW, should have been detected
>>>> during automated testing, prior to beta deployment. I don't know why
>>>> we need users to report them.
>>>
>>>
>>> 500+ edits are being done per hour using Visual Editor [1] (less at this
>>> time given that it is way past midnight -- I have seen about 700/hour at
>>> times).  I did go and click on over 100 links and examined the diffs.  I
>>> did
>>> that twice in the last hour.  I am happy to report clean diffs on all
>>> edits
>>> I checked both times.
>>>
>>> I did run into a couple of nowiki-insertions which
>>> is, strictly speaking not erroneous and based on user input, but is more
>>> a
>>> usability issue.
>>
>> What is a dirty diff?  One that inserts junk unexpectedly, unrelated
>> to the user's input?
>
>
> That is correct.  Strictly speaking, yes, any changes to the wikitext markup
> that arose from what the user didn't change.
>
>> The broken table injection bugs are still happening.
>>
>>
>> https://en.wikipedia.org/w/index.php?title=Sai_Baba_of_Shirdi&curid=144175&diff=565442800&oldid=565354286
>>
>> If the parser isnt going to be fixed quickly to ignore tables it
>> doesnt understand, we need to find the templates and pages with these
>> broken tables - preferably using SQL and heuristics and fix them.  The
>> same needs to be done for all the other wikis, otherwise they are
>> going to have the same problems happening randomly, causing lots of
>> grief.
>
>
> This maybe related to this:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=51217  and I have a tentative
> fix for it as of y'day.
>
> VE and Parsoid devs have put in a lot and lot of effort to recognize broken
> wikitext source, fix it or isolate it, and protect it across edits, and
> roundtrip it back in original form to prevent corruption.  I think we have
> been largely successful but we still have more cases to go that are being
> exposed here which we will fix.  But, occasionally, these kind of errors do
> show up -- and we ask for your patience as we fix these.  Once again, this
> is not a claim to perfection, but a claim that this is not a significant
> source of corrupt edits.  But, yes even a 0.1% error rate does mean a big
> number in the absolute when thousands of pages are being edited -- and we
> will continue to pare this down.
>
>
>> I presume this is also a dirty diff
>>
>>
>> https://en.wikipedia.org/w/index.php?title=Dubbing_%28filmmaking%29&curid=8860&diff=565438776&oldid=565408739
>
>
> Yes, this is a dirty diff where Parsoid reformatted a 2-line image wikitext
> source into one by removing a line break.  Again, relative to the # of edits
> being made, these are not frequent -- that was all that I claimed, which I
> think is still true.  But that said, this is a relatively minor and harmless
> change.
>
>
>> In addition to nowikis, there are also wikilinks that are not what the
>> user intended
>>
>>
>> https://en.wikipedia.org/w/index.php?title=Ben_Tre&curid=1822927&diff=565439119&oldid=561995413
>>
>> https://en.wikipedia.org/w/index.php?title=Celton_Manx&curid=28176434&diff=565439020&oldid=565436056
>
>
> You are correct, but this is not a dirty diff.  I dont want to claim this is
> an user error entirely  -- but a combination of user and software error.
>
>
>> Here is three edits to try to add a section header and a sentence,
>> with a wikilink in the section header.
>> (In the process they added other junk into the page, probably
>> unintentionally.)
>>
>>
>> https://en.wikipedia.org/w/index.php?title=Port_of_Davao&action=history&offset=2013072307&limit=4
>
>
> What is the problem here exactly?  (that is a question, not a challenge).
> The user might have entered those newlines as well.
>
>
>> A leading line feed in a parameter - what the?
>>
>>
>> https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&curid=39469556&diff=565437324&oldid=565416618
>
>
> This is something I'll have to investigate.
>
>
>> External links which should be converted to internal links:
>>
>>
>> https://en.wikipedia.org/w/index.php?title=Krishna_%28TV_series%29&diff=565437699&oldid=564621100
>
>
> This could be an enhancement to Parsoid.  Thanks for the bug report :-).
>
>
>> That is all in the last hour, and I've only checked ~100 diffs.
>>
>> I appreciate that some of these are a result of user input, and the RC
>> feed of non-VE edits will have similar problems exhibited by newbies,
>> albeit different because it is the source editor.  And it is great to
>> see so many constructive VE edits.
>
>
> Thank you for acknowledging this!
>
>
>> But you're not going to get much
>> love by claiming that it is now stable and not causing broken diffs.
>
>
> I did not make that specific claim, but it is possible that my tone was more
> aggressive than I intended it to be.  Just so there is no confusion,
> VE/Parsoid can still cause dirty/broken diffs, but I think the claim is that
> at this time, the vast majority of ongoing edits do not corrupt wikitext
> source and where there are diffs, we have narrowed that down to a couple of
> causes (where VE/Parsoid inserts nowiki wrappers) which are being fixed.
>
>
>> In addition, VE can crash a Google Chrome tab, and it can cause
>> (unsaved changes) dataloss in most browser configurations.
>
>
> Subbu.
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Risker
Why do you think those <nowiki> tags were added by the editors?

Risker


On 23 July 2013 15:32, Robert Rohde <[hidden email]> wrote:

> In the interest of gathering slightly larger statistics, I manually
> reviewed 200 VE entries on recent changes.
>
> I am classifying these as
>
> * "Good" edit
> * Test edits / newbie errors likely to happen in either editor (not VE's
> fault)
> * Obvious vandal edit (not VE's fault)
> * Damaged source that renders correctly (e.g. VE altering source
> formatting that most source editors like to maintain, mostly involving
> missing newlines)
> * Test edits / newbie errors that occur with VE but were unlikely to
> occur previously (e.g. people using lots of extra spaces / newlines to
> visually "format" the positioning of content on a page)
> * Corrupted page content that appears to be caused by the unfamiliar
> UI (e.g. <nowiki>[[Foo]]</nowiki>)
> * Corrupted page content that appears to be directly caused by VE /
> Parsoid bugs (e.g. dirty diffs)
>
> For the sake of simplicity, I'm counting any edit that is well-formed
> and not obviously of destructive intent as "good" without
> consideration of whether it satisfies Wikipedia content policies such
> as NPOV, OR, etc.  There are inevitably many edits whose content isn't
> appropriate or needs to be cleaned up, but I'm not worrying about
> those.  In the rare case that an edit might fall in multiple
> categories, I'm counting it towards the most severe of the categories
> listed above (i.e. lower on the list).  This only applied a handful of
> times.
>
> Altogether, I rated the edits as follows:
>
> * "Good": 157 (78.5%)
> * Test / newbie edits (generic): 13 (6.5%)
> * Obvious vandal: 7 (3.5%)
> * Damaged source: 7 (3.5%)
> * Test / newbie edits (VE oriented): 3 (1.5%)
> * Corrupted page due to unfamiliar UI: 11 (5.5%)
> * VE / Parsoid errors: 1 (0.5%) [This involved the editor spewing out
> extra garbage when trying to save a page that started with malformed
> table syntax.]
>
> That's better than I would have guessed before going into this
> exercise.  In particular, Subbu appears to be correct that the true
> error rate for VE / Parsoid is relatively small (though I'd prefer the
> error rate be too small to notice in a test like this).
>
> The tendency of users to add nowikis and create other corruptions due
> to the unfamiliar UI is still a concern though.  This is not at all
> helped by the fact we have dozen of help pages that teach wiki syntax
> like "[[Foo]]" which are now directly unhelpful to people using VE.
> Over time, that will diminish somewhat as experienced users learn the
> new system, though if it is truly to be useful for new users we
> probably want to look carefully at the various ways new users may
> misunderstand the new UI.  Also, I'm not thrilled by the examples of
> VE manipulating the use of newlines so that template parameters,
> categories, and other things sometimes run together in the source.
>
> If the immediate goal is to ensure that using VE is not harmful for
> people who know how to use it, then the developers are probably
> getting pretty close.  Given the nowikis and such, VE probably still
> causes higher levels of accidental harm when operated by unfamiliar
> users than I would personally be comfortable with.  And of course,
> there is still a long ways to go in terms of feature completeness and
> usability before we can really discuss Erik's dream of having VE be
> perceived as better than source editing.
>
> -Robert Rohde
>
> On Tue, Jul 23, 2013 at 9:06 AM, Subramanya Sastry
> <[hidden email]> wrote:
> > Hi John and Risker,
> >
> > First off, I do want to once again clarify that my intention in the
> previous
> > post was not to claim that VE/Parsoid is perfect.  It was more that we've
> > fixed sufficient bugs at this point that the most significant "bugs"
> (bugs,
> > not missing features) that need fixing (and are being fixed) are those
> that
> > have to do with usability tweaks.  My intention in that post was also not
> > one to put some distance between us and the complaints, just to clarify
> that
> > we are fixing things as fast as we can and it can be seen in the recent
> > changes stream.
> >
> > John: specific answers to the edit diffs you highlighted in your post.  I
> > acknowledge your intention to make sure we dont make false claims about
> > VE/Parsoid's usability.   Thanks for taking the time for digging them up.
> > My answers below are made with an intention of figuring out what the
> issues
> > are so they can be fixed where they need to be.
> >
> >
> > On 07/23/2013 02:50 AM, John Vandenberg wrote:
> >>
> >> On Tue, Jul 23, 2013 at 4:32 PM, Subramanya Sastry
> >> <[hidden email]> wrote:
> >>>
> >>> On 07/22/2013 10:44 PM, Tim Starling wrote:
> >>>>
> >>>> Round-trip bugs, and bugs which cause a given wikitext input to give
> >>>> different HTML in Parsoid compared to MW, should have been detected
> >>>> during automated testing, prior to beta deployment. I don't know why
> >>>> we need users to report them.
> >>>
> >>>
> >>> 500+ edits are being done per hour using Visual Editor [1] (less at
> this
> >>> time given that it is way past midnight -- I have seen about 700/hour
> at
> >>> times).  I did go and click on over 100 links and examined the diffs.
>  I
> >>> did
> >>> that twice in the last hour.  I am happy to report clean diffs on all
> >>> edits
> >>> I checked both times.
> >>>
> >>> I did run into a couple of nowiki-insertions which
> >>> is, strictly speaking not erroneous and based on user input, but is
> more
> >>> a
> >>> usability issue.
> >>
> >> What is a dirty diff?  One that inserts junk unexpectedly, unrelated
> >> to the user's input?
> >
> >
> > That is correct.  Strictly speaking, yes, any changes to the wikitext
> markup
> > that arose from what the user didn't change.
> >
> >> The broken table injection bugs are still happening.
> >>
> >>
> >>
> https://en.wikipedia.org/w/index.php?title=Sai_Baba_of_Shirdi&curid=144175&diff=565442800&oldid=565354286
> >>
> >> If the parser isnt going to be fixed quickly to ignore tables it
> >> doesnt understand, we need to find the templates and pages with these
> >> broken tables - preferably using SQL and heuristics and fix them.  The
> >> same needs to be done for all the other wikis, otherwise they are
> >> going to have the same problems happening randomly, causing lots of
> >> grief.
> >
> >
> > This maybe related to this:
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=51217  and I have a
> tentative
> > fix for it as of y'day.
> >
> > VE and Parsoid devs have put in a lot and lot of effort to recognize
> broken
> > wikitext source, fix it or isolate it, and protect it across edits, and
> > roundtrip it back in original form to prevent corruption.  I think we
> have
> > been largely successful but we still have more cases to go that are being
> > exposed here which we will fix.  But, occasionally, these kind of errors
> do
> > show up -- and we ask for your patience as we fix these.  Once again,
> this
> > is not a claim to perfection, but a claim that this is not a significant
> > source of corrupt edits.  But, yes even a 0.1% error rate does mean a big
> > number in the absolute when thousands of pages are being edited -- and we
> > will continue to pare this down.
> >
> >
> >> I presume this is also a dirty diff
> >>
> >>
> >>
> https://en.wikipedia.org/w/index.php?title=Dubbing_%28filmmaking%29&curid=8860&diff=565438776&oldid=565408739
> >
> >
> > Yes, this is a dirty diff where Parsoid reformatted a 2-line image
> wikitext
> > source into one by removing a line break.  Again, relative to the # of
> edits
> > being made, these are not frequent -- that was all that I claimed, which
> I
> > think is still true.  But that said, this is a relatively minor and
> harmless
> > change.
> >
> >
> >> In addition to nowikis, there are also wikilinks that are not what the
> >> user intended
> >>
> >>
> >>
> https://en.wikipedia.org/w/index.php?title=Ben_Tre&curid=1822927&diff=565439119&oldid=561995413
> >>
> >>
> https://en.wikipedia.org/w/index.php?title=Celton_Manx&curid=28176434&diff=565439020&oldid=565436056
> >
> >
> > You are correct, but this is not a dirty diff.  I dont want to claim
> this is
> > an user error entirely  -- but a combination of user and software error.
> >
> >
> >> Here is three edits to try to add a section header and a sentence,
> >> with a wikilink in the section header.
> >> (In the process they added other junk into the page, probably
> >> unintentionally.)
> >>
> >>
> >>
> https://en.wikipedia.org/w/index.php?title=Port_of_Davao&action=history&offset=2013072307&limit=4
> >
> >
> > What is the problem here exactly?  (that is a question, not a challenge).
> > The user might have entered those newlines as well.
> >
> >
> >> A leading line feed in a parameter - what the?
> >>
> >>
> >>
> https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&curid=39469556&diff=565437324&oldid=565416618
> >
> >
> > This is something I'll have to investigate.
> >
> >
> >> External links which should be converted to internal links:
> >>
> >>
> >>
> https://en.wikipedia.org/w/index.php?title=Krishna_%28TV_series%29&diff=565437699&oldid=564621100
> >
> >
> > This could be an enhancement to Parsoid.  Thanks for the bug report :-).
> >
> >
> >> That is all in the last hour, and I've only checked ~100 diffs.
> >>
> >> I appreciate that some of these are a result of user input, and the RC
> >> feed of non-VE edits will have similar problems exhibited by newbies,
> >> albeit different because it is the source editor.  And it is great to
> >> see so many constructive VE edits.
> >
> >
> > Thank you for acknowledging this!
> >
> >
> >> But you're not going to get much
> >> love by claiming that it is now stable and not causing broken diffs.
> >
> >
> > I did not make that specific claim, but it is possible that my tone was
> more
> > aggressive than I intended it to be.  Just so there is no confusion,
> > VE/Parsoid can still cause dirty/broken diffs, but I think the claim is
> that
> > at this time, the vast majority of ongoing edits do not corrupt wikitext
> > source and where there are diffs, we have narrowed that down to a couple
> of
> > causes (where VE/Parsoid inserts nowiki wrappers) which are being fixed.
> >
> >
> >> In addition, VE can crash a Google Chrome tab, and it can cause
> >> (unsaved changes) dataloss in most browser configurations.
> >
> >
> > Subbu.
> >
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Daniel Barrett-3
Risker asks:
>Why do you think those <nowiki> tags were added by the editors?

I can't speak for the original poster, but the last time I used VE,
it added unwanted <nowiki> tags by itself.
You can see an example in my most recent bug report:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51829

DanB
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tyler Romeo
Please change the subject and use a different thread if you intend to
discuss the usefulness or accuracy of VE, because as I just said, that's
not the subject of this thread.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | [hidden email]


On Tue, Jul 23, 2013 at 3:44 PM, Daniel Barrett <[hidden email]> wrote:

> Risker asks:
> >Why do you think those <nowiki> tags were added by the editors?
>
> I can't speak for the original poster, but the last time I used VE,
> it added unwanted <nowiki> tags by itself.
> You can see an example in my most recent bug report:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=51829
>
> DanB
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: VE and <nowiki>

Steve Summit
In reply to this post by Risker
Risker wrote:
> On 23 July 2013 15:32, Robert Rohde <[hidden email]> wrote:
>> * Corrupted page content that appears to be caused by the unfamiliar
>> UI (e.g. <nowiki>[[Foo]]</nowiki>)
>
> Why do you think those <nowiki> tags were added by the editors?

I assume that since it's VE's job to be wysiwyg, and to insulate
the user from the low-level markup details, any time anyone
forgets they're in VE and attempts to create a link by
reflexively typing

        [[pagename]]

VE will (correctly, from its point of view) translate that to
"<nowiki>[[pagename]]</nowiki>" in the page source.

This is a likely enough mistake, and the number of times you
really want explicit double square brackets is small enough, that
it's worth thinking about (if it hasn't been already) having VE
detect and DTRT when a user types that.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Roan Kattouw-2
In reply to this post by Daniel Barrett-3
On Tue, Jul 23, 2013 at 12:44 PM, Daniel Barrett <[hidden email]> wrote:
> Risker asks:
>>Why do you think those <nowiki> tags were added by the editors?
>
> I can't speak for the original poster, but the last time I used VE,
> it added unwanted <nowiki> tags by itself.
> You can see an example in my most recent bug report:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=51829
>
Of course those <nowiki> tags weren't added by the editors, VE doesn't
let you do that directly. What I think Robert was talking about
(thanks for that analysis, BTW!) is edits where the user typed
something like "[[Foo]]" into the editor, and Parsoid, in order to
achieve a truthful rendering of "[[Foo]]", wraps it in <nowiki> tags.
That's a case of "we did what the user asked us to do, although the
user probably didn't mean that". To counter this, there's a
notification bubble that appears as soon as you type something that
looks like wikitext. However, there's a bug that's causing this
notification to appear at the top of the page and so if you're
scrolled down more than a little bit, you'll probably never see it. We
intend to fix this today or tomorrow so that everyone who types in
wikitext will see this warning. It typically displays in the close
vicinity of, or even on top of, the save button, so it should be
pretty hard to miss once the positioning bug is fixed.

The heading bug where you get ==<nowiki />== is a separate issue. This
happens when you blank a heading (or try to remove it but don't quite
succeed) and leave an empty heading behind. VE then sends an empty
heading to Parsoid, which very diligently puts in a nowiki tag so you
get the empty heading you supposedly wanted. These kinds of
technically-correct-but-probably-not-what-you-wanted issues are a bit
tricky. They're on our list of things to deal with though.

Roan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: VE and <nowiki>

Roan Kattouw-2
In reply to this post by Steve Summit
Whoops, didn't realize this thread had been forked off while I was out
to lunch, and so I responded to the other thread. Sorry about that :(

On Tue, Jul 23, 2013 at 1:11 PM, Steve Summit <[hidden email]> wrote:
> This is a likely enough mistake, and the number of times you
> really want explicit double square brackets is small enough, that
> it's worth thinking about (if it hasn't been already) having VE
> detect and DTRT when a user types that.
>
VE does detect this and warn the user, but there's a bug that makes
the warning bubble appear out of view if you're not scrolled all the
way up to the top. One of our team members is working on fixing that
right now.

Roan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123456