Page MenuHomePhabricator

VisualEditor should fire an event on opening to allow other scripts to clean up
Closed, DeclinedPublic

Description

Upon loading, VisualEditor removes some DOM nodes to get rid of elements that only make sense for article view (including the article content itself but also gadgets etc). That does not always work (see T120443); also some scripts might have event subscriptions or timeouts they should release, requests to cancel, or maybe they use a lot of memory which they might want to free up. There should be a "content unload" event that such scripts can subscribe to, fired by VE when it removes the content.

(A "content load" event is also needed for when VE is saved / cancelled, BUT AFAIK wikipage.content works for that.)

Event Timeline

Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added a project: VisualEditor.
Tgr added a subscriber: Tgr.

Politely, I'm unconvinced that this is a good idea. We intentionally do not use hooks. Starting now to help extensions and gadgets clean up after themselves (rather than not breaking things in the first place) doesn't fill me with love.

Politely, I'm unconvinced that this is a good idea. We intentionally do not use hooks. Starting now to help extensions and gadgets clean up after themselves (rather than not breaking things in the first place) doesn't fill me with love.

How should extensions and gadgets behave, to not be considered broken?

VE doesn't remove any DOM nodes, it hides the article content node and replaces it with Parsoid HTML content. If the edit is abandoned we reshow the original article DOM without modification.

Jdforrester-WMF changed the task status from Open to Stalled.Jan 22 2016, 7:21 PM
Esanders claimed this task.

We actually have a hook that fires on activation: ve.activationComplete, but it should be used sparingly. Edit mode does not need to be identical to read mode, nor have much of it's interactivity. It gadgets ran blindly ran in both read and edit mode they'd likely cause more problems than they fix - for example modifying any of the DOM outside of ce=false focusable nodes would be problematic - and adding interactivity to them would be pointless as they are shielded from interaction anyway.