With the live preview option enabled, previewing a .js page to test the script does not work. (Interestingly, it works the first time, but not afterwards.)
There isn't really a way to unload the old version of a script; live preview should just disable itself on JS pages.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T41272 Bugs in "Live preview" feature (tracking) | |||
| Resolved | Nardog | T186390 Javascript preview feature broken when live previews are enabled |
@Anomie I wonder how this could work with https://gerrit.wikimedia.org/r/#/c/340768 which adds a way for extensions to influence the preview (and potentially inject Javascript into it).
With, I tested on Wikimedia wikis (Meta). But I imagine live previews behave the same way anyway.
The reason the script runs the first time is the page reloads on the first preview, even with live previews enabled (presumably because the URL needs to change from action=edit to action=submit?)
The Live Preview feature is probably not going to be able to preview CSS or JS edits like the normal preview does. https://gerrit.wikimedia.org/r/#/c/340768 isn't going to affect that.
(and potentially inject Javascript into it).
Not really. The patch allows an extension to generally replace the content of some wiki page that ResourceLoader is going to load and serve anyway, replacing the old hack that was specific to editing user CSS and JS pages. It doesn't introduce any new ability to add different RL modules or inject JS in other ways.
The old hack only applied to user CSS/JS subpages, and the patch adds a generic method for using the preview value of the currently edited page, no matter what kind it is (e.g. a gadget JS file). So, before the patch one could use Title::isCssJsSubpage or Title::isJsSubpage to determine when special behavior is needed to avoid this bug, or T186391, but with the patch that's not sufficient anymore. It would make sense to expose something similar to ResourceLoaderWikiModule::shouldEmbedModule, IMO.
@Tgr Can you clarify what the behavior should be? That user CSS/JS will preview the normal, non-Ajax way even if live preview is turned on in Preferences, even after the first time?
Change 626846 had a related patch set uploaded (by Gerrit Patch Uploader; owner: Nardog):
[mediawiki/core@master] LivePreview: Enable live diff, and keep live preview disabled after first preview, on user CSS/JS
Change 626846 merged by jenkins-bot:
[mediawiki/core@master] LivePreview: Enable live diff, and keep live preview disabled after first preview, on user CSS/JS
This may be too trivial for Tech News, but at least the fact live diff now works for user CSS/JS is noteworthy, I think.