* 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.
Kevin Payravi