An open API implies a certain intent of the author. If there is an open API to utilize some feature, that implies an expectation that others will use it and thus an expectation of a consistent interface version to version. If you're forced to go around monkey-patching the core framework, you can expect a moving target as there is no expectation of external users thus no motivation to maintain a consistent interface between versions.

So in this case, the core framework being exposed to javascript is evidence of the expectation of external users, thus it will likely not be a moving target. If you're modifying some software, you will greatly prefer programming to an API than not.

My interpretation is they're saying that Chromium's address bar code is complex deeply integrated with many other parts of the code-base (including many parts that interact with Google's search APIs). On the other hand, Firefox's address bar code exposes a simple javascript API. This means that making and maintaining custom modifications to the address bar is easier with Firefox.

Ever since Chrome Beta users have been able to change the search engine that powers the omnibox (to include autocomplete suggestions, not just search results).

Changing the search engine that powers the omnibox is different than changing the behaviour of the omnibox, which is kind of a lot when it comes to predictive search, predictive completion and a bucket of other things that I wish you could turn off (or can be turned off for a while before Google decides you shouldn't ever need or want to turn it off). It's a target with a huge amount of churn. I agree that Firefox is a more sane target as a developer.

The gp's parenthetical addresses what you call "predictive completion", only it uses the term "autocomplete".

It addresses changing the site that feeds it. It does not address changing the behavior.

When you decide to fork a project, a key concern is: how invasive are your changes going to be? This is a very large component of how easy or hard it will be to merge upstream changes in the future.

In this case, going with Chrome would mean very invade changes to enable exposing things the upstream specifically wants to keep private in their codebase. Firefox instead requires only well-delineated, minimally invasive changes because there is a nice clean boundary between UI code and engine code (which incidentally matches c++/js boundary, the languages themselves don’t matter much), which means their changes can be isolated to the UI layer, which in turn means a much cleaner path to merging upstream changes

I think, Open as in scriptable and documented. Chrome has many undocumented apis and most of it is in c++. Not everything is exposed to the webview area.

This reasoning makes sense to me. If you have a JS api, to me that implies a consistent and maintained interface. Modifying the internals seems like it could easily become deprecated or have to be completely different with a single wrong PR