Closed
Bug 390681
Opened 19 years ago
Closed 19 years ago
Automatically import currently installed add-ons as favorites
Categories
(addons.mozilla.org Graveyard :: Facebook Application, enhancement)
addons.mozilla.org Graveyard
Facebook Application
Tracking
(Not tracked)
VERIFIED
FIXED
RYF-0.4
People
(Reporter: fligtar, Assigned: fligtar)
References
Details
Attachments
(1 file)
|
2.76 KB,
patch
|
morgamic
:
review+
|
Details | Diff | Splinter Review |
The user should be able to choose from his currently installed add-ons which he'd like to mark as "favorites" when adding the app.
Comment 1•19 years ago
|
||
How do you expect to find out what add-ons somebody has installed? If a _website_ can do this, I would consider it a major privacy issue.
| Assignee | ||
Comment 2•19 years ago
|
||
Not just any website can, and it's no different than the way we are using cookies for other things.
There are several ways we can do this, and we haven't decided for sure to use the cookie option, although it would certainly be easier for the user than installing an extension or uploading their extensions.rdf.
| Assignee | ||
Updated•19 years ago
|
Target Milestone: --- → RYF-0.4
| Assignee | ||
Updated•19 years ago
|
Severity: normal → enhancement
| Assignee | ||
Comment 3•19 years ago
|
||
Taking into account caching and privacy concerns, I think this is the best solution to the problem:
We set a netscaler cache rule that will not return a cached update page if a specific cookie is set. Then:
1) When someone adds the facebook app, we say "Hey, would you like to add your currently installed add-ons as favorites?"
2) If they say yes, we set a cookie (expires after that session) with the facebook user id in it from addons.mozilla.org.
3) We tell them to go to Tools -> Add-ons -> Find Updates
4) They will ping the update script with the cookie, which will cause the GUIDs of their add-ons to be written to a temporary table.
5) When finished, we tell them to click "Next" or whatever, and we magically display a list of the installed add-ons with checkboxes for what to add as a favorite.
Assignee: nobody → fligtar
| Assignee | ||
Comment 4•19 years ago
|
||
Two other things:
- The update check should always return no update in this process, as offering an update and prompting to restart Firefox will quickly make the user forget what they were trying to do.
- The cookie should be deleted after the process is complete (on the checkboxes page), so as not to continually return no updates in case the user doesn't restart for awhile.
Comment 5•19 years ago
|
||
(In reply to comment #3)
> 2) If they say yes, we set a cookie (expires after that session) with the
> facebook user id in it from addons.mozilla.org.
How do you plan on setting a cookie from the facebook app (*.facebook.com) for addons.mozilla.org?
| Assignee | ||
Comment 6•19 years ago
|
||
(In reply to comment #5)
> (In reply to comment #3)
> > 2) If they say yes, we set a cookie (expires after that session) with the
> > facebook user id in it from addons.mozilla.org.
>
> How do you plan on setting a cookie from the facebook app (*.facebook.com) for
> addons.mozilla.org?
>
The same way we install extensions from addons.mozilla.org from the Facebook App - by sending the user there. This whole process - from saying "Yes, I want to import" to saying "Add these as Favorites" will be on addons.mozilla.org.
| Assignee | ||
Comment 7•19 years ago
|
||
This is the patch to update/VersionCheck. It won't affect regular updates and will only be different if the specific facebook cookie is set.
The netscaler has been configured to not return a cached page when that cookie is set.
Attachment #278113 -
Flags: review?(morgamic)
Comment 8•19 years ago
|
||
Comment on attachment 278113 [details] [diff] [review]
VersionCheck patch
Looks okay, it won't connect to master unless it knows it has to. All parts of queries escaped, and no-cache headers are there -- though I'm wondering why you didn't use the same ones in the AMO base controller?
Attachment #278113 -
Flags: review?(morgamic) → review+
| Assignee | ||
Comment 9•19 years ago
|
||
(In reply to comment #8)
> though I'm wondering why you didn't use the same ones in the AMO base controller?
Changed to:
header('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, private');
header('Pragma: no-cache');
| Assignee | ||
Comment 10•19 years ago
|
||
This is fixed and on staging.
The import tool is accessible from the sidebar of the new homepage, as well as in the Getting Started message that appears after adding the app. (See http://wiki.mozilla.org/Rock_Your_Firefox/Newsfeed for details on the new home page.)
In order to test this on staging, in about:config change extensions.update.url from https://addons.mozilla.org/... to http://sm-facebook01.mozilla.org/...
Following the instructions on the import page the rest of the way should work fine after that.
The changes to the update script will be pushed live with the next regular AMO update as they don't impact existing functionality of AMO nor Rock Your Firefox, and we'd like to be able to test this with the netscaler before launching.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
http://rockyourfirefox.sm-facebook01.mozilla.org/, according to Justin's latest instructions.
Many thanks to Justin for patiently waiting while I set up the environment needed to test this (it ended up failing because I wasn't including the parameters past the domain in the pref 'extensions.update.url'.
I just finished testing this on all four platforms:
Mac OS X 10.4
Windows XP SP2
Windows Vista
Ubuntu (Linux)
Verified FIXED using the 2.0.0.6 builds with the staging URL and tweaks in comment 10 / comment 11.
I'll likely sign off on a full test Tuesday (late afternoon).
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•