Last modified: 2006-03-02 02:04:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1499 - Remember textarea scrollbar position between previews
Remember textarea scrollbar position between previews
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-09 09:11 UTC by Markus Fischer
Modified: 2006-03-02 02:04 UTC (History)
1 user (show)

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


Attachments
Patch for remembering scrollTop in Preview-Mode (3.28 KB, patch)
2005-02-18 00:12 UTC, Markus Fischer
Details
Cleaned up patch, moved JS code to wikibits (3.97 KB, patch)
2005-02-20 16:57 UTC, Markus Fischer
Details

Description Markus Fischer 2005-02-09 09:11:58 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.
Comment 1 Markus Fischer 2005-02-18 00:12:53 UTC
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)
Comment 2 Markus Fischer 2005-02-20 16:57:49 UTC
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.
Comment 3 Lupin 2006-02-04 21:50:36 UTC
I like this idea. 

The patch should probably use the existing javascript function addOnloadHook
from wikibits.js instead of altering Monobook.php.
Comment 4 Markus Fischer 2006-02-05 14:30:34 UTC
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 ;)
Comment 5 Lupin 2006-03-02 02:04:12 UTC
It turns out that this feature has been in Mediawiki since October 2005 :-)

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


Navigation
Links