With the new painting setup, StCaretHider is completely worthless.

More background: As far as I can tell, StCaretHider used to be needed because we painted the caret using some XOR magic ... a regular paint would not necessarily paint the caret correctly, and scrolling could mess things up somehow. But these days we only ever paint from the refresh driver so there's no way we could disturb the window during the scope of an StCaretHider.

Comment on attachment 675405 [details] [diff] [review] There is no point in checking for the existence of a caret in the presshell Looks good to me, r=mats I did notice one minor "regression" though for this content: data:text/html,<input readonly value="value">body text If you put the document in caret browsing mode (F7), and click on "body text" (caret is displayed - ok), and then click on "value" => caret does not move, so it looks like the <input> isn't focused at all, although it is. If you type Shift+LEFT to select some <input> text then the caret is erased. "regression" in quotation marks because the above STR doesn't really work perfectly now either... but with these patches it's slightly worse. So please file a follow-up bug on this. Also, it might be possible to remove nsCaret::mIgnoreUserModify now. I think it was only used to workaround some paint issue for "View Source" (in bug 394473).

Filed bug 806278.

https://hg.mozilla.org/integration/mozilla-inbound/rev/911658ea401e https://hg.mozilla.org/integration/mozilla-inbound/rev/f31f3948e433

https://hg.mozilla.org/mozilla-central/rev/911658ea401e https://hg.mozilla.org/mozilla-central/rev/f31f3948e433