Closed
Bug 802189
Opened 13 years ago
Closed 7 years ago
Plugin softblock makes Plugin Check open on almost every new session
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: jorgev, Unassigned)
Details
This is being repeatedly reported in the Add-ons Blog, in reply to our massive plugin blocks from bug 797378. See this comment, for example:
https://blog.mozilla.org/addons/2012/10/05/prompting-our-users-to-update-their-plugins/comment-page-1/#comment-160167
Users are reporting that Firefox opens the plugin check page almost every time Firefox starts. One of them claims to be using 16.0.1.
This would also help explain the surge in traffic to the plugin check page in bug 798756.
Do we have any feature or preference that causes the plugin check page to be opened automatically?
Comment 1•13 years ago
|
||
Yes, outdated plugin blocks (severity=0) which the blocks you've added seem to use make Firefox open the plugin check page on next startup. It's only meant to do it once but to my knowledge this is the first time we've used this type of block in the wild
Reporter | ||
Comment 2•13 years ago
|
||
Ugh, I wasn't aware of this. Does it happen for click-to-play blocks as well, since they have the same severity level?
Comment 3•13 years ago
|
||
Specifically, bug 793273 turned off click-to-play support in Firefox 16, so Firefox 16 and lower interpret these blocks as regular outdated block entries, Firefox 17 and newer will interpret them as click-to-play entries which will behave differently.
Comment 4•13 years ago
|
||
Though it should still be only displaying the plugin check page once! Will look into why it might not be today.
Comment 5•13 years ago
|
||
(In reply to Dave Townsend (:Mossop) from comment #1)
> but to my knowledge this is the first time we've used
> this type of block in the wild
Yep, first time since it landed 3 years ago.
When an outdated plugin is detected (either via a blocklist update, or a newly installed plugin that matches a blocklist entry), plugins.update.notifyUser is set to true. Then on next startup, if that pref is true, the Plugin Check page is opened - and the pref is reset.
I can't reproduce the issue myself, and the code looks fine. So I'm kinda stumped.
Comment 6•13 years ago
|
||
Some of the reports suggest something else could possibly be interfering:
> very time I started Firefox or reopened a closed tab, there were other
> conditions, the plug-in checker nag tab would appear.
The only times we open the Plugin Check page is on startup, or when you click the button in the notification bar that shows.
> The string “plugins.update.notifyUser” is setting itself to true apparently at
> random
The only cases when that pref is set to true are:
* Plugins rescanned, new plugin detected that matches an outdated blocklist entry
* Blocklist updated, new entry matches existing plugin
Reporter | ||
Comment 7•13 years ago
|
||
We're still getting lots of complaints about it in the Add-ons Blog. Anything we can recommend to these people? Manually change the preference, maybe?
Comment 8•13 years ago
|
||
As I mentioned in the other thread, I was able to get rid of this page by changing all severity="0" entries in the blocklist.xml to severity="1" and then setting the file to read-only.
If there are any severity="0" entries in the .xml file, my FF opens the plugin page - on every launch.
In about:config, plugins.update.notifyUser is false; setting it to true has no effect, except it being reset to false on the next launch of FF, along with the plugin check page appearing. Same goes for setting it to true and then back to false again - the page still appears on the next launch.
It seems to me more like the actual parsing of the blocklist causes FF to open the plugin check page when it finds a severity="0" entry, instead of the notifyUser causing this. Eg. after parsing the file, FF directly calls the routine that shows that page, because I've never actually seen the plugins.update.notifyUser property in a "true" state.
Comment 9•13 years ago
|
||
(In reply to Jorge Villalobos [:jorgev] from comment #7)
> We're still getting lots of complaints about it in the Add-ons Blog.
> Anything we can recommend to these people? Manually change the preference,
> maybe?
Finding someone that can reproduce it is important. Can we ask people to check the value of plugins.update.notifyUser immediately after they've seen the plugincheck page open. If it is true then there is some bug about resetting that pref.
I'm vaguely remembering a bug that caused us to redetected plugins constantly. If people are seeing this and can send us two copies of their pluginreg.dat file. One after the one time they see the page open, and another after a second time. That might give us an idea of what Firefox thinks is going on with the plugins.
Comment 10•13 years ago
|
||
(In reply to Dave Townsend (:Mossop) from comment #9)
> Finding someone that can reproduce it is important. Can we ask people to
> check the value of plugins.update.notifyUser immediately after they've seen
> the plugincheck page open. If it is true then there is some bug about
> resetting that pref.
In my case that value is always false.
> I'm vaguely remembering a bug that caused us to redetected plugins
> constantly. If people are seeing this and can send us two copies of their
> pluginreg.dat file. One after the one time they see the page open, and
> another after a second time. That might give us an idea of what Firefox
> thinks is going on with the plugins.
In my case, there are no changes made to pluginreg.dat between two (or even several) launches of FF and the plugin check page - I just checked this with a hash tool. So I suppose posting my file would not be helpful?
Comment 11•13 years ago
|
||
(In reply to Dominik Friedrichs from comment #10)
> (In reply to Dave Townsend (:Mossop) from comment #9)
> > I'm vaguely remembering a bug that caused us to redetected plugins
> > constantly. If people are seeing this and can send us two copies of their
> > pluginreg.dat file. One after the one time they see the page open, and
> > another after a second time. That might give us an idea of what Firefox
> > thinks is going on with the plugins.
>
> In my case, there are no changes made to pluginreg.dat between two (or even
> several) launches of FF and the plugin check page - I just checked this with
> a hash tool. So I suppose posting my file would not be helpful?
Does the modification time of the file change?
Comment 12•13 years ago
|
||
(In reply to Dave Townsend (:Mossop) from comment #11)
> Does the modification time of the file change?
Yes. Write access seems to happen upon launch of FF, none on quit.
Comment 13•13 years ago
|
||
(In reply to Dominik Friedrichs from comment #12)
> (In reply to Dave Townsend (:Mossop) from comment #11)
> > Does the modification time of the file change?
>
> Yes. Write access seems to happen upon launch of FF, none on quit.
How often are you seeing the plugin check page appear, every startup? Once a day? Randomly?
Comment 14•13 years ago
|
||
(In reply to Dave Townsend (:Mossop) from comment #13)
> How often are you seeing the plugin check page appear, every startup? Once a
> day? Randomly?
On every launch (unless I open additional windows).
Comment 15•7 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•