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
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T53664 VisualEditor: Surface should respect the default state of collapseable templates | |||
| Resolved | Krinkle | T53565 VisualEditor: Re-run wikipage content handlers (jquery.makeCollapsible, jquery.tablesorter) when rendering new revision after save | |||
| Resolved | Krinkle | T32713 Add mw.hook event for wikipage content ready | |||
| Resolved | Krinkle | T25580 Implement JavaScript mw.hooks framework |
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:
mediawiki.page.ready: 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.
It also affects the MathJax renderer see http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Minor_redisplay_glitch
Change 74313 merged by jenkins-bot:
mediawiki.page.ready: 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
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:
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):
https://en.wikipedia.org/wiki/MediaWiki:Gadget-popups.js
I've made a request for this on its talk page:
https://en.wikipedia.org/wiki/MediaWiki_talk:Gadget-popups.js#Use_the_.27wikipage.content.27_hook
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} $).