fast/dom/rtl-scroll-to-leftmost-and-resize.html frequently times out on Mac. This usually reproduces the problem on my MacBook Pro: run-webkit-tests fast/dom/rtl-scroll-to-leftmost-and-resize.html --repeat 100 --no-build --no-retry -f Via printf debugging, I found that WebContent sends DrawingAreaProxy::DidUpdateGeometry, but the message never reaches Connection::dispatchMessage in UI process.
The message doesn't even reach Connection::enqueueIncomingMessage in UI process...
Okay, a little less mysterious. We do get the message in Connection::processIncomingMessage in UI process, but in the failing case, it gets processed by this block: // Check if we're waiting for this message. { std::lock_guard<Lock> lock(m_waitForMessageMutex); if (m_waitingForMessage && m_waitingForMessage->messageReceiverName == message->messageReceiverName() && m_waitingForMessage->messageName == message->messageName() && m_waitingForMessage->destinationID == message->destinationID()) { m_waitingForMessage->decoder = WTF::move(message); ASSERT(m_waitingForMessage->decoder); m_waitForMessageCondition.notifyOne(); return; } ... So, Connection::waitForAndDispatchImmediately must be buggy, the message that it's waiting for can get dropped altogether. Once a DidUpdateGeometry message gets dropped, that makes UI process never again send any DrawingArea::UpdateGeometry messages for this drawing area.
Added a test expectation in r189491. But this likely affects more tests.
Created attachment 260838 [details] proposed fix
Created attachment 260841 [details] proposed fix Actually, let's also make sure that we don't overwrite m_waitingForMessage->decoder when two messages come in quickly.
Comment on attachment 260841 [details] proposed fix Clearing flags on attachment: 260841 Committed r189546: <http://trac.webkit.org/changeset/189546>
All reviewed patches have been landed. Closing bug.