Page MenuHomePhabricator

Live preview should be disabled if it can't preview the current content (user scripts specifically)
Closed, ResolvedPublic

Description

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]].


Version: 1.21.x
Severity: normal

Details

Reference
bz43981

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 1:15 AM
bzimport set Reference to bz43981.
Rillke created this task.Jan 15 2013, 4:36 AM

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. ***