Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWebView/SearchEngine.cpp

47 lines
1.5 KiB
C++
Raw Normal View History

LibWebView: Define the list of built-in search engines in LibWebView These engines and their query URLs are duplicated in several places. Before implementing search support in the AppKit chrome, let's move these engines to LibWebView.
2023-10-19 15:50:39 -04:00
/*
LibWebView: Store search engine names/URLs as String In order to support custom search engines, we will need to store the engine properties as String to hold user-provided data. This also caused a compile error trying to assign Optional<SearchEngine> to Optional<SearchEngine const&>, so there's a bit of extra churn here.
2025-04-04 09:57:48 -04:00
* Copyright (c) 2023-2025, Tim Flynn <trflynn89@ladybird.org>
LibWebView: Define the list of built-in search engines in LibWebView These engines and their query URLs are duplicated in several places. Before implementing search support in the AppKit chrome, let's move these engines to LibWebView.
2023-10-19 15:50:39 -04:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWebView: Do not use AK::format to format search engine URLs This is to prepare for custom search engines. If we use AK::format, it would be trivial for a user (or bad actor) to come up with a template search engine URL that ultimately crashes the browser due to internal assertions in AK::format. For example: https://example.com/crash={1} Rather than coming up with a complicated pre-format validator, let's just not use AK::format. Custom URLs will signify their template query parameters with "%s". So we can do the same with our built-in engines. When it comes time to format the URL, we will do a simple string replacement.
2025-04-04 17:32:04 -04:00
#include <LibURL/URL.h>
LibWebView: Define the list of built-in search engines in LibWebView These engines and their query URLs are duplicated in several places. Before implementing search support in the AppKit chrome, let's move these engines to LibWebView.
2023-10-19 15:50:39 -04:00
#include <LibWebView/SearchEngine.h>
namespace WebView {
LibWebView: Support custom search engines This allows the user to store custom search engines via about:settings. Custom engines will be displayed below the builtin engines in the drop- down to select the default engine. A couple of edge cases here: 1. We currently reject a custom engine if one with the same name already exists. In the future, we should allow editing custom engines. 2. If a custom engine which was the default engine is removed, we will disable search rather than falling back to any other engine.
2025-04-04 18:12:32 -04:00
static auto s_builtin_search_engines = to_array<SearchEngine>({
LibWebView: Do not use AK::format to format search engine URLs This is to prepare for custom search engines. If we use AK::format, it would be trivial for a user (or bad actor) to come up with a template search engine URL that ultimately crashes the browser due to internal assertions in AK::format. For example: https://example.com/crash={1} Rather than coming up with a complicated pre-format validator, let's just not use AK::format. Custom URLs will signify their template query parameters with "%s". So we can do the same with our built-in engines. When it comes time to format the URL, we will do a simple string replacement.
2025-04-04 17:32:04 -04:00
{ "Bing"_string, "https://www.bing.com/search?q=%s"_string },
{ "Brave"_string, "https://search.brave.com/search?q=%s"_string },
{ "DuckDuckGo"_string, "https://duckduckgo.com/?q=%s"_string },
{ "Ecosia"_string, "https://ecosia.org/search?q=%s"_string },
{ "Google"_string, "https://www.google.com/search?q=%s"_string },
{ "Kagi"_string, "https://kagi.com/search?q=%s"_string },
{ "Mojeek"_string, "https://www.mojeek.com/search?q=%s"_string },
{ "Startpage"_string, "https://startpage.com/search?q=%s"_string },
{ "Yahoo"_string, "https://search.yahoo.com/search?p=%s"_string },
{ "Yandex"_string, "https://yandex.com/search/?text=%s"_string },
LibWebView: Store search engine names/URLs as String In order to support custom search engines, we will need to store the engine properties as String to hold user-provided data. This also caused a compile error trying to assign Optional<SearchEngine> to Optional<SearchEngine const&>, so there's a bit of extra churn here.
2025-04-04 09:57:48 -04:00
});
LibWebView: Define the list of built-in search engines in LibWebView These engines and their query URLs are duplicated in several places. Before implementing search support in the AppKit chrome, let's move these engines to LibWebView.
2023-10-19 15:50:39 -04:00
LibWebView: Support custom search engines This allows the user to store custom search engines via about:settings. Custom engines will be displayed below the builtin engines in the drop- down to select the default engine. A couple of edge cases here: 1. We currently reject a custom engine if one with the same name already exists. In the future, we should allow editing custom engines. 2. If a custom engine which was the default engine is removed, we will disable search rather than falling back to any other engine.
2025-04-04 18:12:32 -04:00
ReadonlySpan<SearchEngine> builtin_search_engines()
LibWebView: Define the list of built-in search engines in LibWebView These engines and their query URLs are duplicated in several places. Before implementing search support in the AppKit chrome, let's move these engines to LibWebView.
2023-10-19 15:50:39 -04:00
{
LibWebView: Support custom search engines This allows the user to store custom search engines via about:settings. Custom engines will be displayed below the builtin engines in the drop- down to select the default engine. A couple of edge cases here: 1. We currently reject a custom engine if one with the same name already exists. In the future, we should allow editing custom engines. 2. If a custom engine which was the default engine is removed, we will disable search rather than falling back to any other engine.
2025-04-04 18:12:32 -04:00
return s_builtin_search_engines;
LibWebView: Define the list of built-in search engines in LibWebView These engines and their query URLs are duplicated in several places. Before implementing search support in the AppKit chrome, let's move these engines to LibWebView.
2023-10-19 15:50:39 -04:00
}
LibWebView: Do not use AK::format to format search engine URLs This is to prepare for custom search engines. If we use AK::format, it would be trivial for a user (or bad actor) to come up with a template search engine URL that ultimately crashes the browser due to internal assertions in AK::format. For example: https://example.com/crash={1} Rather than coming up with a complicated pre-format validator, let's just not use AK::format. Custom URLs will signify their template query parameters with "%s". So we can do the same with our built-in engines. When it comes time to format the URL, we will do a simple string replacement.
2025-04-04 17:32:04 -04:00
String SearchEngine::format_search_query_for_display(StringView query) const
LibWebView: Add an API to format a search query for UI display This will create a string of the form: Search DuckDuckGo for "Ladybird is awesome!" If the provided query URL is unknown, the engine name is excluded (e.g. for custom search URLs).
2023-10-23 16:41:36 -04:00
{
static constexpr auto MAX_SEARCH_STRING_LENGTH = 32;
LibWebView: Do not use AK::format to format search engine URLs This is to prepare for custom search engines. If we use AK::format, it would be trivial for a user (or bad actor) to come up with a template search engine URL that ultimately crashes the browser due to internal assertions in AK::format. For example: https://example.com/crash={1} Rather than coming up with a complicated pre-format validator, let's just not use AK::format. Custom URLs will signify their template query parameters with "%s". So we can do the same with our built-in engines. When it comes time to format the URL, we will do a simple string replacement.
2025-04-04 17:32:04 -04:00
return MUST(String::formatted("Search {} for \"{:.{}}{}\"",
name,
LibWebView: Add an API to format a search query for UI display This will create a string of the form: Search DuckDuckGo for "Ladybird is awesome!" If the provided query URL is unknown, the engine name is excluded (e.g. for custom search URLs).
2023-10-23 16:41:36 -04:00
query,
MAX_SEARCH_STRING_LENGTH,
query.length() > MAX_SEARCH_STRING_LENGTH ? "..."sv : ""sv));
}
LibWebView: Do not use AK::format to format search engine URLs This is to prepare for custom search engines. If we use AK::format, it would be trivial for a user (or bad actor) to come up with a template search engine URL that ultimately crashes the browser due to internal assertions in AK::format. For example: https://example.com/crash={1} Rather than coming up with a complicated pre-format validator, let's just not use AK::format. Custom URLs will signify their template query parameters with "%s". So we can do the same with our built-in engines. When it comes time to format the URL, we will do a simple string replacement.
2025-04-04 17:32:04 -04:00
String SearchEngine::format_search_query_for_navigation(StringView query) const
{
return MUST(query_url.replace("%s"sv, URL::percent_encode(query), ReplaceMode::All));
}
LibWebView: Define the list of built-in search engines in LibWebView These engines and their query URLs are duplicated in several places. Before implementing search support in the AppKit chrome, let's move these engines to LibWebView.
2023-10-19 15:50:39 -04:00
}
Reference in a new issue Copy permalink