Block old Ask.com Toolbar versions

RESOLVED FIXED

Status

()

Toolkit
Blocklisting
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: Dave Garrett, Assigned: morgamic)

Tracking

({common-issue+})

unspecified
common-issue+
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(status2.0 wanted)

Details

(Whiteboard: [Input])

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

7 years ago
Install the Ask.com toolbar in Firefox 3.6:
http://sp.ask.com/toolbar/install/web/ask/download.php

I'm pretty sure there are other ways to get this toolbar installed but this is the most direct route.

It works fine under Firefox 3.6. Next, try it under a Firefox 4.0 beta. On every startup you'll get a popup alert dialog with the title "[JavaScript Application]" and the message:

what happened:TypeError: Components.classes['@mozilla.org/extensions/manager;1'] is undefined

Clearly this extension is not compatible with the Addon Manager backend changes for Gecko 2.0.

Note that you did not have to disable addon compatibility checking for this to have the error. Why? Here are some relevant portions of this extension's install.rdf:

<em:id>toolbar@ask.com</em:id>
<em:name>Ask Toolbar</em:name>

<em:creator>Ask.com</em:creator>
<em:homepageURL>http://www.ask.com/</em:homepageURL>
<em:version>3.8.0.12304</em:version>

<em:targetApplication>  <!-- Firefox -->
    <Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>2.0</em:minVersion>
        <em:maxVersion>5.*</em:maxVersion>
    </Description>
</em:targetApplication>

It's apparently lying and saying it's compatible with Firefox 5.* (yes, five). For now this results in an error message, but I could easily imagine a completely new issue with a startup freeze or who knows what by the time we get to Firefox 5.next. It's claiming to be compatible with things which have not yet been conceived of. This is dumb and Ask.com should clearly not be doing this.

I see no update URL listed so unless it's actually updating via AMO or there's some other update method I don't see here users are generally stuck with whatever they happen to have installed. The error message is cryptic to users and generic to us.

There is now a steady stream of bugs filed by confused Firefox 4 beta testers which I am duping on this issue (bug 578099). This will only get worse after the Firefox 4.0 release and if not dealt with may even persist out to Firefox 5.next. Apparently a fix won't be forthcoming due to the lack of an apparent update channel.

Hopefully someone here knows how to get into proper contact with Ask.com and:
  a) Tell them to stop forging their maxVersion
  b) Find out if there are any newer versions or other IDs which do this
  c) Fix the actual problem, which shouldn't be too hard:
     https://developer.mozilla.org/en/Firefox_4_for_developers

Can this extension please be soft blocklisted for Firefox 4 and up? I don't know the specific version it broke; it could be 3.7a1pre or 3.7a5pre. A minimum version to block for could just be 4.0b1 as well. As to what versions of the extension to block, I think 3.8.0.* and under at least. More info would be helpful here.

For the reason for blocklisting to be added to the mozilla.com blocklist page, say "fraudulent metadata and incompatibility with Firefox 4.0+" or just "incompatibility with Firefox 4.0+".
(Reporter)

Comment 1

