Add-on can disable update check (making Firefox report being "up to date" although update is available)




Application Update
3 years ago
3 years ago


(Reporter: Daniel Kabs, reporting bugs since 2002, Unassigned)


40 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)



(3 attachments)

Created attachment 8654759 [details]
Screen Shot 2015-08-30 at 13.13.39.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150812163655

Steps to reproduce:

The user can manually trigger Firefox to check for available updates. On a Mac this is done by clicking Firefox -> About Firefox. Then a window opens that shows the version number. If the installed version of Firefox is current, a text is displayed "Firefox is up to date". If a newer version of Firefox is available, the user is offered to start an update.

I'm running 40.0.2. Today I checked 
and learned that a new version of Firefox is available since 8/27/2015. 

To manually start the update, I opened "About Firefox"

Actual results:

- A window opens stating that "Firefox is up to date".
- Firefox does not detect update available at, e.g., 40.0.3
- see screenshot

Expected results:

- A window opens stating that a new version is available
- The user is guided through the update process.


3 years ago
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64

Comment 1

3 years ago
Did the user try to update his version from a new profile?

It's a probably a profile issue.
Component: Untriaged → Application Update
Product: Firefox → Toolkit
Loic, that is correct. Thanks a lot! When starting Firefox using a new and clean profile, the "about" window offers the update. This way Firefox was updated to 40.0.3

How can I find out what's wrong with the profile that's not showing the update?

Comment 3

3 years ago
The user can try to delete the "update" files from his local settings.

On Windows, these files are stored in the folder:
Then each update is stored in a folder with alphanumeric string. So by deleting these folders, it should reset the update process/state and remove the update issues.
Hi Loic,
this issue was reported for Mac OS X. On a Mac, the profile folders are in 
/Users/<username>/Library/Application Support/Firefox/Profiles/
However, I found no "updates" folder in any of the profile folders. Therefore I assume the "updates" folder you refer to is outside of the profile folders. 

I found an update folder here:

I will report back after the next Firefox update is available and I can try your suggestion.

Comment 5

3 years ago
Yes, this folder with the "update" files (as .xml) are outside the profile. I don't know exactly the path on OSX but it's probably the one you linked (equivalent to local settings for applications on Windows).
@Loic: now that Firefox 41 is released, I followed your suggestion and deleted all files in the "updates" folder and - after that did not help - even the "updates" folder itself and "active-update.xml" + "updates.xml" (which are on the same directory level as "updates" folder).

In vain. Still "Firefox > About Firefox" mistakenly reports that 40.0.3 is up to date.

Therefore the issue is clearly associated with my specific profile.

Any other ideas why this is?
Thanks. Will try the "reset" as a last resort.

Just figured that with my current (defective?) profile I can not access the update server manually. If I switch to a new profile, I can access this page (and the update works, too). So these two issues might be connected.

What could prevent Firefox to access "" when I enter it in the URL bar? It seems that not even a HTTP request is generated for this URL.

Comment 9

3 years ago
Maybe bad prefs in the profile. Did you check the updates are allowed in the advanced settings?
Anyway, if the issue is fixed with a fresh profile, the fast way to fix it is resetting the profile to keep only the private data.
Loic, of course you are right. I should not investigate further into this issue and rather "reset" my profile. 

I'm puzzled that I fail to identify the root cause of the problem using well known methods. For example, I disabled all add-ons and plugins, still the issue exists, i.e. if I click on any of the links in comment #8, nothing happens (really nothing, not even a http request is issued, the Bugzilla page remains displayed). However, running Firefox in -safe-mode, the links work as expected. I wonder what -safe-mode does over manually disabling addons and plugins.
I found the culprit that prevented Firefox from accessing its update server

It's an add-on (aka extension) which calls itself "web shield" with the identification {458fb825-2370-4973-bf66-9d7142141847}

Interestingly it hides itself from appearing on the add-on list by applying a special CSS rule. The CSS rule sets the "display" property of the add-on's list entry to "none". See screenshot. Therefore, I was unable to disable the add-on and I did not see Firefox' warning message about this unverified add-on.

I find this intriguing but also very alarming that

a) An add-on can  Firefox' update mechanism, and
b) An add-on can hide itself from the list of add-ons (rendering Firefox add-on related controls and warning means inoperable)
Created attachment 8667136 [details]
Screen Shot 2015-09-29 at 09.53.58.png

Extension List (Tools > Add-ons) opened in Inspector while "web shield" add-on is installed.


3 years ago
Summary: Firefox update check fails and reports being "up to date" although update is available → Add-on can disable update check (making Firefox report being "up to date" although update is available)
FYI, I filed a separate bug #1209452 about the issue of CSS injection in order to vanish from Add-ons Manager's list of extensions.
A quick google search ["web shield" firefox add-on] shows that web shield is classified as adware or adware-related/PUP. Top result:

jorgev: I assume this would be easily noticed and rejected if the extension was ever uploaded to AMO for signing, but this seems serious bad behavior so NI'ing you anyway in case there's anything else to be done (add to blocklist maybe?).
Flags: needinfo?(jorge)
Luis, I don't know how this extension got installed in my Firefox profile. *blush* I guess I'll never find out.

Of course I would have detected and removed this extension earlier if it had not hid itself from Add-ons Manager (bug #1209452).
I don't know if this is relevant but I analyzed how the add-on intercepts HTTP requests. It uses the API documented here:


The extension adds an HTTP observer function httpRequestObserver

>  Services.obs.addObserver(httpRequestObserver, "http-on-modify-request", false);

The httpRequestObserver retrieves the requested URL and matches it against the following regex:

> /(\/\/aus.\.mozilla\.org\/|\/\/blocklist\.addons\.mozilla\.org\/|\/\/addons\.cdn\.mozilla\.net\/user-media\/addons\/.*hotfix)/i

If it matches, it calls cancel() on the respective nsIHttpChannel

>  httpChannel.cancel(Components.results.NS_BINDING_ABORTED);
(In reply to Daniel Kabs, reporting bugs since 2002 from comment #15)
> Luis, I don't know how this extension got installed in my Firefox profile.
> *blush* I guess I'll never find out.

That's the thing with these extensions, they're sneaky. :) It was probably bundled with another application. But when there's one there are usually more, so I would recommend that you scan your system. It seems like it's a fairly known package so I suppose any adware/malware removal process of your choice will recognize it and deal with it successfully.

But before you do, perhaps you should temporarily save the extension xpi package file in a folder somewhere (I'm guessing you already did since you're looking at its code), in case it is needed as a reference point for this bug.
Created attachment 8667315 [details]
example extension xpi package file

Comment 19

3 years ago
Could you make a run of Adwcleaner on your machine, theis "Web Shield" should be logged by this tool:

Comment 20

3 years ago
NVM, you're on OSX.
Filed bug 1209588 to block the extension. Thank you for bringing this up.
Flags: needinfo?(jorge)
You need to log in before you can comment on or make changes to this bug.