Closed Bug 839629 Opened 7 years ago Closed 6 years ago

Fix partner add-ons so that search pref changes comply with add-on guidelines

Categories

(Firefox :: General, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 23
Tracking Status
firefox20 - ---
firefox21 - ---
firefox23 + ---

People

(Reporter: kmag, Assigned: kmag)

References

()

Details

Attachments

(3 files, 2 obsolete files)

+++ This bug was initially created as a clone of Bug #838864 +++

We have two add-ons that have been developed for search partners to change default search engines to that of the partner:

http://releases.mozilla.com/bundles/bing/addon/
http://releases.mozilla.com/bundles/msn/us/addon/

These add-ons currently do not comply with add-on guidelines, in that they do not reset these preference changes on uninstall. They also trigger the keyword.URL reset prompt, because they change the keyword URL setting in the user branch rather than the default branch, and fail to change browser.search.defaultenginename
Who has owned changes to bing.xpi in the past?
that'll be tomcat.
Flags: needinfo?(cbook)
will look into this, also we will need to answer https://bugzilla.mozilla.org/show_bug.cgi?id=838864#c20
Flags: needinfo?(cbook)
(In reply to Carsten Book [:Tomcat] from comment #3)
> will look into this, also we will need to answer
> https://bugzilla.mozilla.org/show_bug.cgi?id=838864#c20

What do we need to answer from that comment? Whether users changed the settings on purpose has no bearing on what needs to happen here. The main issues are that the extension needs to change settings in the default branch to a) avoid triggering the reset opt-in, and b) undo its changes more completely when users uninstall or disable it.

Also, though, as KaiRo mentioned, we should probably not be changing keyword.URL at all, but instead changing defaultenginename and providing a x-moz-keywordsearch URL for those engines if necessary.

I proposed a patch fixing all of those issues except the last:

https://gist.github.com/63f39616238430268ba7

The last point would require providing an actual XML search description file, and ideally the default engine name would be set via an actual chrome URL rather than a generated data URL.
Assignee: nobody → cbook
erm not taking this bug, i only changed the values/urls for partners when requested but was not the inital developers and also i guess its a little out of scope for my worktask. Currently checking with Kev who could take this bug here
Assignee: cbook → nobody
These addons are a little legacy-ish, and I thought they did make the changes on uninstall. Originally, they were designed to do that.

