Replies: 4 comments 9 replies
-
|
Hello there and thank you for your interest in the repo, My main question is, whether the changes made it incompatible with chrome one? or better yet, if a properly working chrome and Firefox extension, are compatible between them. I wish to keep a single source of truth for the source code, instead of mainting multiple repos/forks. The release will be made by this account on Firefox as well. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! JS-wise, the extension mostly seems to work; the Firefox-related bugs I've found by now are mostly visual (i.e. everything seems to be left-aligned, some elements get pushed outside the screen, a part of the screen remains empty of content…). I didn't get to fix this yet, but it shouldn't be that complicated. It might be possible for this to be patched in a way that doesn't break cross-compatibility with Chromium, but we shall see when I get to that. The Firefox cross-compatibility tool currently reports the following: {
"compat": [],
"errors": [
{
"message": "\"/manifest_version\" must be <= 2",
"description": "Your JSON file could not be parsed.",
"locations": [
{}
]
}
],
"warnings": [
{
"message": "Unsafe assignment to innerHTML",
"description": "Due to both security and performance concerns, this may not be set using dynamic values which have not been adequately sanitized. This can lead to security issues or fairly serious performance degradation.",
"locations": [
{
"file": "manipulators/addBlockedIndication.js",
"line": 17
},
{
"file": "manipulators/productFlagger.js",
"line": 30
},
{
"file": "manipulators/separatePromoListFlagger.js",
"line": 24
},
{
"file": "manipulators/shelfFlagger.js",
"line": 22
}
]
}
]
}However, the (single) error is misleading, as Firefox has been supporting ManifestV3 since v109, which was released in January 2023. After I do patch these visual bugs, I'll just have to do a lot of testing on Firefox and a chromium-based browser, to ensure that they both behave identically. You can currently see a sneak-peek here, comparing between Firefox and Vivaldi (Chromium-based). Interestingly, a certain sponsored banner actually doesn't get flagged on Vivaldi but does so on Firefox (!) I'll definitely investigate this as well. Regardless, the three most important things to note are:
"browser_specific_settings": {
"gecko": {
"id": "addon@example.com",
"strict_min_version": "109.0"
}
In any case, I shall keep you updated with any new info. I assume I'll be done with the CSS-related patches by next weekend & begin properly testing. |
Beta Was this translation helpful? Give feedback.
-
|
Update: At its current state in my fork, the extension appears to work on both browsers, with minimal edits. In specific, JS-wise everything is cross-compatible, and the primary issue was the following line on the CSS file .content {
margin: 0;
}Which I have now replaced with: .content {
margin: auto;
}The "browser_specific_settings": {
"gecko": {
"id": "addon.todo@example.com",
"strict_min_version": "109.0"
}
}As all Manifest V3 extensions need an add-on ID in their manifest.json when submitted to AMO.. Currently, the plans are for me to:
Then we can see whether it's going to be merged on the main branch or another branch :) |
Beta Was this translation helpful? Give feedback.
-
|
That is, I had edited the JS part originally, but it wasn't needed for this purpose, so I kept only the relevant commits now :) |
Beta Was this translation helpful? Give feedback.
-
|
It appears that the cause of the visual bug is that Firefox tries to apply "content_scripts": [
{
"matches": ["https://www.skroutz.gr/*"],
"css": [
"css/flaggerToogle.css",
"css/popup.css",
"css/productFlags.css",
"css/shelfFlags.css",
"css/style.css",
"css/videoFlags.css"
],
In other news, I may or may not have found a Firefox-related JS bug that I'll need to fix after your most recent commit. I'll properly report or fix it after I properly test that. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @bandisast, I removed |
Beta Was this translation helpful? Give feedback.
-
|
Hey! I haven't yet tested whether any of the most recent changes broke firefox compatibility, but I will do so at the soonest convenience. If no issue is found, I suspect that the only leftover change will be the I'll test the newest commits and I'll let you know if I find anything else that might delay a PR, otherwise only expect a minor edit in the |
Beta Was this translation helpful? Give feedback.
-
|
Great to hear and thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Just to inform you guys, I have switched to a typescript and added webpack as the build process. It is documented in the There are now two different build processes for Chrome and Firefox, so they are developed in parallel but also independently. |
Beta Was this translation helpful? Give feedback.
-
|
That's great news, thanks for the update :) Paging @gtopsis so that they see this as well |
Beta Was this translation helpful? Give feedback.
-
|
Awesome news. Very nice initiative to support FF ❤️ friends @bandisast. |
Beta Was this translation helpful? Give feedback.
-
Greetings, all.
I forked the project yesterday, and I plan to port the extension to Firefox by making some small modifications. With the – relatively miniscule – amounts of testing I've done by now, the extension seems to mostly work already, albeit with a few (primarily visual) bugs and API incompatibilities that should be simple-enough to fix.
However, that raises a few questions that I'd like to ask, assuming that I do make the extension fully work on Firefox before the current primary contributors do:
For security reasons, the only Firefox versions that support unsigned (by Mozilla) visual extensions are Firefox Beta, Firefox Nightly, and Firefox Developer Edition. As such, if the average user wants to install a visual extension, the extension will need to be submitted to the Mozilla store and be manually approved by someone from Mozilla.
What shall be done with the updated (for Firefox) source code? Should it be committed to a special branch of the original repo, a special folder in the main branch of the original repo, or should it stay in my fork?
Seeing as the extension is GNU GPLv3 licenced, standard GPLv3 terms apply, but I would still prefer to ask for the opinion of the original maintainers! :)
Beta Was this translation helpful? Give feedback.
All reactions