User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100225 Minefield/3.7a2pre (.NET CLR 3.5.30729) Build Identifier: See attached testcase. When trying to select all the text in the IFRAME, the window does not scroll to allow the offscreen text to be selected. This is a regression from Firefox 3.6. Reproducible: Always Steps to Reproduce: 1. Have IFRAME that is larger than the window. 2. Start a selection in the iframe 3. Move mouse to bottom of screen/window Actual Results: The window does not scroll. Expected Results: The window scrolls to allow more text to be selected.

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=120667a01fd2&tochange=a43e2f7eda8f Looks like a regression from bug 526394.

Comment on attachment 429454 [details] [diff] [review] fix r=mats

Checked in, but backed out because it caused the accessibility test test_caretmove.html to fail on Linux and Windows, e.g.: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1269829304.1269831497.30384.gz

That bustage was revealing a real bug in existing code. We're updating the rect incorrectly.

Comment on attachment 435557 [details] [diff] [review] additional fix r=mats

Is there a followup bug for doing the same for ScrollSelectionIntoView (specifically for the typeahead find selection)?

Since bug 526394, ScrollSelectionIntoView uses nsIPresShell::ScrollFrameRectIntoView, which we're fixing here.

Comment on attachment 429454 [details] [diff] [review] fix > rect += container->GetPosition(); >- container = container->GetParent(); >+ container = nsLayoutUtils::GetCrossDocParentFrame(container); Do we not want to use the second argument of GetCrossDocParentFrame here to include the cross doc offset?

Yes we do, good catch!

http://hg.mozilla.org/mozilla-central/rev/6549437223c3 http://hg.mozilla.org/mozilla-central/rev/4b48094881e1