The React part of Speedometer makes at least 4000 calls to HTMLInputElement::GetSelectionStart on my machine. I know that's not a lot, but we do spend a bunch of time under that flushing layout (just like bug 1339758), so I thought I'd file it anyway. Furthermore, it looks like WebKit does caching again when the element is not the element that has focus: https://github.com/WebKit/webkit/blob/828e57f5e5a7b22ace541e04ae143381cdc475e6/Source/WebCore/html/HTMLTextFormControlElement.cpp#L350-L351 The attached micro-benchmark confirms this I think. I get the following numbers, when clicking on the <input> / <button>: Nightly: 159 ms / 159 ms Chrome: 53 ms / 20 ms Safari: 47 ms / 13 ms This bug is probably not very urgent, but I am curious about the layout flushing again and 3-10 times slower isn't great.

Daniel, here is a bug where we are slower in flushing layout.

Are we actually flushing layout? I see HTMLInputElement::GetSelectionRange calling GetFormControlFrame(true), which will flush frames (but not layout). Then we call nsTextControlFrame::GetSelectionRange which should not flush anything. Then if that fails we will look for a cached selection on the editor state. None of that should involve any flushing. So we should maybe be flushing frames here, but not layout... If we're flushing layout, I'd love to see the stack involved.

OK, so profiling the microbenchmark, which I understand may not match the original testcase, I see 3% of the time under flushing, none of it layout, which is not surprising: there is nothing to flush in the microbenchmark. Total time under GetFormControlFrame is 6% or so. But nsTextControlFrame::GetSelectionRange is 88% of the time. There's some obvious stuff that can be sped up there, which I'll do in bug 1342197.

bz, it's probably my ignorance. Here's the stack: Weight Self Weight Symbol Name 533.00 ms 2.5% 2.00 ms mozilla::dom::HTMLInputElement::GetSelectionStart(mozilla::ErrorResult&) 531.00 ms 2.5% 0 s mozilla::dom::HTMLInputElement::GetSelectionStart(int*) 516.00 ms 2.5% 0 s nsGenericHTMLElement::GetFormControlFrame(bool) 516.00 ms 2.5% 1.00 ms nsDocument::FlushPendingNotifications(mozilla::FlushType) 509.00 ms 2.4% 3.00 ms mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) 500.00 ms 2.4% 1.00 ms mozilla::GeckoRestyleManager::ProcessPendingRestyles() 331.00 ms 1.6% 3.00 ms mozilla::RestyleTracker::DoProcessRestyles() And some ms under: Weight Self Weight Symbol Name 2.00 ms 0.0% 0 s nsDocument::FlushExternalResources(mozilla::FlushType) 1.00 ms 0.0% 1.00 ms nsContentUtils::RemoveScriptBlocker() 1.00 ms 0.0% 1.00 ms nsIDocument::FlushUserFontSet() 1.00 ms 0.0% 0 s nsBindingManager::ProcessAttachedQueueInternal(unsigned int) 1.00 ms 0.0% 0 s mozilla::EffectCompositor::PostRestyleForThrottledAnimations() So it's a restyle not a reflow?

Yep, that's a restyle flush. Once I'm done with bug 1342197 we should maybe figure out whether we need to flush frames here at all...

Sorry for the noise. Got the wrong bug number in some changesets. :( Anyway, assuming the bugs blocking this one all land in their current state, we will no longer flush anything for these properties. The actual performance numbers for the microbenchmark with those patches applied look like this: Chrome: Click on button: ~20 Click in textfield: ~55 My build: Click on button: ~20 Click in textfield: ~23 so I think we can call this fixed once all that lands.

Was this work completed in a sub bug? Can we close.

See the bugs blocking this one. They just landed on inbound today. We can close once they merge to m-c and we verify the fix on speedometer.

This is fixed.