As far as keyword.URL goes, it's something we used to change with all partner builds. We can make the changes as discussed here, and I want to point out that this addon is used for both bundles and stand-alone installation. If our proposed path forward is to change defaultengine, expect to see pickup on that elsewhere, which will make things like the keyword.URL reset ineffective.
(In reply to Kev Needham [:kev] from comment #6)
> I want to point out that this addon is used for both bundles and stand-alone
> installation.

I'm not sure what this means. Can you elaborate?

> If our proposed path forward is to change defaultengine,
> expect to see pickup on that elsewhere, which will make things like the
> keyword.URL reset ineffective.

When we actually get rid of keyword.URL we'll have to think hard about what our supported mechanism is for customizing search, but we're not there yet.
(In reply to Kev Needham [:kev] from comment #6)
> We can make the changes as discussed here, and I want to point
> out that this addon is used for both bundles and stand-alone
> installation.

Hm. That's odd. I just checked the Bing bundle, and it has the
relevant changes rolled into its distribution.ini, so I'm not
sure why the add-on is needed.

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #7)
> > If our proposed path forward is to change defaultengine,
> > expect to see pickup on that elsewhere, which will make things like the
> > keyword.URL reset ineffective.
> 
> When we actually get rid of keyword.URL we'll have to think hard about what
> our supported mechanism is for customizing search, but we're not there yet.

As long as setting is based on defaultenginename, these should
continue to work.
Tomcat, who is the right person to update these partner add-ons accordingly?

Once we have the original versions updated, I assume we should contact partners to update the versions they are distributing (e.g. on http://www.firefoxwithbing.com/)?

To handle existing users, can we then put the updated versions on AMO so that the existing users automatically get the updated version?
Flags: needinfo?(cbook)
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #9)
> Tomcat, who is the right person to update these partner add-ons accordingly?
> 
no clue, no idea who wrote the inital version of the addon. Kev do you know?

> Once we have the original versions updated, I assume we should contact
> partners to update the versions they are distributing (e.g. on
> http://www.firefoxwithbing.com/)?

Firefoxwithbing is only the Page but the binaries (bundle or addon) come from Mozilla Servers - so no binary like the Firefox Setup exe or .xpi are servered from partner servers. 

> 
> To handle existing users, can we then put the updated versions on AMO so
> that the existing users automatically get the updated version?

Hm this would require some hacking again i guess. So far the Partner (like Bing) does a Browser Detection if a user use Firefox and then get the Page for the Addon and then the direct file.xpi download (so that he might think the download comes from the firefoxwithbing page but instead its technically http://releases.mozilla.com/bundles/bing/addon/bing.xpi ) so a Addon hosted on AMO would require always the direct file download (with bypassing the normal amo page etc) i guess
Flags: needinfo?(cbook)
I was suggesting hosting the addon on AMO only for the purpose of add-on updates, not for actual partner distribution from the web.

Since AIUI Firefox checks for updates on AMO for all add-ons, putting the updated version there should allow existing users to get the update.
I suspect Mardak was involved with the original versions of these add-ons (or at least someone re-used some of his code).

Kris, do you want to own generating updated XPIs for these? Posting a patch here of your changes is probably a good way to handle code review - you can flag me for review.
wrt comment #12 The addons are based on the code from the Twitter addon, which Mardak wrote.

wrt comment #10 I'd be fine with hosting the addons on AMO, but we have an agreement with Bing to host it separately. Part of the reason it's not on AMO is because it didn't meet AMO requirements initially.

wrt comment #9 I'd love for updates to be hosted on AMO, too, but we'll need to run it by our partner, too.

wrt comment #8, the addon is required to setup the apptab, which is something I'd love to be able to define via an ini setting. My point about using the defaultengine setting is that once we start doing that, then you'll see more of the drive-bys using it, and things like the keyword reset fix won't work (but since it's a one-time thing anyways, I'm guessing that's ok).
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #12)
> Kris, do you want to own generating updated XPIs for these? Posting a patch
> here of your changes is probably a good way to handle code review - you can
> flag me for review.

Yes, I'll try to have them up today or tomorrow.

(In reply to Kev Needham [:kev] from comment #13)
> My point about using the defaultengine setting is that once we
> start doing that, then you'll see more of the drive-bys using it,
> and things like the keyword reset fix won't work (but since it's a
> one-time thing anyways, I'm guessing that's ok).

That shouldn't be a problem once we have a user-visible configuration interface. The main problem with drive-bys changing keyword.URL is that users have no obvious way to revert the changes.
I will buy you multiple beverages of choice (within reason) if this gets addressed. :)

(In reply to Kris Maglione [:kmag] from comment #14)
> That shouldn't be a problem once we have a user-visible configuration
> interface. The main problem with drive-bys changing keyword.URL is that
> users have no obvious way to revert the changes.
Attached file Proposed update (obsolete) —
I hadn't realized how many issues these add-ons had apart from the search preference issues, so I decided to upload a new XPI rather than a patch after fixing them. In particular:

• The landing tab was closed when the add-on was disabled even after the user had navigated away from the initial landing page.
• The code that opened the landing page leaked the browser window it added the tab to for the length of the session.
• The icon used for the search engine was a badly chosen 75×25 Bingo logo that was badly distorted in the search bar.

So there are essentially two options here: 1) Use something like my previous patch, with the minimal number of changes to fix the search issues, or 2) Use something like this version which fixes the other issue as well.

This version also uses the re-usable module that I wrote for the wiki page explaining how to make these changes correctly (https://developer.mozilla.org/en-US/docs/draft_Search_Extension_Tutorial), so I'd appreciate any comments on that from the perspective of it being more widely distributed.

A diff, for reference: https://gist.github.com/c413c704c6a331d263f8
Attachment #717289 - Flags: review?(gavin.sharp)
I don't recall exactly what the issue was yet, but I believe at the time of the original add-on package, there was some additional code as part of the bundle ini that specially triggered something with the add-on to get one of 1) new installation 2) migration from old Firefox 3) migration from current Firefox working.

Also, I think the add-on's scripts were written in early 2011 when the Add-on SDK was much newer in development, so various pieces of the code are obsoleted by the SDK.
It seems like it was #3 of where a current version of Firefox doesn't trigger the code to install bundled add-ons, so something like bug 660255 comment 2 was hackily added to get the add-on to install. I'm not sure if this is still being used or is necessary either.
I've done a little exploratory, after installing the proposed add-on from comment 16, with Firefox 20 beta 1 (build ID: 20130220104816) on the next machines: Windows 7 64-bit, Ubuntu 12.04 32-bit, Mac OSX 10.8.

Here are my results:

1) After the add-on instalation, when I manually set the "keyword.URL" pref from about:config in "http://www.evil.com", and perform a search from the awesomebar, the notification is showing up, but is asking me if I would like to restore the default search, Bing.

2) After 1), even if I reset the pref to its default value (empty string) and perform a search from the awesomebar, the search is still made with Bing.

3) If I try 2), only if I disable the Bing Search for Firefox 1 add-on manually, and perform a search from the awesomebar, the search is made with Google.

