Closed ParticleCore closed 7 months ago
After further research it seems the extension can be ported to Chrome, but there are a lot of challenges to make it work. The biggest one is it will require a different way to load the core code into the webpage than what how it is done in Firefox.
Where in Firefox the core code and dynamic data can be injected in the webpage (thanks to their X-ray vision) via content scripts in the following way:
const script = document.createElement("script");
script.id = "iridium-inject";
script.textContent = `(${mainScript}("${browser.runtime.id}",${JSON.stringify(SettingData)}))`;
document.documentElement.appendChild(script);
On Chrome the same thing is not possible, but something close to it can be done in two stages:
manifest.json
content script configuration with the world
set to MAIN
(more details here) and listening for broadcast message from the second content scriptworld
set to ISOLATED
, and as soon as it loads, it sends the settings obtained asynchronously to the first script via broadcast messageSo far this combination appears to run sufficiently fast and there seems to be no discerning issues with it when compared to the new way that is done in Firefox that I am currently experimenting with, so it is looking promising.
The only disadvantage with this at this time is the inability to include dynamic data with the script, so adding a secret to be used with the broadcast messages will simply not be feasible. However, as wOxxOm
noted in our group conversation, a rogue script can easily intercept/tap listeners and obtain the secret, so any communication security would be only as good as up to that point.
I appreciate the information, it is definitely helpful. All of those were unknown to me, except for YouTube Enhancer which I've seen mentioned on Reddit every now and then.
At this time I am not focused on making a userscript, but I was glad to see the changes to drop the dependency on webRequest were successful (the core code functionality is now all in one file in the alpha channel) which opens the door for making it a dedicated userscript one day.
But before that can be done, the main focus is to get it working for Chrome - which I seem to be doing a good progress, at least in my limited testing. If everything goes well I might have a version to push to the Chrome Web Store before the end of the month, and hopefully no rejections.
Extension improvements and refactoring has been completed and an interim 2.0.3 version has been submitted to the Chrome store for review.
First attempt resulted in a rejection with the following reasons:
Violation reference ID: Yellow Zinc
Violation:
Description provided is insufficient to understand the functionality of the item.
How you can fix this
Add a meaningful description that explains the functionality of your item clearly and accurately.
I've rewritten the description to one that is more in line with other similar extensions on the Chrome Web Store that have been successfully updated recently in hopes of being enough to pass this requirement and submitted it again.
Second attempt: rejected again for the same reason as before.
I have now resorted to doing an almost literal copy of the summary and description of a similar extension (enhancer for youtube) that has been recently updated on the chrome store hoping this time it will finally go through.
Third time was accepted, but I believe what worked was not the description, but the extension summary - the one that is included in the manifest.json
The previous summary was simply https://github.com/ParticleCore/Iridium/blob/4f1470938d87defe8144710e3e94c414ba48eb57/src/chrome/manifest.json#L5
And it was changed to
Take control of YouTube and boost your user experience with Iridium
For the next version I will only change the store description to what I wrote on the second try and see if it passes.
Currently I've reached a comfortable stage of the extension in which it is relatively populated with useful features, with the latest biggest one being the Blacklist feature, so I will now focus a bit on researching the possibility of publishing on the Chrome Web Store again.
There are immediately three significant challenges that need to be addressed in order for this to go through with green lights:
Regarding 1
I was able to successfully migrate every single injection in this group:
https://github.com/ParticleCore/Iridium/blob/c516be2c4eee7ddf4de26f8dad2ac9112be0c9e0/src/js/background.js#L96-L136
into dedicated overrides.
This is a method that I used before when the extension was a mere userscript, but became very limiting at one point.
It is hard for me to say how much performance was lost or gained with this method, but without this the extension would stand no chance to work on Chrome.
With this change effectively the background page/event page is reduced to a single function, which is to open the extension options page.
There is also an added benefit to this change since no script files are directly modified, something that in the past lead to discover a bug in Firefox.
The other unintended benefit is it could be possible to port the entire extension back as a userscript. While it would be nice to come to a full circle, this is only a wish at this time and I am not currently thinking on pursuing this actively given the other items with higher priority, and it will also require a robust, compatible solution for the lack of a dedicated settings page.
Regarding 2
The next biggest challenge I've found so far is how fragmented the ability to run a script in a webpage is between Firefox and Chrome.
Personally speaking, Firefox has the easiest and simple approach between the two - whereas even though Chrome considered adopting something similar, they recoiled behind their safety-above-everything-no-matter-the-cost approach
However, the current state of their API will not be changing anytime soon so whatever they offer will have to do.
The major hurdle with injecting a script in a webpage is briefly documented here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities#content_script_environment
script environment, executing code, and lifecycle during navigation vary drastically between the two platforms.
Currently on Firefox the extension can statically inject a content script and it will have the ability to inject code into the page DOM. as well as make use of browser APIs.
On Chrome this is not possible. On Chrome, the same mechanism has limitations. The content script can either be injected into the page directly using the world main property - but then it cannot make use of any browser APIs since it is no longer within the allowed context: https://developer.chrome.com/docs/extensions/reference/manifest/content-scripts
And if the property is set to isolated, then the script cannot inject itself into the page due to CORS, a change introduced in Manifest v3 by Chrome.
The only other possible alternative will rely on the background script (service-worker) to replicate the same behavior using
https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts#programmatic
This is probably the only last resort to try. Otherwise, without this, I do not think there is a way to make it work correctly.
Regarding 3
It is always a concern especially given how YouTube has been actively fighting recently. It also does not help how the Chrome team is completely vague and obstinate with their rejection protocols all in the name of extreme safety, almost alienating their contributors: https://github.com/uBlockOrigin/uBlock-issues/issues/745#issue-503496432
However, I would be willing to accept forgoing a feature if it was a cause for rejection, if that feature is available as a dedicated extension.