Page MenuHomePhabricator

VisualEditor: Re-run wikipage content handlers (jquery.makeCollapsible, jquery.tablesorter) when rendering new revision after save
Closed, ResolvedPublic


At the moment, the VE's refresh after save isn't a full refresh - it refreshes "in place", using the parsoid DOM. This isn't something things like gadgets or site JS recognise, and so the reloaded page lacks power user functionality. Save should simply refresh the page cleanly to avoid this issue.

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:11 AM
bzimport set Reference to bz51565.
  • Bug 51568 has been marked as a duplicate of this bug. ***

No, we should not refresh because of this. This is not a new bug, this is a known issue in mediawiki core for years with "live preview".

The difference being that in 2013 (unlike several years ago when live preview came along) we have solved this. Recently I developed mw.hook in core with an event "wikipage.content". Gadgets should listen to that instead of document-ready.

Refreshing for every rendering is not a solution but a work around to have the native browser document trigger "ready" again. The solution is to have these wikipage (not html document) related actions be bound to its ready event and be able to fire that on-demand if the wiki page has changed (e.g. due to ajax navigation, live preview or page rendering like VisualEditor).

This has been solved and it is up to gadgets to start using it.

I'm rephrasing this bug to instead be a task for VisualEditor to start using this event (like LivePreview does in core).

Change 74313 had a related patch set uploaded by Krinkle: Use wikipage.content instead of domready

We may need this to fire when we re-render parts of the document in editing mode, e.g. you are using the Math extension with JS rendering (MathJax), or you re-render a template containing a makecollapsible.

Some cases (e.g. navigation popups) may not want to fire in editing mode. I'm not sure if that's best done with a separate hook, or just by making the listener check the mode.

Change 74313 merged by jenkins-bot: Use wikipage.content instead of domready

This hook will not fire in VisualEditor's editing mode. Nodes are protected and don't allow interaction anyway.

These hooks are for enhancements. Anything that's required for display should be handled by VisualEditor's ContentEditable node implementation (e.g. including Timeline, Math, etc.).

Change 76751 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Fire 'wikipage.content' hook after saving

Change 76751 merged by jenkins-bot:
mw.ViewPageTarget: Fire 'wikipage.content' hook after saving

This is now merged and will be deployed later today.

Javascript (or at least navigation popups) are again not working after a page is saved but do work when the page is reloaded.

To test:

  1. Enable the navigation popups gadget
  2. View any page editable in VE
  3. Hover over any link to see a popup
  4. Load the page in VE and save an edit (it doesn't mater what)
  5. Hover over any link and fail to see a popup.
  6. Reload the page, hover over the link and see a popup

The code of the gadget is not using the 'wikipage.content' hook introduced to fix bug 30713 (and added to VE on Gerrit Change 76751):

I've made a request for this on its talk page:

Hmm... Visual editor still doesn't call MathJax after saving the page (all I see is the source code of the formulas, e.g. $ \mathbb{N} $).

That's because the Math extension doesn't support this yet; see bug 36060.