Are behaviors 1), 2) and 3) expected?

Note: When first installing the add-on, the value of the pref isn't changed (remains the default one).


Could you please tell me which is the new release target planned for the Awesomebar Search Provider feature? Is it Firefox 20 or later? Thank you.
Kris it looks like this got punted to you, can you do the finishing touches here?
Assignee: nobody → kmaglione+bmo
(In reply to Manuela Muntean [:Manuela] [QA] from comment #19)
> Are behaviors 1), 2) and 3) expected?

All three behaviors are expected, yes.

> Note: When first installing the add-on, the value of the pref isn't changed
> (remains the default one).

The value of keyword.URL is meant to be unchanged. When it's blank,
we use browser.search.defaultenginename instead.

> Could you please tell me which is the new release target planned for the
> Awesomebar Search Provider feature? Is it Firefox 20 or later? Thank you.

As of now, it's still on track for landing in Firefox 20 release.
Ok, thank you Kris!
(In reply to Kris Maglione [:kmag] from comment #21)
> (In reply to Manuela Muntean [:Manuela] [QA] from comment #19)
> > Are behaviors 1), 2) and 3) expected?
> 
> All three behaviors are expected, yes.
> 
> > Note: When first installing the add-on, the value of the pref isn't changed
> > (remains the default one).
> 
> The value of keyword.URL is meant to be unchanged. When it's blank,
> we use browser.search.defaultenginename instead.
> 
> > Could you please tell me which is the new release target planned for the
> > Awesomebar Search Provider feature? Is it Firefox 20 or later? Thank you.
> 
> As of now, it's still on track for landing in Firefox 20 release.

Thanks!
(In reply to Kev Needham [:kev] from comment #13)
> wrt comment #10 I'd be fine with hosting the addons on AMO, but we have an
> agreement with Bing to host it separately. Part of the reason it's not on
> AMO is because it didn't meet AMO requirements initially.
> 
> wrt comment #9 I'd love for updates to be hosted on AMO, too, but we'll need
> to run it by our partner, too.

Who should own this partner interaction bit? We'll have the code ready soon - ideally we will want to have the updates shipped and new versions staged before Firefox 20 is released (on April 2nd).
Flags: needinfo?(kev)
(In reply to Kris Maglione [:kmag] from comment #16)
> So there are essentially two options here: 1) Use something like my previous
> patch, with the minimal number of changes to fix the search issues, or 2)
> Use something like this version which fixes the other issue as well.

Per IRC discussion with Kris, let's got with 1) for now, and we can follow up with 2) once we have less time pressure and have figured out the update story.
I own the partner interaction.  

