[Ext] PrefBar 6.2.1 awaiting review
-
- Posts: 76
- Joined: July 2nd, 2013, 4:29 am
[Ext] PrefBar 6.2.1 awaiting review
This is primarily a bugfix release to fix some problems with latest browser versions.
This is also the first time, I open a thread on the MozillaZine forums for discussions about the new release, or PrefBar at all. I hope this helps me to get better contact with my users and maybe someone has good ideas or feature requests for the next release
Maybe it's even a good idea to drop the PrefBar mailinglist and move all discussions about PrefBar over to the MozillaZine forum platform.
PrefBar Homepage
PrefBar at AMO
This is also the first time, I open a thread on the MozillaZine forums for discussions about the new release, or PrefBar at all. I hope this helps me to get better contact with my users and maybe someone has good ideas or feature requests for the next release
Maybe it's even a good idea to drop the PrefBar mailinglist and move all discussions about PrefBar over to the MozillaZine forum platform.
PrefBar Homepage
PrefBar at AMO
- ElTxolo
- Posts: 2811
- Joined: July 30th, 2007, 9:35 am
- Location: Localhost
Re: [Ext] PrefBar 6.2.1 awaiting review
M-Reimer wrote:This is primarily a bugfix release to fix some problems with latest browser versions ....
Thank you for this great extension (i've been using it for years) and the last update.
BTW, no problem at all with latest versión.
Cheers!
How to Ask Questions The Smart Way - How to Report Bugs Effectively
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20240318 SeaMonkey/2.53.18.2
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20240416 SeaMonkey/2.53.19
~
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20240318 SeaMonkey/2.53.18.2
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20240416 SeaMonkey/2.53.19
~
-
- Posts: 4
- Joined: July 25th, 2013, 5:18 pm
Re: [Ext] PrefBar 6.2.1 awaiting review
With FF23 the Add-on Manager now provides three possible settings instead of just Enable/Disable:
Never Activate
Always Activate
Always Ask
This breaks PrefBar. Enabling a plugin (e.g. Java) by simply checking the option in the Prefbar Toolbar won't work anymore. The plugin doesn't get enabled.
Never Activate
Always Activate
Always Ask
This breaks PrefBar. Enabling a plugin (e.g. Java) by simply checking the option in the Prefbar Toolbar won't work anymore. The plugin doesn't get enabled.
-
- Posts: 76
- Joined: July 2nd, 2013, 4:29 am
Re: [Ext] PrefBar 6.2.1 awaiting review
Thank you for this information.
So we need a new way to handle plugins properly.
As I want to keep the "Always Ask" option, I think a good way could be to remember the current setting and set to "Never Activate" when unchecked and then restore the last setting when checked.
So PrefBar will always toggle between "last setting" and "Never Activate".
Or does someone have a better idea?
I'll try to create a fix as soon as possible and publish a link to a "trunk" version. Seems like we will have 6.2.2 shortly after 6.2.1
So we need a new way to handle plugins properly.
As I want to keep the "Always Ask" option, I think a good way could be to remember the current setting and set to "Never Activate" when unchecked and then restore the last setting when checked.
So PrefBar will always toggle between "last setting" and "Never Activate".
Or does someone have a better idea?
I'll try to create a fix as soon as possible and publish a link to a "trunk" version. Seems like we will have 6.2.2 shortly after 6.2.1
-
- Posts: 4
- Joined: July 25th, 2013, 5:18 pm
Re: [Ext] PrefBar 6.2.1 awaiting review
May be I'm missing something. Assuming the following scenario:
For an existing FF profile, the Java plugin is installed. It's state is 'Never Activate'.
Now the Prefbar extension gets installed for this profile.
Then, when trying to enable Java via Prefbar, what would be the 'last setting'?
How about to map the Prefbar checkbox for Java to 'Never Activate'/'Always Ask'?
Java is just an example for plugins in general.
As you said, 'Always Ask' sounds more reasonable than 'Always Activate'.
For an existing FF profile, the Java plugin is installed. It's state is 'Never Activate'.
Now the Prefbar extension gets installed for this profile.
Then, when trying to enable Java via Prefbar, what would be the 'last setting'?
How about to map the Prefbar checkbox for Java to 'Never Activate'/'Always Ask'?
Java is just an example for plugins in general.
As you said, 'Always Ask' sounds more reasonable than 'Always Activate'.
-
- Posts: 76
- Joined: July 2nd, 2013, 4:29 am
Re: [Ext] PrefBar 6.2.1 awaiting review
You are right...
I somehow even think that this new "Click to play" feature makes the PrefBar "Toggle Plugin" feature obsolute. At least for security reasons there no longer is a need to really disable a plugin. At least if Mozilla had security in mind and it is really impossible for websites to "auto-play" a plugin.
The easiest way to fix the Plugin toggles would be to really toggle between "Never Activate" and "Always Activate". This is the way it always worked.
But I think there may also be situations where someone wants to toggle between "Always Activate" and "Always Ask" or between "Always Ask" and "Never Activate".
So currently, I'm unsure how a good fix could look like. Maybe a preference, which can be adjusted via "about:config", to toggle between the three possible modes, with toggle between "Never Activate" and "Always Activate" as default?
I somehow even think that this new "Click to play" feature makes the PrefBar "Toggle Plugin" feature obsolute. At least for security reasons there no longer is a need to really disable a plugin. At least if Mozilla had security in mind and it is really impossible for websites to "auto-play" a plugin.
The easiest way to fix the Plugin toggles would be to really toggle between "Never Activate" and "Always Activate". This is the way it always worked.
But I think there may also be situations where someone wants to toggle between "Always Activate" and "Always Ask" or between "Always Ask" and "Never Activate".
So currently, I'm unsure how a good fix could look like. Maybe a preference, which can be adjusted via "about:config", to toggle between the three possible modes, with toggle between "Never Activate" and "Always Activate" as default?
-
- Posts: 76
- Joined: July 2nd, 2013, 4:29 am
Re: [Ext] PrefBar 6.2.1 awaiting review
Please have a look at:
http://downloads.tuxfamily.org/prefbar/ ... -trunk.xpi
This one should work just well with Firefox 23. Also have a look at the help system where the new "hidden preference" is documented.
Would be great if some Firefox 22 users could also try if this version still works without problems.
http://downloads.tuxfamily.org/prefbar/ ... -trunk.xpi
This one should work just well with Firefox 23. Also have a look at the help system where the new "hidden preference" is documented.
Would be great if some Firefox 22 users could also try if this version still works without problems.
-
- Posts: 4
- Joined: July 25th, 2013, 5:18 pm
Re: [Ext] PrefBar 6.2.1 awaiting review
Excellent, thanks a lot. I've updated to FF23 by now, and installed the Prefbar trunk version. Now toggling plugins using Prefbar works again. I've also modified the hidden pref to 1, which is what I want.
Wrt documentation, I'd hope the hidden pref function will be mentioned in the 'What's New' section for the next version.
In general, I'm not convinced very many people will notice this new pref anyway, so including it into the GUI may be a good idea for a future version of Prefbar.
Wrt documentation, I'd hope the hidden pref function will be mentioned in the 'What's New' section for the next version.
In general, I'm not convinced very many people will notice this new pref anyway, so including it into the GUI may be a good idea for a future version of Prefbar.
-
- Posts: 76
- Joined: July 2nd, 2013, 4:29 am
Re: [Ext] PrefBar 6.2.1 awaiting review
That's nice. For me it seems like Firefox 23 still has the old style interface. At least I'm unable to set "Always Ask" in the Addons manager. A nightly version has to be used to test the new feature. So there seems to be some more time until this fix has to be published.
I think plugin toggles get more and more uninteresting with the new "Click to play per plugin" feature in Firefox. So I'm unsure if we really need a GUI for this "hidden pref". I would prefer to keep the PrefBar configuration menu simple and clean.
I think plugin toggles get more and more uninteresting with the new "Click to play per plugin" feature in Firefox. So I'm unsure if we really need a GUI for this "hidden pref". I would prefer to keep the PrefBar configuration menu simple and clean.
-
- Posts: 35
- Joined: August 20th, 2004, 5:15 pm
- Location: California
- Contact:
Re: [Ext] PrefBar 6.2.1 awaiting review
While I have submitted a number of buttons that now appear on your More Buttons page, I have others that I created that remain undistributed. With buttons going to a JSON-based format, will those buttons still work? Or will I have to regenerate them?
-
- Posts: 4
- Joined: July 25th, 2013, 5:18 pm
Re: [Ext] PrefBar 6.2.1 awaiting review
M-Reimer wrote:That's nice. For me it seems like Firefox 23 still has the old style interface. At least I'm unable to set "Always Ask" in the Addons manager. A nightly version has to be used to test the new feature. So there seems to be some more time until this fix has to be published.
You probably need to toggle this pref to enable click-to-play:
plugins.click_to_play;true
M-Reimer wrote:I think plugin toggles get more and more uninteresting with the new "Click to play per plugin" feature in Firefox. So I'm unsure if we really need a GUI for this "hidden pref". I would prefer to keep the PrefBar configuration menu simple and clean.
That's fair enough. I still like to toggle a plugin the easy way using Prefbar. Keep up the good work.
-
- Posts: 89
- Joined: October 22nd, 2008, 4:22 pm
Re: [Ext] PrefBar 6.2.1 awaiting review
THANK YOU for fixing the plug-in problem with Firefox 23 (in my case it was with Flash, since I've disabled Java).
-
- Posts: 76
- Joined: July 2nd, 2013, 4:29 am
Re: [Ext] PrefBar 6.2.1 awaiting review
DERoss wrote:While I have submitted a number of buttons that now appear on your More Buttons page, I have others that I created that remain undistributed. With buttons going to a JSON-based format, will those buttons still work? Or will I have to regenerate them?
There is no plan to drop the RDF format support in the near future, but it will be dropped in one of the next major releases. It doesn't make sense to keep backwards compatible forever. I want to get rid of all that nasty RDF stuff.
Just to remember: PrefBar 6.0 was the first one which used JSON based datasources. That means that the RDF datasource format is obsolete since about two years.
So if you don't want to submit your buttons, the best way would be "re-export" them to have them in the new JSON based format. As soon as PrefBar no longer supports the old format, the old files can no longer be imported.
tibitts wrote:You probably need to toggle this pref to enable click-to-play:
plugins.click_to_play;true
Maybe that's it. At least in my Firefox 23 on Windows this Pref seems to be "false" by default. Toggling it to "true" forces me to use the new interface to set plugin status.
But nice to know that the updated code seems to work. So I'll prepare to ship this as 6.2.2.
-
- Posts: 35
- Joined: August 20th, 2004, 5:15 pm
- Location: California
- Contact:
Re: [Ext] PrefBar 6.2.1 awaiting review
Windows XP SP3
SeaMonkey 2.20 (with "Advertise Firefox compatibility" disabled)
I just now discovered that the User Agent menulist resets to "Real UA" whenever I reload a Web page.
I had trouble viewing a particular Web site. I cleared all cookies for that domain, changed the UA to spoof Firefox 23, and then selected the Reload button on my browser's navigation toolbar. The spoofing was cancelled.
----------------------------------------------
Ooops!!
The problem was caused by the Secret Agent 1.6 extension. I disabled the extension, and the problem disappeared.
----------------------------------------------
Secret Agent 1.6 provided an option not to change the UA string, no matter whether it was the actual string or a spoofing string. However, that option would then restore the actual UA string on the next HTTP request.
Now, Secret Agent 1.12 is compatible with PrefBar's User Agent menulist. If the option in Secret Agent is not to change the UA string, then it leaves the UA string alone. Spoofing from outside of Secret Agent is no longer affected.
(comment updated 12 Dec 2013)
SeaMonkey 2.20 (with "Advertise Firefox compatibility" disabled)
I just now discovered that the User Agent menulist resets to "Real UA" whenever I reload a Web page.
I had trouble viewing a particular Web site. I cleared all cookies for that domain, changed the UA to spoof Firefox 23, and then selected the Reload button on my browser's navigation toolbar. The spoofing was cancelled.
----------------------------------------------
Ooops!!
The problem was caused by the Secret Agent 1.6 extension. I disabled the extension, and the problem disappeared.
----------------------------------------------
Secret Agent 1.6 provided an option not to change the UA string, no matter whether it was the actual string or a spoofing string. However, that option would then restore the actual UA string on the next HTTP request.
Now, Secret Agent 1.12 is compatible with PrefBar's User Agent menulist. If the option in Secret Agent is not to change the UA string, then it leaves the UA string alone. Spoofing from outside of Secret Agent is no longer affected.
(comment updated 12 Dec 2013)