// Copyright 2018 The Chromium Authors // Use of this source code is governed by a BSD-style license that can be // found in the LICENSE file. #include "chrome/test/chromedriver/log_replay/log_replay_socket.h" #include <memory> #include "base/files/file_path.h" #include "base/json/json_reader.h" #include "base/strings/string_number_conversions.h" #include "base/values.h" namespace { std::string SessionIdJson(const std::string session_id) { … } } // namespace LogReplaySocket::LogReplaySocket(const base::FilePath& log_path) : … { … } LogReplaySocket::~LogReplaySocket() { … } void LogReplaySocket::SetId(const std::string& socket_id) { … } bool LogReplaySocket::IsConnected() { … } bool LogReplaySocket::Connect(const GURL& url) { … } bool LogReplaySocket::Send(const std::string& message) { … } std::unique_ptr<LogEntry> LogReplaySocket::GetNextSocketEntry( bool include_requests) { … } SyncWebSocket::StatusCode LogReplaySocket::ReceiveNextMessage( std::string* message, const Timeout& timeout) { … } // Ensures that we are not getting ahead of Chromedriver. // // This means not returning events or responses before ChromeDriver has taken // the action that triggers them. // // There is a rare case where the following order of events occurs in the log: // client-side command // WebSocket Command (id=X) (resulting from client-side command) // WebSocket Event // WebSocket Response (id=X) // To ensure that we don't fire the second event before the client-side // command is called (thus probably causing an error), we must block when we // see the WebSocket Command until that id is sent through the Send method. // Such a WebSocket Command will always occur after a client-side command. // If the event occurs between the client-side command and the WebSocket // Command, it will be fine to fire at that time because ChromeDriver hasn't // taken any action on the client-side command yet. bool LogReplaySocket::HasNextMessage() { … }