Will the experience be similar to what occurs today, where MSN users are directed from a marketing page (http://www.firefoxwithmsn.com/) and initiate the download which is hosted on releases.mozila.com?  If we make this change will we just host on an AMO directory rather than releases.mozilla.com?  If not, then that is a problem we'll need to discuss further.

If so, while the change may seem trivial technically - all of their marketing is outsourced and might take a while to make the requested changes.  (just setting your expectations...).  Would we be looking to have the change completed by GA launch of FF20 or sooner?

Thanks, Joanne
(In reply to Joanne Nagel from comment #26)
> If we make this change will we just host on an AMO directory rather than
> releases.mozilla.com?

No, we'd just update the version on releases.mozilla.com. I guess Kev's mention of "agreement with Bing to host it separately" confused me - if they are hosting it, we need to give them the updated file and have them only serve the new version. If we're the only ones hosting it, we can just update our copy (and let them know that we did, I imagine).

> If so, while the change may seem trivial technically - all of their
> marketing is outsourced and might take a while to make the requested
> changes.  (just setting your expectations...).  Would we be looking to have
> the change completed by GA launch of FF20 or sooner?

The goal is for this change to be made prior to the FF20 launch, yes. Hopefully given the above this won't require any marketing adjustments on their side.
Flags: needinfo?(kev)
To confirm - we are the only ones hosting it.  So, updating the version on releases.mozilla.com is perfect.  I will explain the new functionality (search prompt is new to them) and follow-up to the group if there are any questions I cannot answer.  Thanks again for everyone's effort on this!
(In reply to Kris Maglione [:kmag] from comment #4)
> I proposed a patch fixing all of those issues except the last:
> 
> https://gist.github.com/63f39616238430268ba7

I reviewed this patch, here are some comments:

>+ setPref(PREF_ENGINENAME, 'data:text/plain,' + encodeURIComponent(
>+ PREF_ENGINENAME + ' = ' + engineName.replace(/ /g, "\\u0020")));

Worth a comment here to explain why you're using a "\u0020" escape.

>+ // Clear the user value if it's the same, so prefHasUserValue
>+ // returns false.

Is there a specific reason this is needed, or is it just a precaution in case some other code happens to check prefHasUserValue for some reason?

r=me with the additional change from https://gist.github.com/5051866 included.

Can you generate an updated XPI and attach it here? Hopefully Manuela can help us test the new version and ensure it behaves identically to the current version.
Attachment #717289 - Flags: review?(gavin.sharp)
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #29)
> >+ setPref(PREF_ENGINENAME, 'data:text/plain,' + encodeURIComponent(
> >+ PREF_ENGINENAME + ' = ' + engineName.replace(/ /g, "\\u0020")));
> 
> Worth a comment here to explain why you're using a "\u0020" escape.

Already done.

> >+ // Clear the user value if it's the same, so prefHasUserValue
> >+ // returns false.
> 
> Is there a specific reason this is needed, or is it just a precaution in
> case some other code happens to check prefHasUserValue for some reason?

I added it because the KeywordURLResetPrompter module checks 
prefHasUserValue("keyword.URL"). Looking at it again, it seems 
like it will short circuit later because the domain is the same 
as the default search engine anyway, but it seems like clearing 
the user value is still the safe thing to do.

> Can you generate an updated XPI and attach it here? Hopefully Manuela can
> help us test the new version and ensure it behaves identically to the
> current version.

Will do.
Attached file Updated XPI (obsolete) —
Updated XPI with discussed changes. The complete updated diff for reference (the only additional changes being an added comment and a 1-line delta discussed offline): https://gist.github.com/78ab84c967c4c5b0b286
Manuela, can you help us with some testing to ensure that the add-on in comment 31 is functionally equivalent to the existing Bing add-on at http://releases.mozilla.com/bundles/bing/addon/ ? In particular, that the keyword search/homepage changing behavior between them is the same.

In addition, it would be good to confirm that it fixes the bad interaction with bug 718088, and that it properly handles undoing the keyword search modifications when it is disabled or uninstalled.
Keywords: qawanted
Flags: needinfo?(manuela.muntean)
As per comment 32, setting Manuela as QA Contact for this bug.
Flags: needinfo?(manuela.muntean)
QA Contact: manuela.muntean
Here are the results of my testing with Firefox 20 beta 3 builds (buildID: 20130305164032):

1) Mac OSX 10.8.2 and Windows 7 64-bit:

PART 1: 

- a) after installing the add-on in comment 31, the keyword.URL pref is changed to "http://www.bing.com/search?form=MOZPLB&pc=MOZO&q=" , the notification isnt't showing and the search is performed using Bing

- b) when disabling it and restarting Firefox, but also after uninstalling it, the pref is reset to its default value, the notification isnt't showing and the search is performed using Google

PART 2: 

- i) after installing the add-on from http://releases.mozilla.com/bundles/bing/addon/ , the pref keeps its default value, the notification isnt't showing and the search is performed using Google;  browser.search.defaultenginename  pref is set to Google

- ii) same behavior as i), when disabling or uninstalling the add-on


2) Ubuntu 12.04 32-bit:

PART 1: 

- a) after installing the add-on in comment 31, the keyword.URL pref is changed to "http://www.bing.com/search?form=MOZPLB&pc=MOZO&q=" , the notification isnt't showing and the search is performed using Bing

- b) when disabling it and restarting Firefox, but also after uninstalling it, the pref is reset to its default value, the notification isnt't showing and the search is performed using Google


PART 2: 

- i) after installing the add-on from http://releases.mozilla.com/bundles/bing/addon/ , the pref changes its value to "http://www.bing.com/search?form=MOZPLB&pc=MOZO&q=" , the notification is showing and the search is performed using Bing; browser.search.defaultenginename  pref is set to Google

- ii) same behavior as i), when disabling or uninstalling the add-on

I think this behavior (PART 2) on Ubuntu is a little worisome, because I don't think this is intended.
I'm not sure what you're saying about the http://releases.mozilla.com/bundles/bing/addon/ add-on. I see the same behavior that you describe on Ubuntu on Windows, and it's the behavior I'd expect. The behavior that you describe on Windows/OS-X seems to be as if the add-on was not installed.
The http://releases.mozilla.com/bundles/bing/addon/ add-on works for me just as I described in comment 34, PART 2, for both 1) and 2).

