Because the scrollbar position in the editing views does not have any relationship with what will be displayed in the embedded copy of IE in Browser Preview we can't simply tell IE to scroll down the same distance. That might get you close, but only if the output is virtually identical to how the XML is styled for editing. Even something as simple as being in TagsOn vs Normal is going to mess that up because the tags take up room that isn't normally going to be in any output.
People (people that customize the product) are free to set up Browser Preview to produce literally any output format. Even if you are producing HTML or PDF (probably the two most common outputs) with output content that is very similar to the XML being edited any styling differences (font sizes, line spacing, etc) will throw things off.
The one output format I can think of that might allow this to work would be HTML because it is possible to reference a portion of an HTML document using the "name" attribute on an
<a> element. A few things would need to be done (and work) for this to always take you to the right spot:
1) IE supports addresses in the form
filename.html#somevalue and will scroll to the portion of the document containing
<a name="somevalue"> in the HTML source. I'm not sure an embedded copy of IE will support this type of address however. If it doesn't, and only a full-blown copy of IE (with its full UI displayed) could be configured to render the preview instead (we have alternate APIs that help with that).
2) The transformation process that is configured for your customization would need to insert <a name="somevalue"> into the HTML. This means altering the XSLT (or whatever else is doing the transformation if XSLT is not being used).
3) Some indicator of the current position in the document would probably need to be stored or figured out before the transformation occurs so that the address passed in #1 could be properly created. In combination with #2 I think this might best be done by inserting a PI at the author's current selection and then designing the XSLT to trigger on that and insert an
<a name/> at that same position in the HTML (or perhaps nearby depending on what the HTML ultimately looks like, it may be that the portion of the XML you have selected is actually dumped and not included in the output at all for example).
If what is being previewed is another output format, like PDF, it might be possible to inject a bookmark into the file, but then you are dependent on the PDF viewer being used to support that and I'm not sure how to tell any particular PDF viewer to open to a particular bookmark (needs research). I have no idea what the solution might be for other output formats if you transform to something else.
So, basically what I'm saying here is that because this is very dependent on the output itself I think it probably makes the most sense to try to address it as part of any customization work.
