Trigger style recalc when the window's active state change

Source/core/editing/FrameSelection.cpp

Index: Source/core/editing/FrameSelection.cpp
diff --git a/Source/core/editing/FrameSelection.cpp b/Source/core/editing/FrameSelection.cpp
index b2948ef0d254de143ce815d6e4c9383fec615569..91434f7b6572eae154c737b6a3a7b859aacbda81 100644
--- a/Source/core/editing/FrameSelection.cpp
+++ b/Source/core/editing/FrameSelection.cpp
@@ -1466,6 +1466,11 @@ void FrameSelection::focusedOrActiveStateChanged()
     RefPtrWillBeRawPtr<Document> document = m_frame->document();
     document->updateRenderTreeIfNeeded();

[rune, 2014/12/08 23:14:26]

Updating the render tree synchronously immediately before invalidating the
custom scrollbars looks wrong.

Why do we need a synchronous render tree build here at all? It looks like it's
for RenderView::invalidatePaintForSelection below.

What happens if you have a scrollbar pseudo rule that sets the scrollbar to a
different width for :window-inactive? Will the selection invalidation be correct
if the selected text is reflowed at a different width due to the wider/narrower
scrollbar?

[MuVen, 2014/12/09 09:33:07]

the text reflow has been solved earlier for the custom-scrollbar on width
changed. When there is change in CS thickness the RenderBox is set for layout
and the width available for the children is changed is mentioned during
RenderBlock width calculation. 

PTAL @ https://codereview.chromium.org/708283002/.

I have added custom-scrollbar-thumb-width-changed-on-inactive-pseudo.html
testcase for the same.

[rune, 2014/12/09 10:36:33]

But this still doesn't look right. You do:

  updateRenderTreeIfNeeded()
  invalidateAllCustomScrollbarsOnActiveChanged()
  invalidatePaintForSelection()

invalidateAllCustomScrollbarsOnActiveChanged may change the render tree, so why
not do this?:

  invalidateAllCustomScrollbarsOnActiveChanged()
  updateRenderTreeIfNeeded()
  invalidatePaintForSelection()

invalidateAllCustomScrollbarsOnActiveChanged may also require a layout that
708283002 introduces. Also since invalidatePaintForSelection() wants to work on
an up-to-date layout, I wonder why we just do an updateRenderTreeIfNeeded and
not an updateLayout. Ultimately, I think we want to do render tree changes and
layout for scrollbars and selection at the next frame display.

[MuVen, 2014/12/09 10:44:20]

true. It makes sense for me, Ideally updateRenderTreeIfNeeded should be after
invalidating CustomScrollbar.

 
+    // Invalidate All CustomScrollbars as CustomScrollbars supports
+    // CSS window-active attribute.
+    if (FrameView* view = document->view())
+        view->invalidateAllCustomScrollbarsOnActiveChanged();

[rune, 2014/12/08 23:14:26]

This is still called unconditionally even when there is no :window-inactive
selector present. Did we end up saying this was cheap enough? This can be a lot
of scrollbar parts in the worst case, right?

[MuVen, 2014/12/09 09:33:07]

True. I would like to optimise this in my next patch if its ok for you ?

[rune, 2014/12/09 10:36:33]

Sure.

+
     // Because RenderObject::selectionBackgroundColor() and
     // RenderObject::selectionForegroundColor() check if the frame is active,
     // we have to update places those colors were painted.