Last modified: 2013-11-03 23:24:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T53565, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 51565 - VisualEditor: Re-run wikipage content handlers (jquery.makeCollapsible, jquery.tablesorter) when rendering new revision after save
VisualEditor: Re-run wikipage content handlers (jquery.makeCollapsible, jquer...
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
MediaWiki integration (Other open bugs)
unspecified
All All
: Normal normal
: VE-deploy-2013-08-15
Assigned To: Krinkle
:
: 51568 (view as bug list)
Depends on: 30713
Blocks: 51664
  Show dependency treegraph
 
Reported: 2013-07-17 19:02 UTC by Oliver Keyes
Modified: 2013-11-03 23:24 UTC (History)
15 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Oliver Keyes 2013-07-17 19:02:32 UTC
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.
Comment 1 Chris McKenna 2013-07-17 19:14:07 UTC
*** Bug 51568 has been marked as a duplicate of this bug. ***
Comment 2 Krinkle 2013-07-17 19:33:01 UTC
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).
Comment 3 Gerrit Notification Bot 2013-07-18 01:39:29 UTC
Change 74313 had a related patch set uploaded by Krinkle:
mediawiki.page.ready: Use wikipage.content instead of domready

https://gerrit.wikimedia.org/r/74313
Comment 4 Ed Sanders 2013-07-18 19:33:47 UTC
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.
Comment 5 Matthew Flaschen 2013-07-19 22:52:34 UTC
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.
Comment 6 Richard Morris 2013-07-20 17:54:07 UTC
It also affects the MathJax renderer see http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Minor_redisplay_glitch
Comment 7 Gerrit Notification Bot 2013-07-26 00:18:17 UTC
Change 74313 merged by jenkins-bot:
mediawiki.page.ready: Use wikipage.content instead of domready

https://gerrit.wikimedia.org/r/74313
Comment 8 Krinkle 2013-07-30 16:26:56 UTC
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.).
Comment 9 Gerrit Notification Bot 2013-07-30 17:58:17 UTC
Change 76751 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Fire 'wikipage.content' hook after saving

https://gerrit.wikimedia.org/r/76751
Comment 10 Gerrit Notification Bot 2013-07-30 20:47:29 UTC
Change 76751 merged by jenkins-bot:
mw.ViewPageTarget: Fire 'wikipage.content' hook after saving

https://gerrit.wikimedia.org/r/76751
Comment 11 James Forrester 2013-07-30 21:10:58 UTC
This is now merged and will be deployed later today.
Comment 12 Chris McKenna 2013-08-22 15:28:37 UTC
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
Comment 13 Helder 2013-08-24 00:23:30 UTC
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
Comment 14 Helder 2013-11-03 10:20:47 UTC
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} $).
Comment 15 Bartosz Dziewoński 2013-11-03 11:26:49 UTC
That's because the Math extension doesn't support this yet; see bug 36060.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links