Previously, we used to scroll the text control's selection into view after a
reframe. This had two problems: it was not precise (in case the selection was
modified by the mouse, for example), and it lead to problems such as bug 629878
if the control's frame was reconstructed because of the control being moved
inside the DOM.
This patch disables that behavior by wrapping the selection scroll function
into nsITextControlFrame::ScrollSelectionIntoView, so that APIs such as
setSelectionRange on the text control's content node can still call it
explicitly (since they actually need this behavior), but other callers of
nsITextControlFrame::SetSelectionRange (such as the nsTextEditorState
object's selection offset restoring mechanism) don't get this behavior as
an undesired side-effect.
* we know all types frames may be cast to at compile time, so instead of extensible GUID IIDs, use a big enum (see nsQueryFrame::FrameIID)
* eliminate all vestiges of refcounting, since frames aren't refcounted
Some frames (SVG frames in particular) still implement nsISupports-derived interfaces, for example nsISVGValue. There is a FrameIID for nsISVGValue that lets you go from a frame to the XPCOM interface, but you can't query back.
r+sr=roc
nsITextControlFrame didn't have an IID the first time around, but this wasn't a compile error because nsITextControlFrame::kFrameIID inherited from nsIFormControlFrame::kFrameIID. I've added a static analysis pass to verify the correct behavior, since I can't figure out a way to make the compiler do it.
--HG--
extra : rebase_source : 4894a2ca0278e2ab92f27459db77165f8348cf41
