Community
Participate
Working Groups
When I save a mediawiki file I'm editing (in the edit tab) and I switch to the Preview tab, the scrollbar jumps to the beginning of the preview (html) document. This is annoying whenever editing a section that is not at the beginning of the document. To prevent this, maybe the MarkupEditor could save and restore the position of the scrollbar when refreshing the document during the save: int verticalScrollbarPos = editorWidget.getVerticalBar().getSelection(); ... editorWidget.getVerticalBar().setSelection(verticalScrollbarPos); editorWidget.getVerticalBar().notifyListeners(SWT.Selection, new Event());
The intended behaviour when updating the preview is to scroll to the region that corresponds to the caret position or selected text in the source editor. The idea is that the author is most likely interested in the preview for the portion of the document that was most recently viewed/modified in source form. Is the preview scrolling to the top only when document is saved, or does it happen all of the time?
Created attachment 202548 [details] mylyn/context/zip
(In reply to comment #1) > The intended behaviour when updating the preview is to scroll to the region > that corresponds to the caret position or selected text in the source editor. I'm surprised. I've never seen the editor do this. > Is the preview scrolling to the top only when document is saved, or does it > happen all of the time? Yes, it happens all the time when switching to the Preview tab after editing in the Mediawiki Source tab.
After looking deeper I can see that this behaviour was disabled on the Windows platform due to differences in how IE handles JavaScript (see related bug 270293). I've pushed a fix for it to Git, please let me know if that fixes your problem. Note that scrolling occurs to the nearest heading -- if you have lots of text without headings it may not work as expected.
Created attachment 202628 [details] mylyn/context/zip
Created attachment 204944 [details] patch Here is a patch that I propose to fix the problem. With this patch, when I save in the source tab and click on the preview tab, my previous position in the preview is restored. And when I open the same markup editor twice (using "Window > New Editor"), with the source editor on the left and the preview editor on the right, when I save in the source editor I see my changes in the preview editor without any vertical position change.
Nicolas, looks like a great approach! What platform/browsers have you tested this with? Also, would it make sense to move revealItem() back into the progress listener? It looks like there could be a race condition where the browser might not have finished loading the new content before it's asked to reveal the item.
Created attachment 205007 [details] patch v2 (In reply to comment #7) > What platform/browsers have you tested this with? I have tested this on my system only : Windows 7 x64. It uses Internet Explorer for the SWT Browser (judging by the context menu and properties), but I don't know which version. Probably 9.0 which I have installed. I have tried executing this bit of javascript in IE, Firefox and Google Chrome: javascript:window.scrollTo(0,100); It works in all three browsers. I have tried this as well: javascript:alert(document.body.scrollTop); But it doesn't work in all browsers. It works in Chrome, but not in Firefox nor in IE (strangely, since it works in the integrated browser) So I adapted the patch to handle all browsers, according to: http://stackoverflow.com/questions/871399/cross-browser-method-for-detecting-the-scrolltop-of-the-browser-window I tested in IE, Firefox and Google Chrome, and this code works in all three browsers. > Also, would it make sense to move revealItem() back into the > progress listener? It looks like there could be a race condition where the > browser might not have finished loading the new content before it's asked to > reveal the item. I don't understand how that would happen. The code to restore the vertical position is in ProgressAdapter#completed, which is only called when the browser has finished loading.
Thanks for the updated patch, it looks good. Pushed review: http://review.mylyn.org/81
There's some loss of functionality with this patch. Please see comments on the review: http://review.mylyn.org/81
I haven't found a way to reconcile the two mechanisms. Maybe a new preference could be made: to either keep the existing behavior (try to jump to the edited section), or always keep the user's position in the document. What do you think?
I'd hate to see a new preference for something like this. How about this for an idea: we could give every block (paragraph, div, table, etc.) an ID in the generated HTML. When switching to the preview we could scroll to the block corresponding to the current caret position in the editor.
(In reply to comment #12) > How about this for an idea: we could give every block (paragraph, div, table, > etc.) an ID in the generated HTML. When switching to the preview we could > scroll to the block corresponding to the current caret position in the editor. This is a good way to improve the current implementation. But as a user, I don't like the wikitext editor to try to decide what I want to see. For example, I am currently working with diagrams (as images in the wikitext) with a description below. While I am editing the description, I want to see the diagram at the same time. But if the wikitext editor scrolls to the beginning of the text paragraph, the image will get out of the screen and I will lose my context. Since I believe it is impossible for the wikitext editor to always find the best part of the content to display, I would prefer to decide it for myself and let the editor get out of my way. This is a way of empowering users by giving them control over things they are in the best position to decide. So, a way your idea could be implemented while leaving the user in control: - in the Edit tab, add a context menu action "Edit this paragraph" : clicking this would both switch to the edit tab and scroll to the corresponding paragraph - in the Preview tab, each paragraph could have an "edit" link (like on Wikipedia). Clicking this link would switch to the corresponding position in the Edit tab.
(In reply to comment #13) That's a good point Nicolas. The current implementation was designed as a crutch to overcome scrolling being reset to the top of the document each time the preview was updated. That was anoying for obvious reasons. I like your ideas for making it more edit-friendly. How about this for an approach: * we go with the maintain-current-scroll-position approach of your patch * we add a context menu to the editor, something like "Preview here" that opens the preview tab and scrolls as near as possible to the caret position * users can continue to use the outline view to scroll the preview Adding "edit this paragraph" links is a good idea. We should look at the implementation carefully, since we don't want to alter the preview too much. Perhaps an "edit this paragraph" link that only displays on hover would do the trick. We could consider this one as a future enhancement if it's too much to take on right away.
(In reply to comment #14) > * we go with the maintain-current-scroll-position approach of your patch > * we add a context menu to the editor, something like "Preview here" that opens > the preview tab and scrolls as near as possible to the caret position > * users can continue to use the outline view to scroll the preview I think this is a good approach.
*** Bug 362090 has been marked as a duplicate of this bug. ***
Patch applied, thanks Nicolas! Summary of work done: * patch applied - scroll position is restored whenever the preview content is updated * context menu action added in source editor: *Preview at "Heading Name"* causes switch to preview tab, scrolls to reveal heading
Created attachment 206158 [details] mylyn/context/zip
