Last modified: 2006-03-02 02:04:12 UTC
It would be a nice useability enhancement to also remember the position of the textarea's scrollbar between preview requests of a page. Say I've entered many lines of text and work currently somewhere in the middle of the text, upon preview of the page, the scrollbar ist always at the top. An implementation would need to rely on JavaScript. Before the page (form) is submitted for preview, the scrollTop position is read and written into a already existing hidden input field which is then written back to the client as JavaScript statement to the textarea so it positions itself to the old position.
Created attachment 294 [details] Patch for remembering scrollTop in Preview-Mode This patch gives basic support for remembering the scrollTop position on the preview page. How it works: 1. It creates a new property $jsScrollTop in EditPage, initially set to 0 2. If EditPage is showing a preview, the $jsScrollTop is set from the Request 3. If we're previewing a page and $jsScrollTop > 0 , add the necessary body onload Handler to set the scrollTop value on the textarea, once the page is loaded 4. Adds a handleEditformSubmit JS function which gets triggered when "editform" is submitted (currently does make no distinction whether it's a preview or not) 5. Adds a input type="hidden" field which holds the jsScrollTop value 6. Lets SkinTemplate.php set the body onload handler (this was missing before anyway) 7. Enabled the body onload handler in skins/MonoBook.php (was missing, too)
Created attachment 299 [details] Cleaned up patch, moved JS code to wikibits This is like the first patch, with the following things changed: 1. Moves the JS-handler to skins/common/wikibits.js 2. More carefully checks if all the elements required for making this feature work are there. I've tested in successfully on Windows with: IE 5.0+ Netscape 7.1+ Mozilla 1.7.3+ Firefox 1.0 In Opera (7.54u2), the scrollTop property can be read and will be submitted and later set in onload, but this scrollbar of the textarea doesn't refelect the change (though re-reading the property tells the newly set value). In all other browsers the feature did not work but didn't cause any troubles (javascript errors, abort of submit) either. One thing I've spotted: Since I've enabled the onload-Handler in the (default) Template, the "document.editform.wpTextbox1.focus()" handler (EditPage.php, line 583) will start working too, which was not ran until now. In any circumstance both onload-Handlers will get fired, my new handler would overwrite the previous one (no logic of stacking handlers at PHP level like with addEventListener.
I like this idea. The patch should probably use the existing javascript function addOnloadHook from wikibits.js instead of altering Monobook.php.
It most likely should. When I came up with the patch, there was no addOnloadHook in the stable release back then. Since I'm running still the same version of MediaWiki I'm currently not able to create a new patch, I hope someone else can. This is really useful and I'm still happy every day that I wrote it ;)
It turns out that this feature has been in Mediawiki since October 2005 :-)