After installing this add-on, on the same profile on which I first installed the add-on from comment 31, (of course, after uninstalling the add-on from comment 31), for Windows and OS-X, the pref keeps its default value, the notification isnt't showing and the search is performed using Google;  browser.search.defaultenginename  pref is set to Google.  Same behavior when disabling or uninstalling this add-on.

As for Ubuntu, the pref changes its value to "http://www.bing.com/search?form=MOZPLB&pc=MOZO&q=" , the notification is showing and the search is performed using Bing; browser.search.defaultenginename  pref is set to Google. Same behavior when disabling or uninstalling this add-on.
I tested again just to be sure, and your experience on Windows doesn't match mine. In any case, I'm not particularly concerned with the behavior of the old versions, just that the new ones have the behavior that we've specified.
Keywords: qawanted
Attached patch MSN add-on diffSplinter Review
Same updates applied to the MSN add-on. There's a small amount of additional functionality in that one which I hadn't noticed before (it opens an app tab at startup), so it might need a light code review and QA.

Here's a meta diff, if your brain can handle such things: https://gist.github.com/34ca3302369f2a0ec090

I also noticed the add-on here that hadn't been mentioned before: http://releases.mozilla.com/bundles/msn/international/addon/

The only difference relative to the US version seems to be that a function was removed in helper.js, which breaks the app tab code.
Attachment #725112 - Flags: review?(gavin.sharp)
Attached file Updated MSN XPI
Attachment #717289 - Attachment is obsolete: true
Comment on attachment 725112 [details] [diff] [review]
MSN add-on diff

>diff -ur msn-orig/install.rdf msn/install.rdf

>-        <maxVersion>18.0</maxVersion>
>+        <maxVersion>19.*</maxVersion>

Hrm, this value should be at least "20", right? I suppose this isn't a problem for the other add-ons currently (which seem to have maxVersion=15) because we assume add-ons are compatible by default.
Attachment #725112 - Flags: review?(gavin.sharp) → review+
So in terms of next steps here, it seems like we need:
1) Make sure we have a complete list of affected add-ons, and have patched them all. Kris can provide the list of add-ons he has patched. Who is the right person to confirm that is complete? Joanne or Tomcat?

2) We need to re-pack all of the builds that include add-ons under http://releases.mozilla.com/bundles/. I don't know how they were previously produced, and how much work that would involve. Tomcat?

3) We need to get the updated versions of those add-ons on AMO, so that updates work correctly. Kris, once we have 1) I assume this is something you can do relatively easily?

4) We'll need to get the updated add-ons uploaded to releases.mozilla.com/bundles.

5) We'll need some QA on the add-ons from 3)&4) to ensure they're still functionally correct. We'll also want to QA that the old add-ons update to the new ones properly.
Flags: needinfo?(cbook)
If you visit this page from non-Firefox browsers:

https://twitter.com/download/firefox/

Get Firefox with Twitter links to 
http://releases.mozilla.com/twitter/mac/en-US/Firefox-Twitter.dmg
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #40)
> Comment on attachment 725112 [details] [diff] [review]
> MSN add-on diff
> 
> >diff -ur msn-orig/install.rdf msn/install.rdf
> 
> >-        <maxVersion>18.0</maxVersion>
> >+        <maxVersion>19.*</maxVersion>
> 
> Hrm, this value should be at least "20", right? I suppose this isn't a
> problem for the other add-ons currently (which seem to have maxVersion=15)
> because we assume add-ons are compatible by default.

It shouldn't matter, with default to compatible, but 20.* might make more sense given the context.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #41)
> So in terms of next steps here, it seems like we need:
> 1) Make sure we have a complete list of affected add-ons, and have patched
> them all. Kris can provide the list of add-ons he has patched. Who is the
> right person to confirm that is complete? Joanne or Tomcat?

I've patched the following:

http://releases.mozilla.com/bundles/bing/addon/bing.xpi
http://releases.mozilla.com/bundles/msn/us/addon/msn-us.xpi (identical to http://releases.mozilla.com/bundles/msn/us/msn-us.xpi)

I also updated http://releases.mozilla.com/bundles/msn/international/addon/msn-international.xpi but it seems to just be a slightly broken version of the msn-us.xpi

> 3) We need to get the updated versions of those add-ons on AMO, so that
> updates work correctly. Kris, once we have 1) I assume this is something you
> can do relatively easily?

