I have the same question. I’ve often been tempted by the editable URL field, but I have no idea how this would affect my extension’s existing users.
Here’s a discussion from 2018 about /privacy-badger17
, but they are still using the same URL today.
Edit1:
I’ve decided to try some YOLO research. Renamed https://addons.mozilla.org/firefox/addon/ipvfoo-pmarks/ to https://addons.mozilla.org/firefox/addon/ipvfoo/ and uploaded a placeholder with "id": "ipvfoo-renamed@pmarks.net"
to the old URL.
The placeholder is currently awaiting review. If you can see https://addons.mozilla.org/firefox/addon/ipvfoo-pmarks/ then it worked.
Edit2:
The placeholder was rejected:
Due to issues discovered during the review process, one or more versions of your add-on IPvFoo (URL changed) will be disabled on addons.mozilla .org in 14 day(s). Please see the reviewer’s comments below for more information.
Details:
This add-on didn't pass review because of the following problems:
- To help users discover your extension and decide if they want to install it, please include more information in your add-on listing. Here are a few tips:
- Your extension’s summary should clearly and concisely explain what your extension does.
- Use the description field to describe what the extension does and how it benefits the user.
- Add screenshots to show your extension in action and to highlight key features.
So Mozilla won’t let you create a mostly-blank forwarding page. I’m trying again with a full description/screenshots/etc.
Edit3:
Mozilla accepted the change. /ipvfoo-pmarks
is now published with a forwarding notice at the top of the description, while /ipvfoo
retains the original reviews and statistics. I haven’t tried pushing an update to /ipvfoo
.
Edit4:
Updates still work. It seems that the biggest problem is convincing Google to prefer the new URL.
Edit5:
Because my extension supports Android (gecko_android
in manifest.json), I was able to disable the “Add to Firefox” button for most users by removing “Firefox” from the Compatibility list in AMO. Setting strict_max_version
to a lower number had no effect.