7 years ago
(In reply to comment #0)
> I don't know the specific version it broke; it could be 3.7a1pre or 3.7a5pre.

By which I mean more things than this error message may be broken.
(Reporter)

Comment 2

7 years ago
Just for the sake of completeness, here are all the reports for this addon via the compatibility reporting tool:
https://addons.mozilla.org/en-US/firefox/compatibility/reporter/toolbar@ask.com
(there are a few pages of duplicates in the middle for some unknown problem)

A few comments left by Firefox 4.0 beta users:

3.6.5.112   Firefox 4.0b1 20100630141702  Windows NT 6.0  2010-07-15
british english dictionary is not yet included on firefox.4 can these be modified

3.4.4.118   Firefox 4.0b1 20100630141702  Windows NT 5.1  2010-07-17
when it is enable, it caused me with this error message: Components.classes['@mozilla.org/extensions/manager;1'] is undefined

3.6.6.117   Firefox 4.0b2 20100720190347  Windows NT 6.1; WOW64  2010-08-02
"Select language" option does not work - compressed to a vertical line.

3.6.6.117   Firefox 4.0b2 20100720190347  Windows NT 6.1; WOW64  2010-08-05
I get a pop-up that seems to show some script with a message about a type error

3.8.0.12304 Firefox 4.0b5pre 20100820074529  Windows NT 5.1  2010-08-20
causes things not to load

3.6.6.117   Firefox 4.0b4   20100818132640  Windows NT 6.1; WOW64  2010-08-30
FUCK YOU GODDAM BITCHES DONT FUCKING INSTALL SHIT ON MY COMPUTER

So... few things learned here:
* This extensions' options window is also broken
* This extension may or may not break something else
* At least one guy is furious that this extension was installed without permission
(Reporter)

Comment 3

7 years ago
There are also some reports in the compatibility reporter and elsewhere about some problems under Firefox 3.x, but that's another issue entirely.
See also bug 530747.
Assignee: nobody → morgamic
Target Milestone: --- → 5.12
(Reporter)

Comment 5

7 years ago
Created attachment 470839 [details]
security warnings from the addon validator

If anyone is curious as to what the addon validator says about this thing:
* Lots of warnings related to not using native JSON
* An nsIProcess usage in core.js
* multiple usages of netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead") in network.js
* Escaped Unicode in json.js, toolbar.xul, and cache.sqlite
* Known home page changing
* Adds itself to the user agent string (which will no longer work with the removal of general.useragent.extra.* for 4.0b5)

If someone from Ask.com would like to take a look at this and fix these problems along with the addon manager backend support in a new version, that'd be great. For now, this is a recurring problem for Firefox 4 beta users and it looks like it's apparently going to get worse whenever enablePrivilege gets removed (I don't know the schedule on that; it's bug 546848).
(Reporter)

Comment 6

7 years ago
Kev Needham: Are you or someone you know able to contact Ask.com about this?

Comment 7

7 years ago
yes. on it.
(Reporter)

Comment 8

7 years ago
Thanks Kev!

By the way, I'm aware that I probably posted way more info than necessary. I just wanted to be thorough because some bugs like this have a tendency to stall.

Comment 9

7 years ago
Adding rdoherty. I've asked my contacts at Ask.com to provide a toolbar dev contact, and outlined that the toolbar is causing problems, using an invalid MaxVersion, and is a blocklist candidate.

Handing over to rdhoerty for go/no go on blocklisting.
(Reporter)

Comment 10

7 years ago
I said soft blocklist initially in comment 0, but a full hard block might be warranted because of the potential for complete breakage out to Firefox 5.x.
Target Milestone: 5.12 → ---

Comment 11

7 years ago
The ask.com toolbar is creepware/spyware that installs itself surreptitiously with other programs (bug 451106 "Firefox Hijacked"). My Firefox was infected when I installed an (otherwise fine) mobile syncing tool called MyPhoneExplorer. The ask.com extension didn't even show up in the addons list! This extension should be blacklisted for all versions of Firefox, because it doesn't respect the Mozilla principle that users should have control over what is installed on their computers.
(Reporter)

Comment 12

7 years ago
kev & rdhoerty: What's the status on this going through with this block?

quidam: Before Firefox 3.6 there used to be a way to allow extensions to hide themselves if they were supposed unimportant dependencies installed on the system. This was clearly abused and was removed. As of Firefox 3.6 and more so for Firefox 4.0, every extension that is installed will be made known at least in the Addons Manager list. I am personally not thrilled with this extension in general, however this particular bug is just for Firefox 4 related issues so let's please keep this bug on that topic and file others as need be.
(Reporter)

Comment 13

7 years ago
Just noticed today's Firefox planning meeting notes:
https://wiki.mozilla.org/Firefox/Planning/2010-10-20#Highlights_.2F_Notices

The unknown "Error at Start-Up" is this stupid toolbar.

From Input, 386 total reports:
http://input.mozilla.com/en-US/search/?product=firefox&date_start=01%2F01%2F2010&q=what+happened%3ATypeError

From SUMO, 239 total reports:
https://support.mozilla.com/en-US/questions/755114

This thing needs to be dealt with before Firefox 4 is released, preferably ASAP. Requesting blocking final release.
blocking2.0: --- → ?
status2.0: --- → ?
Keywords: common-issue+
Whiteboard: [Input]

Comment 14

7 years ago
Ask.com has started to push out a fix, and agree that affected versions should be blocked for 4.0b7. I've discussed with their dev team, and they are aware that they may be added to the blocklist, so we can push.

Morgamic/Beltzner: any comments or concerns? I'll get version info and append to the bug.

Comment 15

7 years ago
To be a little more clear: _I_ agree that affected versions should be blocked for 4.0b7 (and beyond).

(In reply to comment #14)
> Ask.com has started to push out a fix, and agree that affected versions should
> be blocked for 4.0b7.
(Reporter)

Comment 16

7 years ago
(In reply to comment #14)
> Ask.com has started to push out a fix

Just to clarify: they are pushing a new version with a fix for the error AND a non-bogus max version in their install.rdf?

Comment 17

7 years ago
They're working on a fix for the error in an upcoming release, and are pushing a new version with a correctly-set maxVersion.
(Reporter)

Comment 18

7 years ago
(In reply to comment #17)
> They're working on a fix for the error in an upcoming release, and are pushing
> a new version with a correctly-set maxVersion.

Firefox 4 won't update to a new version that says it isn't compatible. (a valid max version would be 3.6.*) In other words, unless they're hacking around with an external updater, the only way to quash this error for Firefox 4 users before they push a fix for the actual compatibility problem is to blocklist all toolbar versions with the bogus install.rdf for Firefox 4+.
(Reporter)

Comment 19

7 years ago
(In reply to comment #18)
> blocklist all toolbar versions with the bogus install.rdf for Firefox 4+

More precisely, block for Firefox 3.7a5pre+ or just 3.7a1pre+ or 4.0b1+

Comment 20

7 years ago
The intent is to blocklist all versions that have maxVersion set incorrectly, which would cause Fx4 to look for updates. Ask has created an updated version of the current extension that has the maxVersion set to 3.6.* and increments the version. In some cases they can push it out to users via a separate update, but I think we're on the same page (e.g. blocklist up to and including the current versions, which are horked in Fx4 because of an improper maxVersion).

Newer versions will have the maxVersion set properly, and should not load.

A future release, which is being worked on according to Ask.com, will be compatible.
(Reporter)

Comment 21

7 years ago
Update? When can we pull the trigger on this and push the block?

Comment 22

7 years ago
I just installed the ask.com toolbar (in a safe VM) and got version 3.9.1.14019 which has a minVersion2.0 and maxVersion 4.*, and appears to basically work correctly in Firefox 4 nightlies/betas.
(Reporter)

Comment 23

7 years ago
(In reply to comment #22)
> I just installed the ask.com toolbar (in a safe VM) and got version 3.9.1.14019
> which has a minVersion2.0 and maxVersion 4.*, and appears to basically work
> correctly in Firefox 4 nightlies/betas.

A max version of 4.* is still wrong. Are you sure it wasn't 4.0.* or did they actually screw it up in the fixed version? Better than 5.*, mind you, but still will probably break at some point.

Kev: What's going on with this bug? Blocklist bugs seem to never get done even if everyone agrees on the way forward. Per comment 20 we should have at least blocked all versions below whatever version set a max of 3.6.* for Firefox 4+.

Comment 24

7 years ago
Yes, I am sure it was 4.*
(Reporter)

Comment 25

7 years ago
Apparently this extension also needs certain versions blocked because it's causing a crash. See bug 612088. Not sure if the range there is the same as what's needed here or a subset. If this range is larger, then only one block will need to be added to cover both. Adding dependency.

Just need to know what the range is on this one. Kev?
Blocks: 612088
(Reporter)

Comment 26

7 years ago
(In reply to comment #25)
> Not sure if the range there is the same as
> what's needed here or a subset. If this range is larger, then only one block
> will need to be added to cover both.

Answering my own question: The version info from comment 0 says that Ask Toolbar 3.8 still has the bogus 5.* max version, which is after the 3.6 range mentioned in bug 612088. Putting through this block request would cover that one too.

Comment 27

7 years ago
They do get done, but we do try to exhaust all other options before we bring it in. From talking to the Ask.com toolbar dev team, the older, incompatible versions of the toolbar are blocklist candidates for a couple of reasons, mainly the invalid MaxVersion and that there's no updateURL and/or AMO update in the majority of installs out there.

We definitely need to confirm versions, and we should probably blocklist this one unless there's objections to do so. Does anyone have any objections?

k

(In reply to comment #23)
> Kev: What's going on with this bug? Blocklist bugs seem to never get done even
> if everyone agrees on the way forward. Per comment 20 we should have at least
> blocked all versions below whatever version set a max of 3.6.* for Firefox 4+.

Comment 28

7 years ago
The blocklist requested in bug 612088 is a known topcrash and needs to happen *now*. That is a much smaller request than the more expansive request logged here.
blocking2.0: ? → beta8+

Comment 29

7 years ago
Created attachment 494208 [details] [diff] [review]
Possible patch to block ask toolbar
Attachment #494208 - Flags: review?

Updated

7 years ago
Attachment #494208 - Flags: review? → review?(dtownsend)

Comment 30

7 years ago
Posted a possible patch. Likely want to not restrict the minimum version of the ask toolbar as the block is restricted only to FF4, but I kept it a bit narrow to be slightly safer.
Comment on attachment 494208 [details] [diff] [review]
Possible patch to block ask toolbar

>diff --git a/browser/app/blocklist.xml b/browser/app/blocklist.xml
>--- a/browser/app/blocklist.xml
>+++ b/browser/app/blocklist.xml
>@@ -13,16 +13,23 @@
>     </emItem>
>     <emItem id="mozilla_cc@internetdownloadmanager.com">
>       <versionRange minVersion="2.1" maxVersion="3.3">
>         <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
>            <versionRange minVersion="3.0a1" maxVersion="*"/>
>         </targetApplication>
>       </versionRange>
>     </emItem>
>+    <emItem id="toolbar@ask.com">
>+      <versionRange minVersion="3.6" maxVersion="3.8.*">
>+        <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
>+           <versionRange minVersion="4.0b*" maxVersion="4.0.*"/>

As a rule using * in a minVersion will not do what you expect. It will not for example block all beta versions here. Use a specific minVersion like "4.0b1pre" assuming that is what you want.

Note that unless the database has been updated with the same block then the add-on will get re-enabled around a day after.
Attachment #494208 - Flags: review?(dtownsend) → review-

Comment 32

7 years ago
Created attachment 494209 [details] [diff] [review]
Blcok ask, now ith explicit beta1 minversion
Attachment #494208 - Attachment is obsolete: true

Comment 33

7 years ago
The AMO database stuff is in bug 612088. Not sure if we want to merge them into one bug.

Updated

7 years ago
Attachment #494209 - Flags: review?(dtownsend)

Comment 34

7 years ago
Created attachment 494225 [details] [diff] [review]
Block Ask Toolbar 3.6-3.8.* XML

No need to have a MaxVersion as mossop pointed out
Attachment #494225 - Flags: review?(dtownsend)

Updated

7 years ago
Attachment #494209 - Attachment is obsolete: true
Attachment #494209 - Flags: review?(dtownsend)
(Reporter)

Comment 35

7 years ago
As I mentioned above, the actual minimum affected Firefox version for this bug is 3.7a5pre if you wish to be precise.

As to the addon's version, for this bug the minimum should be "*" and I'm not exactly sure what the max should be. Per comment 22, I guess we could block up to and including 3.9.1.0 (unless we wish to get more precise than that and someone knows the exact subversion).

(In reply to comment #33)
> The AMO database stuff is in bug 612088. Not sure if we want to merge them into
> one bug.

This addon version range is a superset of the one for bug 612088. That bug only needs to get 3.6-3.8, whereas the user feedback I gathered in comment 2 shows that this problem here exists down to at least 3.4 (possibly earlier), so blocking everything below the current known "fixed" version would be the best route. That would mean a range of 0 - 3.9.1, so putting in the one block here would cover both problems.

These extensions end up on peoples' computers via many routes, without necessarily update routes. If we want to fix it for everyone we'll need to block the whole range preceding the current version for all Firefox 4 users.

Comment 36

7 years ago
Concur with Comment #35 in that minVersion should be 0. I've asked the product lead at Ask.com for the current version of their product, and made them aware of bug 612088 per comment #28. They were aware that we were going to put them on the BL for 4.0, so the BL policy has been satisfied, and I'm guessing 612088 means their current version is still incompatible.

If 3.9.1 is the current latest version, we can put that in and push, or wait until tomorrow when I hear back from Ask's product team.

Comment 37

7 years ago
I was going to wait until tomorrow in any case, so we'll (hopefully) hear what they have to say.
(Reporter)

Comment 38

7 years ago
It seems the blocklist.xml uses an empty min version of " " (quotes+space), not a zero or "*". At least that's what others in the list do. The XML would then be:

<emItem id="toolbar@ask.com">
  <versionRange minVersion=" " maxVersion="3.9.1.0">
    <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
      <versionRange minVersion="3.7a5pre" maxVersion="*"/>
    </targetApplication>
  </versionRange>
</emItem>

Or 3.9.1.something if we hear back with the exact last version to have the bogus 5.* max version. (or if we get the exact current working version, then that minus one)
(Reporter)

Comment 39

7 years ago
(In reply to comment #36)
> I'm guessing 612088 means their current version is still incompatible.

Benjamin Smedberg said up in comment 22 that version 3.9.1.14019 appears to work fine in the current Firefox 4 nightlies.

I might've suggested blocking up to 3.9.1.14018, but that might not be safe because for all I know that version is perfectly fine too. I'd ~guess~ 3.9.1 as the version with the full fix, but I simply don't know. We do know at least all 3.8.* are bad for this bug and the other as well.
(Reporter)

Comment 40

7 years ago
Oh, and I have no idea about 3.9.0 either, but I'd just block it for good measure if we're getting everything else. If Ask.com gives us the exact number that of course would be the one to go by.

Comment 41

7 years ago
Kev, any news from Ask?

Comment 42

7 years ago
Yes. We spoke today, and their dev team is looking into both bugs. They're putting a matrix together of what's compatible where, and will have it to me tonight or first thing in the am. The topcrasher we're seeing is caused by an audioplayer they include on select versions of the addon (e.g. distributed with Limewire) for mp3 and other audio playback. 

It's not included with all versions of the toolbars Ask distributes, and they're putting together a list of what versions are affected (guids and version numbers). Just waiting on an email. Apologies for not updating earlier.
(Reporter)

Updated

7 years ago
Attachment #494225 - Attachment description: Block ask → Block Ask Toolbar 3.6-3.8.* XML
Attachment #494225 - Attachment is obsolete: true
Attachment #494225 - Flags: review?(dtownsend)

Comment 43

7 years ago
Email back from Ask says these are the versions that work on FF4:

o   3.6.12
o   3.6.13
o   3.9.1
o   3.9.2
o   3.11
o   3.6.0.99999
o   3.6.1.99999
o   3.6.2.99999
o   3.6.3.99999
o   3.6.5.99999
o   3.6.6.99999
o   3.6.8.99999
o   3.6.9.99999
o   3.6.10.99999
o   3.6.12.99999
o   3.7.0.99999
o   3.7.1.99999
o   3.8.0.99999
o   3.8.1.99999
o   3.9.0.99999
o   All versions higher than 3.11 will be supported in Firefox 4.0

I've put together a quick python script to generate the proper XML. Do we support multiple versionRange's in an emItem or do I need to create individual emItems? The XML namespace doesn't seem to exist (http://www.mozilla.org/2006/addons-blocklist).
(Reporter)

Comment 44

7 years ago
(In reply to comment #43)
> Email back from Ask says these are the versions that work on FF4:
> 
> o   3.6.12
> o   3.6.13
> o   3.9.1
> o   3.9.2
> o   3.11
> o   3.6.0.99999
> o   3.6.1.99999
> o   3.6.2.99999
> o   3.6.3.99999
> o   3.6.5.99999
> o   3.6.6.99999
> o   3.6.8.99999
> o   3.6.9.99999
> o   3.6.10.99999
> o   3.6.12.99999
> o   3.7.0.99999
> o   3.7.1.99999
> o   3.8.0.99999
> o   3.8.1.99999
> o   3.9.0.99999
> o   All versions higher than 3.11 will be supported in Firefox 4.0

Huh? That's an... interesting list, as none of those are real version numbers. ("99999"?) I think there may have been a bit of a miscommunication here. In any case, even if they did branch fixes (i.e. 3.6.n is broken and 3.6.n+1 is fine) we should only block one linear range, which has to include everything up to and including one specific version. It a block only to apply for FF4 users so we don't need to parse things here; we just block everything not compatible with FF4 just for FF4. Based on that last line does that mean they want us to block up to 3.11.*? (which would be everything including current) I'd much rather block up to wherever the problem of using a bogus max version was (partially) fixed, which would then be 3.9.1 as I said earlier (I think). Either would cover the issue, however.

> I've put together a quick python script to generate the proper XML. Do we
> support multiple versionRange's in an emItem or do I need to create individual
> emItems?

It's added to an AMO database which in turn generates the proper XML when requested by clients. (and is also packaged with installers/updates) If it's going to be one range, so I don't think we need more than someone to write the proper SQL and the XML patch if also needed is simple to write without a script. (unless I'm missing something?)
(Reporter)

Comment 45

7 years ago
To be clear, if Ask did something strange like adding support for new Gecko APIs in old toolbar minor version updates, we shouldn't go along with that and bloat up the blocklist with dozens of little ranges. New versions are where new things should be added; that's sorta the point of version numbers. Seeing as this block is just for FF4 users anyway, one block range should be more than fine.

Comment 46

7 years ago
(In reply to comment #44)
> (In reply to comment #43)
> Huh? That's an... interesting list, as none of those are real version numbers.
> ("99999"?) I think there may have been a bit of a miscommunication here.

Nope, this is the list copied out of email. They updated some versions as well
as pushed ".99999" versions out to existing ones that are supported on FF4. We
gave them a heads up about doing this in October (I wasn't involved so I don't know if we suggested it or if we just said it was possible).

> In any
> case, even if they did branch fixes (i.e. 3.6.n is broken and 3.6.n+1 is fine)
> we should only block one linear range, which has to include everything up to
> and including one specific version.It a block only to apply for FF4 users so
> we don't need to parse things here; we just block everything not compatible
> with FF4 just for FF4. 

The list is the list of versions that work on FF4. We can't just kill a whole
linear range as the support is patchy. Hvaing multiple ranges makes sure we
block known-incompatible versions and allow people to use the versions that
work with FF4

> Based on that last line does that mean they want us to
> block up to 3.11.*? 

No, they want us to block the versions that don't work with FF4. Working
backwards from the FF4 supported list above, that's:

Block   -> 3.5.*
Block 3.6.0 -> 3.6.0.99998
Block 3.6.1 -> 3.6.1.99998
Block 3.6.2 -> 3.6.2.99998
Block 3.6.3 -> 3.6.3.99998
Block 3.6.4 -> 3.6.4.99998
Block 3.6.5 -> 3.6.5.99998
Block 3.6.6 -> 3.6.6.99998
Block 3.6.7 -> 3.6.7.99998
Block 3.6.8 -> 3.6.8.99998
Block 3.6.9 -> 3.6.9.99998
Block 3.6.10 -> 3.6.10.99998
Block 3.6.11 -> 3.6.11.99998
Block 3.6.12 -> 3.6.12.99998
Block 3.7.0 -> 3.7.0.99998
Block 3.7.1 -> 3.7.1.99998
Block 3.8.0 -> 3.8.0.99998
Block 3.8.1 -> 3.8.1.99998
Block 3.9.0 -> 3.9.0.99998

> It's added to an AMO database which in turn generates the proper XML when
> requested by clients. (and is also packaged with installers/updates) If it's
> going to be one range, so I don't think we need more than someone to write the
> proper SQL and the XML patch if also needed is simple to write without a
> script. (unless I'm missing something?)

Errr, I'm not sure how this was handled in the past. I know that the m-c
version isn't updated automatically from the AM database (bug 426214). I don't
know if we typically do the database changes first and then manually copy the
resulting XML into the tree, or if we do both changes separately and manually.

(In reply to comment #45)
> To be clear, if Ask did something strange like adding support for new Gecko
> APIs in old toolbar minor version updates, we shouldn't go along with that and
> bloat up the blocklist with dozens of little ranges.

I disagree. Keeping users and a partner happy at the cost of having a couple more entries in an XML file that is rarely looked at seems like an easy choice. We don't want arbitrary blocks, we only want to block for known reasons. The known reason is FF4 incompatibility, so we shouldn't block anything that's compatible.

Comment 47

7 years ago
(In reply to comment #46)
> > Huh? That's an... interesting list, as none of those are real version numbers.
> > ("99999"?) I think there may have been a bit of a miscommunication here.
> 
> Nope, this is the list copied out of email. They updated some versions as well
> as pushed ".99999" versions out to existing ones that are supported on FF4. We
> gave them a heads up about doing this in October (I wasn't involved so I don't
> know if we suggested it or if we just said it was possible).

I was directly involved, and I don't ever recall suggesting updating point releases with a new version. My assumption was that, since an update was being pushed, they'd update it to the latest codebase and version number. I didn't say that explicitly, just that we identify by ID and version numbers, and we needed to be able to differentiate. I do think what's "right" wrt versioning is super-subjective, and if we have a versioning policy it may not be publicized well. Like Christian, I'd like to avoid blocking good versions, and it's something we can continue to work with Ask to reduce it to a range.
(Reporter)

Comment 48

7 years ago
(In reply to comment #46)
> (In reply to comment #45)
> > To be clear, if Ask did something strange like adding support for new Gecko
> > APIs in old toolbar minor version updates, we shouldn't go along with that and
> > bloat up the blocklist with dozens of little ranges.
> 
> I disagree. Keeping users and a partner happy at the cost of having a couple
> more entries in an XML file that is rarely looked at seems like an easy choice.

The word "couple" generally refers to the number two. You're suggesting:

> Block   -> 3.5.*
> Block 3.6.0 -> 3.6.0.99998
> Block 3.6.1 -> 3.6.1.99998
> Block 3.6.2 -> 3.6.2.99998
> Block 3.6.3 -> 3.6.3.99998
> Block 3.6.4 -> 3.6.4.99998
> Block 3.6.5 -> 3.6.5.99998
> Block 3.6.6 -> 3.6.6.99998
> Block 3.6.7 -> 3.6.7.99998
> Block 3.6.8 -> 3.6.8.99998
> Block 3.6.9 -> 3.6.9.99998
> Block 3.6.10 -> 3.6.10.99998
> Block 3.6.11 -> 3.6.11.99998
> Block 3.6.12 -> 3.6.12.99998
> Block 3.7.0 -> 3.7.0.99998
> Block 3.7.1 -> 3.7.1.99998
> Block 3.8.0 -> 3.8.0.99998
> Block 3.8.1 -> 3.8.1.99998
> Block 3.9.0 -> 3.9.0.99998

That's 19, not a couple. I don't think it's reasonable for literally half of AMO's blocklist.xml to be taken up with nit-picking ranges for Ask's toolbar. You're suggesting doubling the load put on the client's blocklist system at startup just for this.

Additionally, there's whatever ranges are needed for bug 612088. Over there it was going to be 3.6-3.8.*, which already merges the almost all of that together to essentially:

0 - 3.5.*
3.6 - 3.8.*
3.9.0 -> 3.9.0.99998

Which could easily be reduced to 0 - 3.9.0.99998. (which is pretty much the 0 - 3.9.1 suggested earlier)
(Reporter)

Comment 49

7 years ago
For the record, if this were a block that affected all users I would be more sympathetic and a multi-range kludge might make sense, but it's not. This is a Firefox 4 only block that affects beta users, i.e. zero stable Firefox users. Firefox 4.0 final won't be out for a while and Ask can deal with their old versions situation in the plenty of available time.

To quote Benjamin Smedberg in comment 28, the main portion of this big range needs to be blocked "*now*" for a topcrash (bug 612088). When combining the ranges it becomes one simple range to cover both, which is preferable to doing one and then another to expand later. (at least in my opinion) They both need doing, so it makes sense to do the full route instead of piecemeal solution.

Comment 50

7 years ago
Created attachment 495591 [details] [diff] [review]
Blocklist ask versions that claim they are compatible with 4.0 betas but really aren't
Attachment #495591 - Flags: review?(dtownsend)
Comment on attachment 495591 [details] [diff] [review]
Blocklist ask versions that claim they are compatible with 4.0 betas but really aren't

feedback+ from me, as one of the extension's developers.  This looks right, from our perspective.
Attachment #495591 - Flags: feedback+

Comment 52

7 years ago
I'm going to make this not block beta8. Now that we think we fixed the startup crash in bug 612088 I don't think it is as urgent. Also, Ask says a fair amount of their users are on versions that support FF4. I'm asking for specific numbers of users running FF4 that aren't running a compatible version, but unless that number is surprising large I don't think we'll block. If that's the case we can also update it on AMO and people will eventually see the incompatible ones blocked, as I don't think the incompatible toolbars prevent users from using FF4.
blocking2.0: beta8+ → ---
status2.0: ? → wanted
(Assignee)

Comment 53

7 years ago
That's a hell of a blocklist entry guys.  Has someone asked them to adjust their versioning for future releases?

Comment 54

7 years ago
Definitely. Christian and I spoke to them late last week about what we expect and why on use of GUIDs and versioning, and they're going to be making some changes. It's also something we should update on MDC or AMO as a policy; they do support individual branches, and Per comment #52, the number of users affected now by the compatibility issue is less than 10%, and continuing to decrease, so the BL may not be necessary (and can probably come out at a later date if we do).

(In reply to comment #53)
> That's a hell of a blocklist entry guys.  Has someone asked them to adjust
> their versioning for future releases?
(Assignee)

Comment 55

7 years ago
Cool, sounds good.
(Reporter)

Comment 56

7 years ago
(In reply to comment #53)
> That's a hell of a blocklist entry guys.

I couldn't agree more. In my opinion, it's an abuse of the blocklist system to push through a block mess like that. Again, it would be literally, not rhetorically, about _half_ of the total blocklist XML.

(In reply to comment #54)
> Per comment #52, the number of users affected now by the compatibility issue
> is less than 10%, and continuing to decrease, so the BL may not be necessary
> (and can probably come out at a later date if we do).

It's nice that they're fixing their problem, but I have to point out that I had filed this request when it was a far larger issue, affecting many more people, and in fact ended up being one of the mystery support highlights in one of the Firefox planning meetings (comment 13). This is a beta block request, which I don't think has any reason to follow the standard block request path and could have been blocked back when it would have helped a large portion of the beta user base instead of waiting until it became near obsolete. If this is the route taken even with betas, there is barely a reason for the blocklist system to exist. It is none of anyone here's concern if Ask.com is "happy" about having their extension with forged metadata being blocked for _beta_ Firefox users. All versions should have been blocked for FF4 the second the bogus 5.* max version was found and then once they got their act together a valid version and up could've been allowed through. (and Ask would've had months to do so) I think this bug was handled backwards, which just meant more confused users and frankly more confused people here.

I triaged the bugs and got up to a dozen duplicates, investigated the extension myself in a VM, found the abuse of the install.rdf max version, found user reports of problems, even found validator issues, and after a couple months nothing was done and it ended up listed as some sort of "mystery" in a Firefox meeting with hundreds of user complaints that needed to be handled. (and probably, as per usual, many many more not reported) Honestly, I'm annoyed and am very discouraged from bothering to investigate and file blocklist requests for even such egregious cases as this if nothing is ever blocked with this amount of evidence given up front. Yeah, great, the issue is being resloved-ish eventually; I filed comment 0 in August with enough that it should have been blocked, again just for Firefox 4 beta users, within a day.
(Reporter)

Comment 57

7 years ago
Also, to restate comment 10: A hard blocklist entry is still required to prevent breakage out to any Firefox 5.*. We could be dealing with any manner of problem in Firefox 5.n or 5.n+1 or whatever in years to come. It shouldn't even matter if the number of users goes down. If it's known bad it should be blocked, and it's known that this extension has scattered version usage without good update paths.

Comment 58

7 years ago
(In reply to comment #56)
> I couldn't agree more. In my opinion, it's an abuse of the blocklist system to
> push through a block mess like that. Again, it would be literally, not
> rhetorically, about _half_ of the total blocklist XML.

Which is why we're weighing on whether or not to put it in. Blocklisting is always a last resort, which is why we try to work with the vendors first, per AMO policy. I don't consider it to be an abuse, but it's definitely a situation we haven't encountered before because of how Ask versions their extensions.

Ask maintains more than one branch of their software, and differentiates it with versioning. I think it's fair to say it's not something we expected, but it's a practice that is not uncommon with software. This is opinion only, of course.

> (In reply to comment #54)
> > Per comment #52, the number of users affected now by the compatibility issue
> > is less than 10%, and continuing to decrease, so the BL may not be necessary
> > (and can probably come out at a later date if we do).
> 
> It's nice that they're fixing their problem, but I have to point out that I had
> filed this request when it was a far larger issue, affecting many more people,
> and in fact ended up being one of the mystery support highlights in one of the
> Firefox planning meetings (comment 13). This is a beta block request, which I
> don't think has any reason to follow the standard block request path and could
> have been blocked back when it would have helped a large portion of the beta
> user base instead of waiting until it became near obsolete. If this is the
> route taken even with betas, there is barely a reason for the blocklist system
> to exist. It is none of anyone here's concern if Ask.com is "happy" about
> having their extension with forged metadata being blocked for _beta_ Firefox
> users. All versions should have been blocked for FF4 the second the bogus 5.*
> max version was found and then once they got their act together a valid version
> and up could've been allowed through. (and Ask would've had months to do so) I
> think this bug was handled backwards, which just meant more confused users and
> frankly more confused people here.

This is where we make a judgement call, and I still don't believe a blocklist was justified. The error reported was that an error dialog popped up in our betas and minefield. Our blocklisting policy is pretty clear around this, but if it needs to be re-visited, we can do that as well. See https://wiki.mozilla.org/Blocklisting#Blocklisting_Policy for more info, but I honestly believed it didn't meet our blocklist criteria. I agree it's annoying and potentially confusing, but I really do not believe the confusion meets the "major user-facing issues" criteria. That's totally subjective, of course, but I stand by it.

> I triaged the bugs and got up to a dozen duplicates, investigated the extension
> myself in a VM, found the abuse of the install.rdf max version, found user
> reports of problems, even found validator issues, and after a couple months
> nothing was done and it ended up listed as some sort of "mystery" in a Firefox
> meeting with hundreds of user complaints that needed to be handled. (and
> probably, as per usual, many many more not reported) Honestly, I'm annoyed and
> am very discouraged from bothering to investigate and file blocklist requests
> for even such egregious cases as this if nothing is ever blocked with this
> amount of evidence given up front. Yeah, great, the issue is being resloved-ish
> eventually; I filed comment 0 in August with enough that it should have been
> blocked, again just for Firefox 4 beta users, within a day.

The very last thing I would want to do is to discourage people from doing the kind of work you have done, and I realize that I did not provide the necessary context. For discouraging you through lack of communication, I am truly sorry, and will do better moving forward.

I reviewed the error, and did what we typically do, which is work with the developer to fix the problem, and see whether we needed to blocklist. The addon did pop up an error with our beta and nightlies, but I do not believe the issue outlined in comment #0 was something that impacted users to the point where a BL was mandated (we usually reserve that for exploits and crashers, and I realize that there was a crasher, but that was a separate issue). 

I'll take full responsibility for making that call, and I wouldn't change it. I could definitely add more context to the bug and what/why I did, and will do that moving forward.

The point of the process, from what I have always understood and worked towards, is to correct issues without having to resort to blocklisting. Their fixing the problem is the end goal, and we don't differentiate between blocklists we provide to beta nd released clients, AFAIK. Blocklisting is always the last step we take, and if we can avoid it, we will. I have spent a considerable amount of time working with Ask and educating them on how we look at things, and what we expect, and they have been working on bringing things in line with those expectations. 

If we were releasing Fx4 tomorrow, I'd change my thought patterns. I did what I thought was correct given the beta/nightly status of Fx4 and the potential impact. Your efforts have directly led to the problem being outlined to and addressed by the developer, and I'd like to think the system worked. I understand your frustration, and do apologize for causing a good chunk of it. I'm happy to work on policy around this if it's needed, and adding more clarity to the process, and will work on identifying a clear owner for the BL process.

Comment 59

7 years ago
It's pretty clear that this extension is causing a major topcrash in beta7. Apart from whether we blocklist it for beta8 or any other version, I think it's clear that it meets the criteria for blocklisting for just beta7, and we should have done this two weeks ago when the cause was clarified.

This is not "an error pops up", this is "the browser will not launch and people with the Ask toolbar will simply stop using the betas".

Comment 60

7 years ago
The bug as reported was not, and the topcrash only became apparent recently (which was a separate issue). That was my main point of the above, and if we don't have consensus around how we handle the double-registration of the dll, I'd really like to get there fast and close this off so it's addressed.
(Reporter)

Comment 61

7 years ago
(In reply to comment #58)
> Ask maintains more than one branch of their software, and differentiates it
> with versioning. I think it's fair to say it's not something we expected, but
> it's a practice that is not uncommon with software.

Firefox maintains more than one branch as well: two, 3.5 & 3.6, one of which was supposed to be EOL by now. It's not really realistic "branching" in the same sense when you get over a dozen. It sounds to me like they have different flavors of the extension which get different version numbers instead of different IDs, or maybe they just have really bad updating, but I don't know enough on this subject.

Regardless, working with them is good but it's my opinion that we should try to work with vendors, not defer to them.

> > (In reply to comment #54)
> > > Per comment #52, the number of users affected now by the compatibility issue
> > > is less than 10%, and continuing to decrease, so the BL may not be necessary
> > > (and can probably come out at a later date if we do).
> >
> > It's nice that they're fixing their problem, but I have to point out that I had
> > filed this request when it was a far larger issue, affecting many more people,
> > and in fact ended up being one of the mystery support highlights in one of the
> > Firefox planning meetings (comment 13). [...] I
> > think this bug was handled backwards, which just meant more confused users and
> > frankly more confused people here.
>
> This is where we make a judgement call, and I still don't believe a blocklist
> was justified. The error reported was that an error dialog popped up in our
> betas and minefield. Our blocklisting policy is pretty clear around this, but
> if it needs to be re-visited, we can do that as well. See
> https://wiki.mozilla.org/Blocklisting#Blocklisting_Policy for more info, but I
> honestly believed it didn't meet our blocklist criteria.

Yes, I guess I can agree that having a bogus 5.* as a max version, thus virtually guaranteeing a breakage at some point, is not listed in the stated blocklist criteria. However, I would think this should be an obvious thing to block for. They constructed an extension which was knowingly lying about what it supported to be lazy, and that resulted in the obvious result of breaking support at some point. It could easily get worse between now and 5.next. This is not something we should tolerate. (and as mentioned above they only lessened the lying to 4.*)

In part, I was being paranoid and stating that this bogus claim of support was a landmine waiting to be tripped... which was tripped way earlier than I was even expecting with bug 612088 wanting to block a large range of versions for a crash caused in this incompatible range. In replies to comment 59 and comment 58, if this blocklist request was put through when first asked the other issue would have never come up as the incompatible versions would've been blocked. (though to play the devil's advocate, ironically, the lack of a block led to bug 616056 and a fix we might've not otherwise gotten, though this was incidental)

> I agree it's annoying and potentially confusing, but I really do not believe
> the confusion meets the "major user-facing issues" criteria.

Extension breakage and a stupid popup affecting beta users does of course not meet any blocking criteria. (I didn't even bother to file this request at first) A stupid popup eventually affecting all users once the beta period is over however does, and one that would stick around until Firefox 5.999 should certainly do so as well. Because this extension is known to be installed without user knowledge and has poor update paths I did not wish this thorn to stay stuck in "forever" and that's what the blocklist is for: to fix addon problems that otherwise could or can not be fixed by existing means.

At the point of comment 0 it is my opinion that this most certainly met the spirit of the criteria, even though the subject was not conceived of within the criteria. It had the distinct potential to meet the the 3rd point in the list, "with fatal bugs (client crashes on startup or something causing an endless loop of unusability)", and it DID eventually meet this exact criteria with bug 612088. I essentially filed this bug to try to prevent that one and others like it.

At this point I do not disagree that the severity of the issue is lessened if Ask is making an attempt to fix the problem, but again, and I cannot stress this enough, such a blatant and stupid forgery of extension metadata that was virtually guaranteed to break should have warranted an immediate block for beta users. Because this was about only beta users at the time, there would have been zero impact to the actual Firefox user-base, so in a cost-benefit analysis this should've been a no-brainier. A quick and simple block would've fixed the problem right away and given Ask months and months to put out a valid version for Firefox 4.0. Instead we're now debating over a messy 19-part block which is a waste of time and effort on everyone's part.

> > [...] Honestly, I'm annoyed and am very discouraged [...]
>
> The very last thing I would want to do is to discourage people from doing the
> kind of work you have done, and I realize that I did not provide the necessary
> context. For discouraging you through lack of communication, I am truly sorry,
> and will do better moving forward.

I of course accept your apologies; we all want the same thing here. I do not mean to be rude, but many blocklist requests go down similar routes, even those that affect stable users in a way that meet the criteria. Bug 449062 for example has been sitting there for years and it's a known startup crash, even under safe mode.

The point I'm trying to make is that I believe this system is too hesitant to pull the trigger and block a known serious problem, even after working with the vendor has failed. To be precise, I consider waiting more than a month for a vendor to fix the problem in totality to be a failure. This entire process should be much faster and it is capable of having much higher expectations not only of the vendor but of itself.

> I reviewed the error, and did what we typically do

This was about the beta; it's atypical.

> The point of the process, from what I have always understood and worked
> towards, is to correct issues without having to resort to blocklisting. Their
> fixing the problem is the end goal, and we don't differentiate between
> blocklists we provide to beta and released clients, AFAIK.

I do not believe there is a policy stated on this anywhere, unfortunately. My point is that we should differentiate and block far more often for beta users and let developers fix after the fact as we have a much lower impact of the block.

> I have spent a considerable amount of time working with Ask and educating
> them on how we look at things, and what we expect, and they have been working
> on bringing things in line with those expectations.

Thank you immensely for that. It will be fantastic if they can get everything fixed and keep it that way.

> Your efforts have directly led to the problem being outlined to and
> addressed by the developer, and I'd like to think the system worked.

Somewhat true, but VERY slowly and in a roundabout and incomplete fashion. (again, see comment 22 - 24: they've reduced the level of lying in the install.rdf from 5.* to 4.*)

> I understand your frustration, and do apologize for causing a good chunk of it.
> I'm happy to work on policy around this if it's needed, and adding more clarity
> to the process

I understand and do agree that the policy here needs updating and clarifying. I think it needs to be far more strict on developers who abuse the extension system. In fact, because of the advent of the low severity / soft block whereby a user can opt-out, I think we should be using this system more often than we do. I don't believe the policy has changed since this ability was introduced.

> and will work on identifying a clear owner for the BL process.

I am in general frustrated with the blocklisting process, and as you said there also doesn't seem to be a clear owner to move things along which slows down many bugs in this component. Sometimes there's even a blocklist request that warrants a WONTFIX but that even takes a long time to get.

Yes, I know you personally do wonderful work behind the scenes quite often, and thanks again for that, but these bugs aren't always updated and it is very frustrating to identify something that is a problem but wait months on end to not have it resolved when a quick block would fix the problem and force the developer to fix their problem much faster. Instead, we wait... and wait...

Comment 62

7 years ago
(In reply to comment #61)
> It sounds to me like they have different
> flavors of the extension which get different version numbers instead of
> different IDs, or maybe they just have really bad updating, but I don't know
> enough on this subject.

Yep. They are aware of the issue though and I believe will have different ids in the future for different flavors.

> > Regardless, working with them is good but it's my opinion that we should try to
> > work with vendors, not defer to them.

We are working with them in the future to make us not get into a similar situation. I don't think this is deferring to them, rather it's working with the situation we are currently in.

> > > It's nice that they're fixing their problem, but I have to point out that I had
> > > filed this request when it was a far larger issue, affecting many more people,
> > > and in fact ended up being one of the mystery support highlights in one of the
> > > Firefox planning meetings (comment 13). [...] I
> > > think this bug was handled backwards, which just meant more confused users and
> > > frankly more confused people here.

Yes, there is not really an owner for the BL stuff currently, which is unfortunate. This definitely causes turn-around to be less than stellar.

Additionally, blocklisting takes a lot of time due to communication with the vendor, discussing other avenues, etc. Also, from the mozilla side, we have to organize multiple groups of people (one for the product blocklist, one for the database AMO blocklist, QA for testing, IT to run the queries against the production DB, etc) which takes time as well.

At least for the owning part, we'll hopefully have someone soon or enough spare cycles between a couple of us to get this covered. I'd take it myself but I know I'd have to drop it when other high-priority stuff conflicted.

> The point I'm trying to make is that I believe this system is too hesitant to
> pull the trigger and block a known serious problem, even after working with the
> vendor has failed. To be precise, I consider waiting more than a month for a
> vendor to fix the problem in totality to be a failure. This entire process
> should be much faster and it is capable of having much higher expectations not
> only of the vendor but of itself.

Understandable. Though in this case it wasn't us consciously deciding to not blocklist and instead wait for Ask to fix it. We informed Ask of the problem and then didn't drive the blocklist to resolution quick enough. Now the facts have changed a bit, primarily based on Ask trying to rectify the issue from their side (which is a good thing).

> > Somewhat true, but VERY slowly and in a roundabout and incomplete fashion.
> (again, see comment 22 - 24: they've reduced the level of lying in the
> install.rdf from 5.* to 4.*)

I believe they are aware of the issue FYI.

> Yes, I know you personally do wonderful work behind the scenes quite often, and
> thanks again for that, but these bugs aren't always updated and it is very
> frustrating to identify something that is a problem but wait months on end to
> not have it resolved when a quick block would fix the problem and force the
> developer to fix their problem much faster. Instead, we wait... and wait...

Agreed. We'll find an owner and get better.
(Reporter)

Comment 63

7 years ago
(In reply to comment #62)
It's good to hear that they are aware of the still pending issues (flavor versioning and still bogus maxversion) and are working on it. I was and am still to some degree skeptical that they'll fix everything, but if they do it will be a very good thing.

> (In reply to comment #61)
> > Regardless, working with them is good but it's my opinion that we should try to
> > work with vendors, not defer to them.
> 
> We are working with them in the future to make us not get into a similar
> situation. I don't think this is deferring to them, rather it's working with
> the situation we are currently in.

I understand and do not entirely disagree with your point. If we can get them to fix things and not repeat mistakes in the future I think we can all agree that would be good. What I mean by deferring in this instance is that the path chosen was to wait for them to do something then eventually we may block, whilst I would rather a block be put in place first and then work with them to get together a version which is compatible and not blocked. I guess one could make the argument that this method might be impaired by the ego of the developer in question in some instances, however this shouldn't be a problem when both parties agree that there's a known complete incompatibility and with a non-release browser version no less.

I would still much prefer a _single_ blocklist entry for this issue, which I would also file under the category of "deferring". I'm repeating myself, but the 19 suggested blocklist entries would constitute a doubling of our blocklist.xml. On principle alone this feels nuts. Mozilla should simply say no to that, point blank, yet work with Ask to help get a single range that has the desired effect.

> Yes, there is not really an owner for the BL stuff currently, which is
> unfortunate. This definitely causes turn-around to be less than stellar.

Nicely understated. ;)

> Additionally, blocklisting takes a lot of time due to communication with the
> vendor, discussing other avenues, etc. Also, from the mozilla side, we have to
> organize multiple groups of people (one for the product blocklist, one for the
> database AMO blocklist, QA for testing, IT to run the queries against the
> production DB, etc) which takes time as well.

Not sure on the topic, but I might as well ask: how involved are people from Tech Evangelism here? It seems like the two groups of people needed overlap significantly. I know some people are involved with both areas, but I'm wondering if there's more that could be done to share resources and people as these are sometimes basically the same issues in different realms.

> then didn't drive the blocklist to resolution quick enough

That's my point: this side should drive to the resolution, and hard. BL bugs tend to have a very slow workflow, at least from the perspective of here. In my opinion, no BL bug should ever be open longer than a month. That means any of the following:
* putting through a block with or without the vendor
* working with the vendor to avoid a block (morph to a FIXED TE bug?)
* WONTFIXing the bug

> Now the facts have changed a bit, primarily based on Ask trying to rectify
> the issue from their side (which is a good thing).

Agreed.
Comment on attachment 495591 [details] [diff] [review]
Blocklist ask versions that claim they are compatible with 4.0 betas but really aren't

Getting this out of my review queue though I question the necessity of ballooning tis when we aren't sure what problems the toolbar causes right now.

>+    <emItem id="toolbar@ask.com">
>+        <versionRange minVersion=" " maxVersion="3.5.*">

minVersion of " " is kind of weird (technically " " < "0") I'd just not include a minVersion.

Also note that very soon now we'll be automatically updating the blocklist.xml in the tree with that from the webservice so checking stuff in like this will not be necessary.
Attachment #495591 - Flags: review?(dtownsend) → review+
(Reporter)

Comment 65

7 years ago
(In reply to comment #64)
How can 19 new blocklist entries for one addon be ok? Why make such a mess of things here to nitpick over versions, especially when we're talking about an addon they may not have installed themselves. ONE RANGE is the only thing that is sane. I can't comprehend doubling the blocklist.xml for this one addon being acceptable.

Also note that I think any versions that are still using a max version of 4.* should be blocked too, as that too is invalid and will eventually break. In other words, all versions until they finally fix things correctly. If not enough people are having problems right now, then a block is not needed asap, but eventually we're going to want to clean up the old ones before Firefox 4.0 is released with one sane block of old versions.

> minVersion of " " is kind of weird (technically " " < "0") I'd just not include
> a minVersion.

Not sure why, but this is how the XML is output.
https://addons.mozilla.org/blocklist/1/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/3.6.0/
(Reporter)

Comment 66

7 years ago
By the way, why XML to start in the first place? SQL needs to come first.

(In comment #31)
> Note that unless the database has been updated with the same block then the
> add-on will get re-enabled around a day after.
(Reporter)

Comment 67

7 years ago
People are now starting to hit this problem in Firefox 5 (bug 669590).
(Reporter)

Comment 68

6 years ago
This block really should have been pushed as some sloppy work from Ask.com caused a fair bit of grief for too many people, which could have been avoided. Nonetheless, with the new rapid release cycle the only currently supported Firefox versions are now 3.6.x & 6.0.x. As this issue only affects Firefox 4.0.x & 5.0.x, both no longer supported, this block is no longer relevant. Closing as WONTFIX unless someone else says otherwise. If someone has another case to block in a currently supported version please post a new bug for it.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 69

6 years ago
With compatible by default addons in Firefox 10+, I've already seen one report of this problem. Reopening.

Is there a new known incompatibility blocklist that this can be one of the first addons in?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Blocklist Ask.com Toolbar under Firefox 4+ (incompatible and claims to support Firefox 5.*) → Blocklist Ask.com Toolbar under Firefox 4+ (incompatible and claims to support Firefox 5.*; now also a problem under Firefox 10+)
What problem are you referring to, Dave?
(Reporter)

Comment 71

6 years ago
The first one I reported this bug for; an old version of the Ask.com Toolbar extension claims Firefox 4-5 support when it doesn't, causing an error popup on Firefox start. (see comment 0 & bug 578099 where I've been duping reports of it) A lot of people were complaining about this here, on SUMO, via Input, & etc. No clue how many have updated to a newer version of this toolbar and won't get it now/again due to compatible-by-default, though. I would hope Ask.com has updated most people by now, but it's apparently already hitting at least some people using Firefox 10.

Updated

6 years ago
Blocks: 719561
(In reply to Dave Garrett from comment #69)
> Is there a new known incompatibility blocklist that this can be one of the
> first addons in?

Yes, we have one. Do you have a copy of the XPI that I can look at so I can add it to the list?
(Reporter)

Comment 73

6 years ago
(In reply to Jorge Villalobos [:jorgev] from comment #72)
> (In reply to Dave Garrett from comment #69)
> > Is there a new known incompatibility blocklist that this can be one of the
> > first addons in?
> 
> Yes, we have one. Do you have a copy of the XPI that I can look at so I can
> add it to the list?

No, I don't have a copy of the old XPI. Newer versions should be fine, so the info in comment 0 should do hopefully. As mentioned in comments above, Ask.com used a messy versioning system, but now that the fix has been in newer versions for a while there shouldn't be a problem in just listing all the older versions up to 3.9.1.0. If you'd rather attempt to block as few old versions as possible, see comment 46.

The current version is now 3.14.1.20007, by the way, and works fine under Firefox 10.
I just added all versions up to 3.9.1.0 to the override list, starting with Firefox 10.0a1. I believe this should cover all required cases.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Comment 75

6 years ago
Jorge - 

Can you change this to v 3.6 only.  That's  the only version that's at issue.  This incorrectly identifies other toolbar versions which are not causing errors.
(Reporter)

Comment 76

6 years ago
(In reply to eric.engleman from comment #75)
> Can you change this to v 3.6 only.  That's  the only version that's at
> issue.  This incorrectly identifies other toolbar versions which are not
> causing errors.

The initial reports for this were for toolbar versions 3.8.* and that was the version I inspected and filed this bug based on. It's maxversion is set to 5.* which didn't exist at the time and it wasn't compatible with 4.* either. There's a very small sampling of user reports in comment 2 with this error message appearing on version 3.4, 3.6, & 3.8 under Firefox 4.0 beta. Any compatibility problem affecting Firefox 4+ will now affect Firefox 10+.

Again, current versions of the toolbar are fine and Ask.com has had a year to update their users. This new block is now not on the normal blocklisting system (is there a better component to move the bug to?) but rather an addition to the list of addons that just aren't compatible with Firefox 10 and shouldn't be automatically considered compatible under the new default to compatible system. This entry should do nothing but tell Firefox 10 to take the addon's stated compatibility declaration strictly, thus marking it as not compatible with Firefox 10 in the same way that it already was marked as not compatible with Firefox 9.

Renaming bug title to better reflect the action that was done as this was not blocked under Firefox 4-9 as implied if you don't read the rest of the bug.
Summary: Blocklist Ask.com Toolbar under Firefox 4+ (incompatible and claims to support Firefox 5.*; now also a problem under Firefox 10+) → Block old Ask.com Toolbar versions
(Reporter)

Comment 77

6 years ago
Mistype; comment 2 has reports of this script error under 3.4 & 3.6 as well as other errors. 3.8 was reported elsewhere and tested.
There's an Extension Compatibility component, but for historical purposes I think this should stay here.

Updated

6 years ago
No longer blocks: 719561
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.