Yes. We just need to decide who should own them. We use the Mozilla or Mozilla Labs accounts for most of our add-ons, but I'm not sure those would be appropriate here.
Attached file Updated Bing XPI
Bumped em:version and em:maxVersion in the Bing add-on.
Attachment #719714 - Attachment is obsolete: true
(In reply to Kris Maglione [:kmag] from comment #44)
> Yes. We just need to decide who should own them. We use the Mozilla or
> Mozilla Labs accounts for most of our add-ons, but I'm not sure those would
> be appropriate here.

Is there a way to provide update info for them without them appearing in public listings? That would be ideal. Otherwise, it seems like just using the Mozilla account would likely be fine.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #46)
> Is there a way to provide update info for them without them appearing in
> public listings? That would be ideal. Otherwise, it seems like just using
> the Mozilla account would likely be fine.

Not easily. It would require code changes, or redirecting matching version check requests to static update manifests in nginx, neither of which seems worth the trouble. We can use the Mozilla account for now.
Please add the "qawanted" keyword when this is ready for testing. Thanks!
(In reply to Edward Lee :Mardak from comment #42)
> If you visit this page from non-Firefox browsers:
> 
> https://twitter.com/download/firefox/
> 
> Get Firefox with Twitter links to 
> http://releases.mozilla.com/twitter/mac/en-US/Firefox-Twitter.dmg

That doesn't appear to include an extension. I don't think it's relevant.

(In reply to Manuela Muntean [:Manuela] [QA] from comment #48)
> Please add the "qawanted" keyword when this is ready for testing. Thanks!

I think this is ready for QA now.
Keywords: qawanted
(In reply to Kris Maglione [:kmag] from comment #49)
> (In reply to Edward Lee :Mardak from comment #42)
> > Get Firefox with Twitter links to 
> > http://releases.mozilla.com/twitter/mac/en-US/Firefox-Twitter.dmg
> That doesn't appear to include an extension. I don't think it's relevant.
If you open up the package Contents/MacOS/distribution/extensions directory has twitter.address.bar.search@firefox.twitter

> > https://twitter.com/download/firefox/
That url from Firefox browsers links to this add-on:
https://addons.mozilla.org/en-US/firefox/downloads/latest/318202/addon-318202-latest.xpi?src=external-twitter
Oh, I see, it's unpacked. I searched for XPIs.

This one is based on the same template as the MSN add-on, but with added location bar autocomplete features. I'll try to update this one on the train tomorrow, or some time this weekend.

Does anyone know if there are any others that haven't been mentioned yet? I don't want another last minute surprise backout for the 20 release.
(In reply to Edward Lee :Mardak from comment #50)
> > > https://twitter.com/download/firefox/
> That url from Firefox browsers links to this add-on:
> https://addons.mozilla.org/en-US/firefox/downloads/latest/318202/addon-
> 318202-latest.xpi?src=external-twitter

Well, at least there's some precedence for these add-ons being listed on AMO. I'm surprised that this passed review, though.
URL: o
It looks like the Firefox version in that bundle is 6.0.2 and the AMO listing is not owned by us. Is this an active partnership that we need to worry about?
(In reply to Kris Maglione [:kmag] from comment #53)
> the AMO listing is not owned by us.
I'm an unlisted owner of the add-on, but I haven't heard anything from Twitter about this addon for almost 2 years.

> Is this an active partnership that we need to worry about?
I'm not sure, but as linked above, Twitter is still linking to both a Firefox build and the add-on. I believe kev and dascher were the Mozilla contacts in terms of this partnership.
Considering https://bugzilla.mozilla.org/show_bug.cgi?id=738818#c4, point 3)a), how does this significant change affect the verification of this bug? Should I go on testing the behavior of the attachments from comment 39 and comment 45, only regarding the appearance of the notification?

Also, is it possible for this feature (Awesomebar Search Provider Reset, bug 718088) to be delayed until Firefox 21 is released?
(In reply to Manuela Muntean [:Manuela] [QA] from comment #55)
> Also, is it possible for this feature (Awesomebar Search Provider Reset, bug
> 718088) to be delayed until Firefox 21 is released?

Given the slow progress on this so far, we likely will end up delaying bug 718088 for another cycle.
Hey guys. This has already been delayed several times. We've got some goals around this update and more importantly we'll be helping to protect an insane number of users. Before we decide to delay I think we should meet to discuss this.
Bumping this to FF21 tracking, we're tracking the backout/delay for FF20 in bug 838864
I've done some testing on: Windows 7 32-bit, Ubuntu 12.04 32-bit and Mac OSX 10.8.2, with Firefox 20 RC (build ID: 20130326150557), with these add-ons:

http://releases.mozilla.com/bundles/bing/addon/bing.xpi
http://releases.mozilla.com/bundles/msn/us/addon/msn-us.xpi 
http://releases.mozilla.com/bundles/msn/us/msn-us.xpi
http://releases.mozilla.com/bundles/msn/international/addon/msn-international.xpi 
https://addons.mozilla.org/en-US/firefox/downloads/latest/318202/addon-318202-latest.xpi?src=external-twitter


On all 3 platforms, and with all 5 add-ons from above, I get the same results:

1) the notification doesn't appear anymore
2) after disabling any of the add-ons from above, the search from the awesomebar is still made using Bing (+ the notification doesn't appear anymore)
3) after disabling any of the add-ons from above and then restarting the browser, the search from the awesomebar is still made using Bing (+ the notification doesn't appear anymore)
4) after removing any of the add-ons from above, the search from the awesomebar is still made using Bing (+ the notification doesn't appear anymore)
5) after removing any of the add-ons from above and then restarting the browser, the search from the awesomebar is still made using Bing (+ the notification doesn't appear anymore)

Are 2), 3), 4) and 5) expected? Shouldn't Google be the search engine "in charge" after each of these steps is performed?

Regarding comment 41:

>5)[...] We'll also want to QA that the old add-ons update to the new ones properly.
Could you please give me more details regarding how this should be tested? Thanks!
(In reply to Manuela Muntean [:Manuela] [QA] from comment #59)
> http://releases.mozilla.com/bundles/bing/addon/bing.xpi
> http://releases.mozilla.com/bundles/msn/us/addon/msn-us.xpi 
> http://releases.mozilla.com/bundles/msn/us/msn-us.xpi
> http://releases.mozilla.com/bundles/msn/international/addon/msn-
> international.xpi 
> https://addons.mozilla.org/en-US/firefox/downloads/latest/318202/addon-
> 318202-latest.xpi?src=external-twitter

These copies haven't been updated to the latest version yet, AFAIK. I was hoping Tomcat could help with that, but I have not heard from him.

> >5)[...] We'll also want to QA that the old add-ons update to the new ones properly.
> Could you please give me more details regarding how this should be tested?
> Thanks!

This requires that we get the updated versions on AMO, which also hasn't happened yet.
Tomcat is on vacation until month end - Chris, can you help out here?
Flags: needinfo?(coop)
(In reply to Joanne Nagel from comment #61)
> Tomcat is on vacation until month end - Chris, can you help out here?

I'll take a look, but the chances of me gathering enough context to be useful before Tomcat gets back tomorrow are slim.
Flags: needinfo?(coop)
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #60)
> (In reply to Manuela Muntean [:Manuela] [QA] from comment #59)
> > http://releases.mozilla.com/bundles/bing/addon/bing.xpi
> > http://releases.mozilla.com/bundles/msn/us/addon/msn-us.xpi 
> > http://releases.mozilla.com/bundles/msn/us/msn-us.xpi
> > http://releases.mozilla.com/bundles/msn/international/addon/msn-
> > international.xpi 
> > https://addons.mozilla.org/en-US/firefox/downloads/latest/318202/addon-
> > 318202-latest.xpi?src=external-twitter
> 
> These copies haven't been updated to the latest version yet, AFAIK. I was
> hoping Tomcat could help with that, but I have not heard from him.

Yeah was on vacation but will replace the Addons for MSN and Bing today.

I guess the twitter one will be updated on AMO (where i was so far not involved in) right Gavin?

> 
> > >5)[...] We'll also want to QA that the old add-ons update to the new ones properly.
> > Could you please give me more details regarding how this should be tested?
> > Thanks!
> 
> This requires that we get the updated versions on AMO, which also hasn't
> happened yet.
Flags: needinfo?(cbook)
(In reply to Carsten Book [:Tomcat] from comment #63)
> I guess the twitter one will be updated on AMO (where i was so far not
> involved in) right Gavin?

That's still an open question. It's still not clear to me that we
should be updating the Twitter add-on, given that the bundle has not
been updated since Firefox 6. Mardak, you're an owner of the AMO
listing, are you confident that we should be updating this? 

Does anyone else know whether we should be updating the installer bundle?

If so, I'll have the updated add-on ready today.
Flags: needinfo?(edilee)
(In reply to Kris Maglione [:kmag] from comment #64)
> are you confident that we should be updating this? 
I'll defer to David Ascher. Can someone summarize what's the user experience with the old add-on bundled with the new Firefox?
Flags: needinfo?(edilee) → needinfo?(dascher)
The behavior, as far as users are concerned, should be identical.
Sorry, not entirely identical. The default search engine will be restored when the add-ons are uninstalled, which was not the case before. But while the add-ons are installed, the experience should be the same.
(In reply to Kris Maglione [:kmag] from comment #64)
> Does anyone else know whether we should be updating the installer bundle?
> 
> If so, I'll have the updated add-on ready today.

If we decide to do so and i have the updated addon from Kris, thats easy to do
I think we should update the Twitter add-on. And in case it wasn't clear from comment 41, we should also "re-pack" any installers that include the affected add-ons.
Flags: needinfo?(dascher)
OK, I'll have an updated version of the Twitter add-on ready tonight.

The add-on claims XUL Fennec support. Are we OK to drop that?
The Twitter add-on, it turns out, does not change the default search engine or keyword URL (which I guess makes sense). It looks like its app tab code is still leaking every browser window that ever opens, so it should still be updated, but it's outside the scope of this bug. If someone wants to review a patch for that purpose, please let me know, otherwise I'm going to have to send a message to Twitter via AMO asking that it be fixed.
Just spoke to Kris on irc on this & we are waiting on :

a) Tomcat, can you please confirm if the Addons for MSN and Bing today have been updated per comment# 63 ? Once this is done, QA can go ahead and help with final verification on the updated bundles.
b) Kris, will be getting back on the final decision regarding the Twitter add-on, since they're bundled with Firefox now .
I'll also need to know when the new bundles are live so that I can upload the add-ons to AMO. I don't want to do it before hand, since I don't think that a silent update of these add-ons on first run will lead to a good user experience.
(In reply to bhavana bajaj [:bajaj] from comment #72)
> Just spoke to Kris on irc on this & we are waiting on :
> 
> a) Tomcat, can you please confirm if the Addons for MSN and Bing today have
> been updated per comment# 63 ? Once this is done, QA can go ahead and help
> with final verification on the updated bundles.

Hey, yeah confirmed,the addons are live.
I've done some testing on: Windows 7 64-bit, Ubuntu 12.04 32-bit and Mac OSX 10.8.3, with Firefox 20.0.1 RC (build ID: 20130409194949) and Firefox 21 beta 2 (build ID: 20130408165307), with these add-ons:

https://addons.mozilla.org/addon/bing-search-for-firefox/
https://addons.mozilla.org/addon/msn-for-firefox/


On all 3 platforms, with both add-ons and builds from above, I get the same results:

1) the notification doesn't appear anymore and the search is performed with Bing
2) after disabling any of the add-ons from above, the search from the awesomebar is made using Google 
3) after removing any of the add-ons from above, the search from the awesomebar is made using Google
No longer need to track for 21, given the resolution of bug 718088/bug 838864, but we do need to make sure we're OK for 23 given bug 738818.
Keywords: qawanted
Do we have anything left to do here? As I understand it:

a) the updated add-ons are live on addons.mozilla.org, they should be updating existing users
b) the add-on copies at http://releases.mozilla.com/bundles/ have been updated (comment 74)

