Last modified: 2013-01-15 19:24:18 UTC
On user script pages, users are advised to > Use the "Show preview" button to test your new JavaScript before saving. This does not work if wpuselivepreview is enabled in [[Special:Preferences]].
> Live preview should either hide #mw-userjsyoucanpreview I don't like killing off features like this. > or inject/eval the javascript to be previewed Not gonna work, this is guaranteed to cause funny issues like buttons appearing twice. I think LivePreview should just turn itself off in presence of #mw-userjsyoucanpreview. This would be easy to do.
(In reply to comment #1) > I think LivePreview should just turn itself off in presence of > #mw-userjsyoucanpreview. This would be easy to do. Change I8750448c submitted, for both JS and CSS preview.
(In reply to comment #1) > > Live preview should either hide #mw-userjsyoucanpreview > > I don't like killing off features like this. > Are you reading the same thing? He is suggesting we hide a messages during live preview. A message a simple message. A message that is incorrect when using live preview. Nothing strange about that.
Uh, yes, but using live preview here disables the feature of previewing how your JS and CSS would work. My patch reenables that by disabling live preview, which is useless in this case anyway.
Live preview is an experimental feature with heaps of lackings and issues. The purpose of live preview is to do what preview does but without the refresh. So: * Not hiding #mw-userjsyoucanpreview * Unloading the user module from the queue * Implement inline a customised version with mw.loader.implement, implementing all pages of the user module except for the one being edited right now and add the submitted text in its place. This logic is already in place on the server, we need to reproduce it on the client. Though as Bartosz mentioned, this has one side-effect, namely that in case of live preview we can't unload a module from the queue because it is already executed. You can't "undo" that. So in this case it is probably best to not reproduce the regular behaviour but disable live-preview. For properly previewing javascript edits we need a refresh.
(In reply to comment #5) > Though as Bartosz mentioned, this has one side-effect, namely that in case of > live preview we can't unload a module from the queue because it is already > executed. You can't "undo" that. (In reply to comment #2) > Change I8750448c submitted, for both JS and CSS preview. For CSS we can actually implement live preview. CSS can be unloaded in browsers. We just delete the stylesheet from the document. Rendering is live.
(In reply to comment #6) > (In reply to comment #2) > > Change I8750448c submitted, for both JS and CSS preview. > > For CSS we can actually implement live preview. CSS can be unloaded in > browsers. We just delete the stylesheet from the document. Rendering is live. While this is true, live preview currently doesn't do that, so disabling it is an improvement over the current situation. And while possible, I think it would require reimplementing some server-side logic. (I should have clarified that in the commit message.)
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #2) > > > Change I8750448c submitted, for both JS and CSS preview. > > > > For CSS we can actually implement live preview. CSS can be unloaded in > > browsers. We just delete the stylesheet from the document. Rendering is live. > > While this is true, live preview currently doesn't do that, so disabling it > is an improvement over the current situation Sure, by all means. > And while possible, I think it would require reimplementing some server-side > logic. No. Change-Id: I8750448c827eb965509158bb4a0cd8b0cf3c7a67
*** Bug 41655 has been marked as a duplicate of this bug. ***
