Last modified: 2012-08-23 21:41:22 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 T10618, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8618 - Live Preview doesn't reload Edit Summary preview; no way to use standard preview when Live Preview is enabled
Live Preview doesn't reload Edit Summary preview; no way to use standard prev...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.11.x
All All
: Low normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 39272
  Show dependency treegraph
 
Reported: 2007-01-13 01:11 UTC by Elliott Cable
Modified: 2012-08-23 21:41 UTC (History)
8 users (show)

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


Attachments

Description Elliott Cable 2007-01-13 01:11:37 UTC
When you are using Live Preview, the preview of the edit summary doesn't reload along with the page - you have to do a normal, non-live preview for that 
(and there is no way to do a page-reloading preview without unsetting that prefrence checkbox anyway).
Comment 1 Voyagerfan5761 / dgw 2007-09-16 08:15:27 UTC
I can confirm this from my own installation of MW 1.11.0. The Live Preview function only updates the page content. Also, the ability to use standard preview when Live Preview is enabled would be a good thing to have.
Comment 2 Niklas Laxström 2007-09-16 08:37:17 UTC
In my opinion Live preview should be moved to an extensions or removed altogether. It just cannot work properly with the current state of technology and MediaWiki code.
Comment 3 jeremyb 2007-09-16 08:42:26 UTC
"current state of technology"?  elaborate?
Comment 4 Voyagerfan5761 / dgw 2007-09-16 08:44:32 UTC
In my experiences with Live Preview, it renders things quite well, just like the normal preview would. I don't think it should be enabled by default, by any means, but moving it to an extension would be removing functionality that needs only a few small improvements. The Ajax Watch script wasn't really working well in version 1.9, but it's become the default to "on" in version 1.11. Another script that nobody really knew much about until a Bugzilla discussion decided to fix it up and make it work.

----

(In reply to comment #3)
> "current state of technology"?  elaborate?
> 

I agree; what "current state of technology"?
Comment 5 Niklas Laxström 2007-09-16 14:44:26 UTC
> I don't think it should be enabled by default, by any
> means, but moving it to an extension would be removing functionality that needs
> only a few small improvements. The Ajax Watch script wasn't really working well
> in version 1.9, but it's become the default to "on" in version 1.11. Another
> script that nobody really knew much about until a Bugzilla discussion decided
> to fix it up and make it work.

I disagree. The improvements are not few and small but quite big. First of them being working back button and otherwise consistent browser behavior with normal preview. As far as I know there is no easy way to accomplish this without pulling in some JavaScript toolkits.

Second improvement would be identical behavior compared to preview, which means that categories, edit summary previews, language links etc are all updated on preview. This is impossible without altering the skins and other code.
Comment 6 Voyagerfan5761 / dgw 2007-09-16 19:53:35 UTC
(In reply to comment #5)
> I disagree. The improvements are not few and small but quite big. First of them
> being working back button and otherwise consistent browser behavior with normal
> preview. As far as I know there is no easy way to accomplish this without
> pulling in some JavaScript toolkits.
> 
> Second improvement would be identical behavior compared to preview, which means
> that categories, edit summary previews, language links etc are all updated on
> preview. This is impossible without altering the skins and other code.
> 

Why would we need identical behavior to the standard preview? Most modern browsers keep an undo history for each textbox/textarea, and the user could step back and forth in this, clicking preview if desired, to look at previous versions of their edits. And why would we need that? Going back to a previous version of a page, making edits, and standard previewing that page erases all future versions from the browser's cache; using one page with Live Preview keeps the browser undo history all nicely bundled on one page, uninterrupted. It should make it easier to undo things, because users won't need the back button.

Another idea is to have a second, small button that calls a normal preview (created by the Live Preview JS, say, only if that script can function, since browsers that don't support LP fall back to normal anyway). That button could be labeled "View final" or something, and would display a preview that has all changes, including language links. Returning categories is something that needs to be added to the server-side code, to render the box and its links below the main content. Language links and edit summary preview need the script to update multiple divs with different sections of the data. It can be done. If Gmail and Yahoo! Mail beta can use AJAX the way they do, MediaWiki can definitely pull off this Live Preview thing.

PS
enwiki's wikEd editing tool by Cacycle has a good preview algorithm we could start with, and maybe use the diff script, too, since it's easier to read.
Comment 7 Bartosz Dziewoński 2012-08-09 16:49:18 UTC
Patch submitted to gerrit: I4f4f91ed3b51a54b645bca9697c2840b717bddf6
Comment 8 Bartosz Dziewoński 2012-08-23 21:34:55 UTC
Fixed in I4f4f91ed.
Comment 9 Roan Kattouw 2012-08-23 21:41:22 UTC
(In reply to comment #8)
> Fixed in I4f4f91ed.
Merged.

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


Navigation
Links