Hi James, the google consensus seems to be that a DivX plugin is inserting that.

http://padawan.info/en/2011/03/wtf-is-this-myeventwatcherdiv-doing-in-my-web.html

I'm guessing that VE's interface suddenly looks like something the plugin was expecting to use in the browser, and so it silently adds the div.

We could add an abusefilter rule to block those edits, but that seems a little drastic.

yeah, that seems to be the consensus I could find too (which is very very weird... because I can't for the life of me find a 'legitimate' reason it should insert that into any page it can edit.. oh well certainly not the weirdest plugin BS I've seen).

Actually I don't think that's very drastic to do, the community almost certainly would agree and I'd pass it off to them (though they'll likely blame us for it which is never fun). It's certainly a type of edit we really don't want but more importantly I'm confused about how it's getting inserted and avoiding the normal VE/parser work flow which should <nowiki> it (instead of actually inserting it in as a div like it is now).

(In reply to comment #1)

Hi James, the google consensus seems to be that a DivX plugin is inserting
that.

http://padawan.info/en/2011/03/wtf-is-this-myeventwatcherdiv-doing-in-my-web.
html

I'm guessing that VE's interface suddenly looks like something the plugin was
expecting to use in the browser, and so it silently adds the div.

We could add an abusefilter rule to block those edits, but that seems a
little drastic.

Ideally we'd want a global AbuseFilter rule that just silently dropped the content from the edit, but that's not a feature AF currently does. :-)

Blocking is a bit strong, though possibly likely to happen from the community if we just warn users and they ignore. The only fix (other than getting the upstream plugin crap fixed, which seems unlikely) is to do the auto-drop in VE, which is icky too.

(In reply to comment #2)

I'm confused about how it's getting inserted and
avoiding the normal VE/parser work flow which should <nowiki> it (instead of
actually inserting it in as a div like it is now).

It looks like it's bypassing the browser's events model and just inserting into the DOM, hence the issue. JS like VE isn't able to notice things outside the JS events model, sadly.

(In reply to comment #2)

It's certainly a type of edit we really don't
want but more importantly I'm confused about how it's getting inserted and
avoiding the normal VE/parser work flow which should <nowiki> it (instead of
actually inserting it in as a div like it is now).

It's possible that the plugin inserts it in all <iframe>s. We use <iframe>s internally for encapsulating HTML documents.

Making this public since I don't see this having any security impact. Then the community can also give input into how they want to see it handled.

(In reply to comment #6)

Making this public since I don't see this having any security impact. Then
the
community can also give input into how they want to see it handled.

Thanks Chris

As a workaround for now we could make VE remove those divs from the HTMLDOM that it is sending to MW API for serializing. @James: Should we do it?

(In reply to comment #8)

As a workaround for now we could make VE remove those divs from the HTMLDOM
that it is sending to MW API for serializing. @James: Should we do it?

You mean, have a blacklist of items to just silently remove on save? Could work as a quick hack.

Silently remove on save. Hacking blacklist will prevent people from saving and many of them are not technical enough to understand why - bad bad user experience.

On it.wp as well: http://it.wikipedia.org/w/index.php?title=Tank_Palamara&diff=60582899&oldid=60582688

I am also curious to know why it only happens to anonymous editors - at least, all the occurrences I have seen so far.

@James: Should we go for silent remove on safe? Also we can start tracking it with information about logged in vs. logged out user.

for the record it happened in fr.wp : https://fr.wikipedia.org/w/index.php?title=Les_Fourmis_%28Werber%29&diff=96415737&oldid=89791930

Detected and warning issued by the abuse filter http://en.wikipedia.org/wiki/Special:AbuseFilter/485

Sorry meant http://en.wikipedia.org/wiki/Special:AbuseFilter/345

(In reply to comment #16)

Sorry meant http://en.wikipedia.org/wiki/Special:AbuseFilter/345

Thanks - though we should probably silently remove on save inside VisualEditor, like Inez suggests.

Has anyone here managed to actually get this to happen in their browser yet? James tried the DivX plugin in Safari on his Mac and couldn't get it to insert the bad content.

Change 163961 had a related patch set uploaded by Alex Monk:
Remove certain blacklisted elements when getting HTML from document

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

Change 163961 merged by jenkins-bot:
Remove certain blacklisted elements when getting HTML from document

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

Still seems to be happening, e.g. https://fr.wikipedia.org/?diff=108255165

This task has VE-deploy-2014-10-02 but is still open. Should this be retargetted?