Closed
Bug 1200144
Opened 9 years ago
Closed 5 years ago
Add-on can disable update check (making Firefox report being "up to date" although update is available)
Categories
(Toolkit :: Application Update, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bugzilla, Unassigned)
Details
Attachments
(3 files)
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 https://www.mozilla.org/en-US/firefox/40.0.3/releasenotes/ 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.
Reporter | ||
Updated•9 years ago
|
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Did the user try to update his version from a new profile? https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles It's a probably a profile issue.
Component: Untriaged → Application Update
Product: Firefox → Toolkit
Reporter | ||
Comment 2•9 years ago
|
||
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?
The user can try to delete the "update" files from his local settings. On Windows, these files are stored in the folder: C:\Users\<username>\AppData\Local\Mozilla\updates\ 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.
Reporter | ||
Comment 4•9 years ago
|
||
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: /Users/<username>/Library/Caches/Mozilla/updates/Applications/Firefox/updates I will report back after the next Firefox update is available and I can try your suggestion.
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).
Reporter | ||
Comment 6•9 years ago
|
||
@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?
There is the reset feature: https://support.mozilla.org/en-US/kb/reset-firefox-to-fix-most-problems
Reporter | ||
Comment 8•9 years ago
|
||
Thanks. Will try the "reset" as a last resort. Just figured that with my current (defective?) profile I can not access the update server https://aus4.mozilla.org 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 "https://aus4.mozilla.org/" when I enter it in the URL bar? It seems that not even a HTTP request is generated for this URL.
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.
Reporter | ||
Comment 10•9 years ago
|
||
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.
Reporter | ||
Comment 11•9 years ago
|
||
I found the culprit that prevented Firefox from accessing its update server aus4.mozilla.org. 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)
Reporter | ||
Comment 12•9 years ago
|
||
Extension List (Tools > Add-ons) opened in Inspector while "web shield" add-on is installed.
Reporter | ||
Updated•9 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)
Reporter | ||
Comment 13•9 years ago
|
||
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.
Comment 14•9 years ago
|
||
A quick google search ["web shield" firefox add-on] shows that web shield is classified as adware or adware-related/PUP. Top result: https://www.pcrisk.com/removal-guides/8909-web-shield-adware 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)
Reporter | ||
Comment 15•9 years ago
|
||
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).
Reporter | ||
Comment 16•9 years ago
|
||
I don't know if this is relevant but I analyzed how the add-on intercepts HTTP requests. It uses the API documented here: > https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensions/XUL_School/Intercepting_Page_Loads#HTTP_Observers 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);
Comment 17•9 years ago
|
||
(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.
Reporter | ||
Comment 18•9 years ago
|
||
Comment 19•9 years ago
|
||
Could you make a run of Adwcleaner on your machine, theis "Web Shield" should be logged by this tool: https://toolslib.net/downloads/viewdownload/1-adwcleaner/
Comment 20•9 years ago
|
||
NVM, you're on OSX.
Comment 21•9 years ago
|
||
Filed bug 1209588 to block the extension. Thank you for bringing this up.
Flags: needinfo?(jorge)
Comment 22•5 years ago
|
||
We no longer support these types of add-ons so resolving wontfix
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•