Ah, you are right. I had added so many search engines (usually by
adding a path and search argument to eliminate having to wade through
submenus or subpages to get a particular type of search) that I couldn't
remember which were the default ones bundled with the web browser.
I noticed there is one bundled for Bing, and the one that I added for
Bing. I can remove the one that I added, but not the bundled one.
For Edge-C, I'm using 97.0.1072.62. Same as you. Just picked a
non-bundled (user-added) search engine looking at the options under the
3-dot menu. Instead I looked at the Yahoo! entry. It's 3-dot menu did
NOT have the Remove option. I could still rename the keyword (from
"
yahoo.com" to just "yahoo"), but lost it for a bit until I noticed the
entry moved from near the end of the list to near the top, and later it
moved back to near the bottom. Boing boing boing, where is it now. I
would never use "
yahoo.com" or even "yahoo" for the keyword even if it
ever did use Yahoo (which I haven't for decades), so I changed it to
just "y". But, I cannot remove the entry anymore.
Thinking Edge might use the registry to store some settings, I change
the Yahoo keyword to "y1a2h3o4o5" to give my a likely unique string on
which I could search in the registry. Nope, not found, so Edge is
storing its settings elsewhere. I loaded SysInternals' Process Monitor
to watch for events from msedge.exe as a filter (ProcMon records all
events, so the filter just eliminates having to see all events to see
just those in which you are interested). I changed the keyword for
Yahoo to "yahoo12345", and saved, to see if I could catch Edge updating
a config file. Edge creates a LOT of events, so I had to stop ProcMon
from monitoring, clear its log, edit the Yahoo keyword, start monitoring
in ProcMon, do the keyword save, and quickly stop monitoring in ProcMon.
Nope, none of the Write events were to a file that looked like holding
config data. Some session files got written into, but I was hoping to
capture Edge writing into a data file. It's possible the config changes
are temporary within the current session of Edge, and that any config
changes are made permanent by writes when closing Edge. Well, closing
Edge resulted in 5960 events before I could stop logging in ProcMon. Of
the WriteFile events, the vast majority were to .log or .tmp files. I
found some that might updates to data files, but they were hex files, so
some database file that I won't be able to edit the search engines list.
After hunting through hundreds of WriteFile events from the top of the
log, and also looking backward from the bottom of the log, I gave up
trying to find where msedge.exe might be saving a change to the search
engines list on its close.
Looked online and found:
https://www.linkedin.com/pulse/windows-10-microsoft-edge-browser-forensics-brent-muir
(dated 2015)
However, that is NOT for the Edge-Chromium web browser, but for the old
Edge-EdgeHTML web browser. I went under:
C:\Users\<username>\AppData\Local\Microsoft\Edge\User Data\Default
(where the default profile is stored)
but from there I couldn't tell where to go next. I found a Preferences
file under there, but a search on "yahoo" didn't find anything. Since
that is the Edge profile folder, any changes to the search engines list
should be saved there. Edge-C does not have an export for an entire
profile, just for Favorites, so the recommendation to copy an Edge
profile to another instance of Edge is to copy this folder (well, up to
the parent folder of "%localappdata%\Microsoft\Edge\User Data" which
includes the Default subfolder).
I suspect that even if I found the file holding the list of search
engines that it would be a database that I could not easily edit, if at
all. In addition, the bundled search engines might be hardcoded into
the app rather than in a config file along with other search engine
entries.
I used feedback in Edge-C to report the change of not allowing removal
of pre-installed search engines. Yeah, they are a bit deaf, but I've
found lots of feedback on the same issue is far more likely to get
addressed by Microsoft than any feedback for Google's software.
https://bugs.chromium.org/p/chromium/issues/detail?id=1263679
Just because Google decided to be assholes doesn't mean Microsoft have
to brown nose. This is the arrogance of programmers that I encountered
in Software QA who thought their code and choices were so important that
just everyone must comply. I'd ask why they did a dirty uninstall.
Their attitude is that customers would only uninstall to perform a
reinstall in troubleshooting, so they would retain all the config data
in files or registry. Yeah, of course, a customer would never want a
clean uninstall, because a customer would never want to completely
remove their product, and always want to reinstall it. After refusing
to close my own bug ticket, and because I would keep updating it to move
to the top of their Open tickets list, and showing a poll from customers
requesting a clean uninstall, they eventually provided options during
uninstall to retain user data (the default) or remove all program and
data entries for a clean uninstall. I had to be stubborn, and provide
proof, that Dev was wrong in their opinion of why customers would do an
uninstall and want a clean one.
Google's attitude has always been "we know what is best for you
regardless of what you want". Here's a comment in the bug ticket:
I think prohibiting deletions is sensible and probably will fix more
problems than it would create.
A ridiculous supposition without any proof of just what problems would
be caused by deletion of pre-populated search engine entries. Not even
citing one incidence of a "problem". An example of their arrogance is
"Deleting these should either be more difficult (confirmation dialog) or
impossible (no delete option in the menu). My strong preference is to do
the latter." Yeah, don't let users choose. They don't matter. They
didn't take the best path (in their opinion, or not) but took the path
of least resistance. All they had to do in the menu list was to hide
the Remove entry for pre-populated entries, like setting the visible
attribute on an entry element to false. The entry is still there, but
invisible hence inaccessible to the user. The don't even to remove the
entry. A lot easier than adding a dependent confirmation popup on
selecting the Remove option.
There is some light in they muddy tunnel of the dev tunnel:
"in the meantime, I'll restore the Delete option in the UI. It should
return in either Chrome 98 or 99 (releasing in early Feb and early
Mar, respectively)."
So, a "problem" they perceived (but did not cite cases showing such ever
happened) was of malware changing the default search engine by deleting
it from the search engine list. Has anyone here encountered that
malicious event? They saw a possibility, contrived it a definite
vulnerability, and took a half-ass approach. A confirmation prompt
would eliminate that threat, but then it would have to appear when
removing ANY search engine entry for consistency instead of just
appearing for the pre-populated entries. After all, getting a
confirmation prompt on a change or delete has been a common behavior
ever since Windows showed up, and even back in DOS. It was a safety net
against an accidental action. How often do you delete search engine
entries that a confirmation prompt on Remove would be such a monsterous
nuisance?