Fixed bug where search engine result re-ordering was not taking into account whether a user has disabled search engine filtering for a particular wiki. Also, search engine result re-ordering can now detect and compare main pages (for the purpose of hiding duplicate results from non-indie wikis).
* Re-implementing previous solution where all indie results are moved above the first non-indie result, instead of swapping
* Only hiding non-indie results that match an indie result when re-ordering is enabled
* Adjust top-mount CSS query for Firefox Android
Trying this out to help resolve issue when running on Google image results. Querying for closest jscontroller and hveid can go too far up in the DOM; jsname is another option that is sometimes closer.
The script for the settings page included a large amount of duplicated code, so I refactored it to put that reused code in functions instead. I also refactored other code, such as massively simplifying the function that converts the user's settings to checked radio buttons.
Additionally, I refactored the "Individual wiki settings" table to actually be built using a table, instead of a structure that only appears to be a table.
I also made various other minor adjustments to the Settings page:
* Adjust the formatting of the "icon legend" box to be consistent with the other boxes on the page.
* Replaced the emoji 🍃 instead of the Tibetan character ༄ to represent BreezeWiki. The Tibetan character was rendering much smaller than the emoji in the other boxes. But regardless, it's better not to use characters non-semantically.
* Add a border around the "individual wiki settings" table, for consistency with the other boxes on the page.
Since we now take the parentNode of located Google search engine result containers, we need to adjust where we insert re-ordered results. Instead of prepending to parent node, we insert before the non-indie container.
Adding the change observer after the initial filter occurs seems to be able to cause race conditions, particularly on Startpage. This commit moves the change observer addition to the beginning of the filtering function. The downside is that adding the change observer before filtering starts isn't ideal, since filtering manipulates the DOM and can trigger a re-check.
When hiding or replacing Google search results, we now use the search result container's parentNode. This avoids some UI conflicts and issues, particularly when injecting the replacement button.
For Google search result re-ordering, we still use the original search container w/o the parent node.
Adding a check for div.MjjYud when injecting redirect button into Google search results. This helps resolve UI issues with non-traditional search results (like video results).
Google will insert the user's searches into some of their meta links. If the user does a Google search for a non-indie domain (e.g. mario.fandom.com), that domain can appear in those Google meta links and cause IWB to detect them. By filtering out links that start with /search, we avoid capturing these.
Refactor code that depends on the destination wiki's platform in order
to support generic wiki platforms (e.g. Wikidot).
Redirection to the Main Page now uses the destination_content_path to
send users directly to the destination wiki's main page, rather than
using a different URL depending on the destination wiki's software.
The only remaining code that depends on the destination wiki's software
is the construction of the search path. This code now has a default case
that doesn't add any software-specific path to a constructed search URL.
This allows any wiki, regardless of the software it runs on, to be
added by putting its full search path in the "destination_search_path"
property of the redirect definition.
As a result of these changes, it is now possible to add redirects to
Wikidot wikis, by just defining the full search path in their redirect
entry's "destination_search_path".
Co-authored-by: SnorlaxMonster <snorlaxmonster@users.noreply.github.com>
Kevin Payravi