I think the remaining questions are:
i) have we verified that the updates of previous versions of the add-on via AMO work?
ii) have all of the builds under http://releases.mozilla.com/bundles/ been repacked? I see that the Bing builds have been modified May 15, but I don't see equivalent changes to all of the files under http://releases.mozilla.com/bundles/msn/
Flags: needinfo?(manuela.muntean)
Flags: needinfo?(cbook)
> I think the remaining questions are:
> i) have we verified that the updates of previous versions of the add-on via
> AMO work?

I can't find older versions of the add-ons on AMO. Where can I find them, so I can install them and see that they update to the newest version?

I have searched for them here:

https://addons.mozilla.org/en-US/firefox/addon/bing-search-for-firefox/versions/
https://addons.mozilla.org/en-US/firefox/addon/msn-for-firefox/versions/
Flags: needinfo?(manuela.muntean)
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #78)

> I think the remaining questions are:
> i) have we verified that the updates of previous versions of the add-on via
> AMO work?
> ii) have all of the builds under http://releases.mozilla.com/bundles/ been
> repacked? I see that the Bing builds have been modified May 15, but I don't
> see equivalent changes to all of the files under
> http://releases.mozilla.com/bundles/msn/

The update was done, see https://hg.mozilla.org/build/partner-repacks/rev/914554e39b91 so should be fine
Flags: needinfo?(cbook)
Flags: needinfo?(gavin.sharp)
Looks like we now only need to address Manuela's question in comment 79 - can someone help close the loop here?
Flags: needinfo?(kmaglione+bmo)
Jorge - can you help with comment 79? Just want to close the loop here.
Flags: needinfo?(jorge)
Kris, do we have access to the old versions?
Flags: needinfo?(jorge)
Marking this as status fixed, though the outstanding questions should be answered if possible, but since we haven't had reports of fallout we'll move forward with release and this is not blocking.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(gavin.sharp)
Resolution: --- → FIXED
Flags: needinfo?(kmaglione+bmo)
Target Milestone: --- → Firefox 23
You need to log in before you can comment on or make changes to this bug.