chromium/chrome/test/chromedriver/log_replay/log_replay_socket.cc

// 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() {}