133863 - Netscape Plug-in Finder Service Preference UI

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Gregg Landskov (gone)]

Need to add UI to an existing preference panel to allow users to turn off/on
Netscape's plugin finder service.

I know this is late in the game, but the change is trivial and extremely
important for improving our plugins acquisition experience while allowing the
user appropriate control of the functionality.

This pref will be on by default on the Commercial product and off by default for
Mozilla (unless determined otherwise by Mozilla).

The existing pref location: Edit | Preferences > Navigator > Helper Applications
(Screenshot is attached below)

The UI to be added should include a Box below the "File Types" box, and above
the "Opening Files" box.  The "File Types" box should be made smaller to
accomodate the new pref.  Inside the new box should be a checkbox and the
following text:  

"Use the Netscape Plug-in Finder Service to help me acquire my plug-ins."

I will file another bug immediately after this to cover the back end work.

Marlon - Please comment about any UI description if necessary.
Steve - Please comment about any language changes if necessary.

Comment 1

[Gregg Landskov (gone)]

Attachment: Preference Panel Screenshot

Comment 2

[Gregg Landskov (gone)]

Reassigning to Trudelle per ADT; adding nsbeta1

Peter - please direct as necessary.  I know your team is slammed, was told by
PeterL and ADT to have Nav team do this work.

Comment 3

[Gregg Landskov (gone)]

adding mcarlson, as we hope to have this UI change landed by Friday 3/29, but
want to have it on her radar now.

Comment 4

[Peter Lubczynski]

The back end is bug 133864. This bug is about adding a single checkbox UI
element for the new pref.

Comment 5

[Jaime Rodriguez, Jr.]

Marking this bug as a dependency on bug 133864.

Comment 6

[Daniel Veditz [:dveditz]]

Why do we need UI for this? Assuming the service works, why would Netscape users
want to turn it off?

Why would Mozilla want a simple check-box saying "use Netscape or not"? A URL
preference would be more appropriate, in case anyone came up with an open source
alternative service.

Or does this service start automatically installing things for people? In that
case maybe the Software Installation pane is a more appropriate place.

Comment 7

[rudman]

This isn't entirely a response to Dan's comments above, but regarding his point
about Netscape and Mozilla, maybe the wording can be generic. Like, "Use a
plug-in finder service to obtain plug-ins."

How much real estate do we really have to play with on the dialog box? Instead
of the one-line pref as the addition, we should really add a section, even if it
has the single pref. Similar to the "Opening files" section, which has a title
and text below. If the section were titled "Obtaining plug-ins," then text below
could be something like, "A plug-in finder service can locate and install
plug-ins automatically." If we need to say something about the unchecked state
beyond what will appear in the help content, then it could be something like,
"If this option is unchecked, you may need to get the plug-in directly from the
vendor, and the plug-in may not be installed automatically."

To summarize:

--Obtaining plugin-ins-----------------------------------
|                                                        |
|  A plug-in finder service can locate and install       |
|  plug-ins automatically.                               |
|                                                        |
|  [ ] Use a plug-in service to obtain plug-ins. If this |
|      option is unchecked, you may need to get the      |
|      plug-in directly from the vendor, and the plug-in |
|      may not be installed automatically.               |
---------------------------------------------------------|

The Help content can make it clear that, at least for Netscape builds, the
service is provided by Netscape. But that might not matter to the user much.

Have I captured correctly what the pref is all (or mainly) about?

Comment 8

[Peter Trudelle]

Gee, this is a poorly-timed surprise, to say the least.  If this were really
were critical for MachV, I would have expected to hear about it months ago. If I
assign it to prefs component to be done before UI freeze for beta, then we'd
have to stop work on Fastloading XUL, wasting weeks of effort on this
performance (our #1 MachV priority) enhancement just as it is landing. Even
then, it would have to get in line behind disabling the popup UI (for Netscape
only), which is considered stop-ship.  Other engineers have similar last-minute
work, and I'm not clear where this should fit in priority order.  Is having a
pref for this really critical, considering how few people would ever use it? I
don't see why we couldn't just offer to use the service whenever a plugin is
needed. That will be the experience for 90% of our users anyway.  


BTW, obviously none of this belongs in bugzilla. 

Comment 9

[Peter Lubczynski]

I sort of agree with Peter that maybe UI isn't really needed, maybe rel note the
pref. But then again, always hitting the Netscape.com server when searching for
plugins may be a privacy concern to some (remember search). We currently already
always hit the server in some situations without any prefs.

Comment 10

[rudman]

This definitely isn't a relnote issue---at least, we don't (or try not to)
document basic features in the relnotes. If there's no UI or tasks involved, the
content wouldn't go into Help. On the Netscape side, we could discuss the
feature in the end-user book, but not everyone gets that. 

What is needed here is a PRD of sorts---maybe a one-pager highlighting what the
feature really is, why it's important (and to whom), etc., so we're clearer what
the justification is for the UI addition. Too many questions and "maybe"
statements in the bug.

Comment 11

[Gregg Landskov (gone)]

Improved user experience for plugins acquisition is a high priority for Mach V,
but only about a week ago did any possibilty of UI changes come about.
It was always going to be on (no pref).

Privacy concerns came up due to the fact that Netscape servers would be making a
decision about where to point users to obtain a plugin.  This is a fundamental
change in functionality.  We obviously WOULD NOT have access to any unique user
information, but we want to cover ourselves in case sensitive users don't want
us to do this, despite a greatly enhanced user experience in many cases.  

We can't afford not to improve our plugin finder service, and we should not
compromise our privacy position.  Adding a visible preference is the best and
easiest solution to resolve this issue. 

I obviously don't want to compromise fast load xul, that work should not stop.
This is a very minor change (I know it is really late), and puts us in the right
position on both fronts.

I look to the adt to help prioritize and help resolve who can do this work.

Comment 12

[Peter Trudelle]

nsbeta1+, ->1.0, ADT2

Comment 13

[rudman]

Adding doc volken, for potential doc impact.

So, what's the UI? Who's court is this in? Maybe the bug should be Marlon's or
Gregg's until the UI is finalized, then back to Peter?

Comment 14

[scottputterman]

Shuehan is going to be able to work on this bug.  I'm reassigning to her.  If
you think that reassigning to Gregg or Marlon is the best thing to do, then if
you do it, please reassign back to her afterwards.

Comment 15

[shliang]

Attachment: patch

box containing checkbox labeled "Use the Netscape Plug-in Finder Service to
help me acquire my plug-ins." will appear in pref panel for netscape, but not
in mozilla (so no changes will appear in the pref panel for mozilla).

i'm confused as to whether the box is supposed to be in the pref panel for
both, with the checkbox on by default in netscape and off in mozilla, or if the
box is supposed to just not be there in mozilla.

Comment 16

[shliang]

Attachment: screenshot

Comment 17

[Jaime Rodriguez, Jr.]

How does the proposed text notify the user that they will be sent through
Netscape servers, if they check the box (i.e. How are we advising the user that
information is being sent to a server - Privacy concern)?

Comment 18

[Peter Lubczynski]

Might be a tad misleading when unchecked as the PFS is ALWAYS used anyway when
pluginpage/pluginurl are missing.

Comment 19

[Arun Ranganathan]

Remember: as peterl says, we hit a server *anyway* iff. the pluginurl or
pluginspage are missing.  In this case, the "Netscape Plugin Finder Service" is
a series of words suggesting hitting a server for binaries -- does it need to be
more obvious?

Comment 20

[rudman]

Even if the UI appears in Mozilla, can we point to NS PFS and state that in the
UI?  If another vendor wants to distribute Mozilla, there is at least the option
of creating another PFS and resetting the URL for that (the vendor is obligated
to make the changes). 

My text was an attempt at being generic, but if we don't need to be, and can use
Netscape in the UI, then we don't have to come up with two versions (or an overlay).

The text in the screenshot and as proposed by Gregg needs work. It's too wordy,
and I don't think it has the impact we're looking for. If the PFS installs the
plug-ins, too, we should emphasize that, no?

Comments on the text in the screenshot:
"Obtain" seems more commonplace than "Acquire," and for some reason,
sounds/reads better. "Acquire" seems to convey a greater effort on the part of
the user to get something, whereas "obtain" seems closer to simply "get,"
without much effort. And that's what I think we want to convey. So I suggest we
use "Obtaining plug-ins" for the title of the section, and the text for the pref
reads:

"Use the Netscape Plug-in Finder Service to obtain and install plug-ins"

Note no end period. Prefs style is not consistent for end punctuation, but I
hope to provide the spec for that next week. No end punctuation is preferred
style for the pref text context here. 

I think it's strongly implied that a server is involved. There will be
context-sensitive help that explains that the PFS goes to a Netscape server.

Comment 21

[Peter Trudelle]

What is wrong with 'get"?  We use it elsewhere in the text, and several times in
this bug.  It seems quite natural to me.  

If we still fall back on the PFS even when disabled, why not change the text to
"Always use ~" or "~ when the page doesn't specify how to get it", or words to
that effect?

Comment 22

[rubydoo123]

I agree with Peter, why not say something like:

Always use the Netscape Plug-in Finder Service (PFS) to get the plug-in

And there seems to be enough space in the dialog to add a note under the 
checkbox:
Note: If a plug-in location is not specified, the PFS will always be used.

Or some such comment.

Comment 23

[rudman]

I initially thought that "get" was, well, rough...It's better as a linking verb,
as in "getting started." But I'm fine with replacing "obtain" with "get," and
using "Always...." 

The "note" or second sentence of the pref should clarify what happens if the
pref is not selected.

My suggestion, following Peter and Beth's comments, is:

"Always use the Netscape Plug-in Finder Service (PFS) to get plug-ins" [line break]
"If this option is not checked, the PFS is used only when a plug-in location is
not specified by the web page that requires the plug-in." 

As for the title of the box in which the pref appears: There is inconsistency in
those titles across prefs dialog boxes. There's no strong stylistic precedent
for using a verb clause or a noun. I suggest: "Plug-in Finder Service" and leave
it at that.

Comment 24

[Jaime Rodriguez, Jr.]

Adding Asa to cc: list.

Comment 25

[Gregg Landskov (gone)]

I agree with rudman's comments in comment 23.  Let's go with that.  Shuehan, can
you make the change and ask for approvals for commercial?

I sent e-mail last Thursday to [e-mail] on whether they wanted this
pref on or off, or not at all.  Asa, Scott - can you let us know asap?

Comment 26

[Gregg Landskov (gone)]

Shuehan -

Mozilla drivers have given their ok that they want this, but have not decided on
whether they want this preference on or off by default.

So please begin check-in process for both Commercial and Mozilla.

Comment 27

[Jaime Rodriguez, Jr.]

Shouldn't we have bug 133864, before we go checking the front-end in anywhere?
This also, need the reviews and approvals from Drivers and ADT before it has
checkin approval.

Comment 28

[Gregg Landskov (gone)]

Depends on whether it is a higher priority to get the UI work checked in vs.
having the pref functionality work 100%.

PeterL is going to work on checking in the back end work, with the pref turned
"off" by default until the server side work can be finished.  Still, nothing
would be broken, just not the steamlined behavior that we are shooting for in
the first place.

My thought was that getting the UI work finished was more important.  We are not
going to have all the server side work done for a couple weeks at the earliest.

Comment 29

[shliang]

Attachment: patch

in both mozilla and netscape, off by default in mozilla, on by default in
netscape...is that right?

see http://bugscape/show_bug.cgi?id=13144 also

Comment 30

[shliang]

Attachment: screenshot with revised text

please check to see if text is correct now

Comment 31

[rubydoo123]

It looks good to me, but I'm sure others wish to give their opinion on the 
dialog.

Comment 32

[jag (Peter Annema)]

Comment on attachment 77741 [details] [diff] [review]
patch

>Index: xpfe/components/prefwindow/resources/content/pref-applications.xul
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/components/prefwindow/resources/content/pref-applications.xul,v
>retrieving revision 1.44
>diff -u -w -r1.44 pref-applications.xul
>--- xpfe/components/prefwindow/resources/content/pref-applications.xul	29 Mar 2002 02:45:48 -0000	1.44
>+++ xpfe/components/prefwindow/resources/content/pref-applications.xul	4 Apr 2002 22:58:23 -0000
>@@ -36,6 +36,12 @@
>   <script type="application/x-javascript" src="chrome://communicator/content/pref/pref-applications.js"/>
>   <script type="application/x-javascript" src="chrome://communicator/content/pref/overrideHandler.js"/>
>         
>+  <script type="application/x-javascript">
>+  <![CDATA[  
>+  var _elementIDs = ["useNSPluginFinder"];
>+  ]]>
>+  </script>

I'd indent a little more to make the code stand out:

  <script type="application/x-javascript">
    <![CDATA[  
      var _elementIDs = ["useNSPluginFinder"];
    ]]>
  </script>

>@@ -105,6 +111,16 @@
>                 prefstring="pref.application.disable_button.remove"/>
>       </vbox>
>     </hbox>
>+  </groupbox>
>+  <groupbox id="pluginFinderBox">
>+    <caption label="&plugins.label;"/>
>+    <vbox>
>+      <hbox pack="start" align="center">
>+        <checkbox id="useNSPluginFinder" label="&pluginFinder.label;"
>+         prefstring="application.use_ns_plugin_finder"/>

Indent |prefstring| to line up with |id| for readability.

>+      </hbox>
>+      <description>&pluginFinderDesc.label;</description>
>+    </vbox>
>   </groupbox>
>   <groupbox>
>     <caption label="&fileOpening.label;"/>
>Index: modules/libpref/src/init/all.js
>===================================================================
>RCS file: /cvsroot/mozilla/modules/libpref/src/init/all.js,v
>retrieving revision 3.363
>diff -u -w -r3.363 all.js
>--- modules/libpref/src/init/all.js	1 Apr 2002 05:56:24 -0000	3.363
>+++ modules/libpref/src/init/all.js	4 Apr 2002 22:58:23 -0000
>@@ -194,6 +194,9 @@
> // size of scrollbar snapping region
> pref("slider.snapMultiplier", 6);
> 
>+// option to choose plug-in finder
>+pref("application.use_ns_plugin_finder", false);
>+
> // Smart Browsing prefs
> pref("browser.related.enabled", true);
> pref("browser.related.autoload", 1);  // 0 = Always, 1 = After first use, 2 = Never

Off by default is fine with me, but find out what Mozilla wants.

>@@ -363,7 +366,6 @@
> pref("advanced.mailftp",                    false);
> pref("image.animation_mode",                "normal");
> 
>-pref("offline.startup_state",            0);
> pref("offline.send.unsent_messages",            0);
> pref("offline.download.download_messages",  0);
> pref("offline.prompt_synch_on_exit",            true);

I've been told this chunk is for another patch.

Address my nits and you have r=/sr=jag

Comment 33

[Joe Hewitt (gone)]

Comment on attachment 77741 [details] [diff] [review]
patch

r=hewitt

... but you don't need align="center" on the hbox around the checkbox, because
there is only one child

Comment 34

[Gregg Landskov (gone)]

Where are we in the approval process?  Do we need to get this going to make sure
we aren't too far past UI freeze?

Comment 35

[Lori Kaplan]

a=UI
approving nomination. adding status impact. This feature is needed by netscape
to allow users to choose whether to use the PFS. It might be considered a
privacy violation if we don't give people the option to not use the PFS. 
cc'ing mcarlson for localization approval. 

Comment 36

[rubydoo123]

looks like we need driver approval and then adt approval

pinging asa

Comment 37

[rubydoo123]

I totally missed Lori's a=, so just need adt

Comment 38

[Jaime Rodriguez, Jr.]

Should we make sure the back-end dependent bug 133864 is resolved before making
a change to the front-end? 

Comment 39

[Lori Kaplan]

beppe: I speak only for UI. I think you might still need drivers approval. 

Comment 40

[shliang]

i emailed for drivers approval for this and bugscape 13144 this morning, 
waiting on that

Comment 41

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) approval for checkin to 1.0, pending back-end being
enabled.

Comment 42

[Asa Dotzler [:asa]]

Comment on attachment 77741 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 43

[Ben Goodger (use ben at mozilla dot org for email)]

Can you verify that this addition doesn't cause this panel to run off screen 
on platforms that use bigger fonts by default, like Mac?

Comment 44

[Jaime Rodriguez, Jr.]

Second Ben's comment for double byte characters like Japanese.

Comment 45

[Michele Carlson]

We have already passed the localization freeze date (UI freeze) on 3/29. Please
check in any UI changes today. thanks.

Comment 46

[shliang]

dtd going in today because of localization freeze, other stuff will go in when 
back-end is enabled.

Comment 47

[Jaime Rodriguez, Jr.]

The blocker bug 133864 should be resolved fixed sometime tonight. Once that goes
in, pls land this on the trunk and the branch.

Comment 48

[Jaime Rodriguez, Jr.]

bug 133864 is resolved. Pls check this into the branch and the trunk.

Comment 49

[timeless]

what in the world?

you guys just rushed in random text in response to a localization freeze?

I'm going to cc some people for a sanity check on the wording. at first glance 
I think the wording is currently insane.

I'm currently preoccupied by the backend tripping over procedure, but I promise 
to get back to this bug later.

Comment 50

[timeless]

Ok, so I decided to find myself an end user. one turned up in #mozillazine, 
here's the relevant portion of our conversation:

<hoarycripple> timeless: the wording is a bit convoluted
<hoarycripple> timeless: you're talking about the plugin finder?
<timeless> yes. yes.
<timeless> so please tell me what you think it says
<hoarycripple> timeless: if the option is checked, regardless of the fact 
that the page specifies a plugin location, moz will use the pfs
<hoarycripple> timeless: if the option is unchecked, then  the pfs is used 
only when the page does not specify a location for the plugin
<timeless> hoarycripple: ok, now the fun part.  what do you think they meant 
to say? and why do you think this option was added to the ui?
<hoarycripple> timeless: ok, so if the pfs is used all the time, then it 
might not know where an esoteric plugin is hiding
<hoarycripple> timeless: so i figure that you should leave that unchecked all 
the time
<hoarycripple> timeless: why *was* it added?
<timeless> hoarycripple: you make a great end user
<timeless> it was added for privacy reasons
<hoarycripple> timeless: news for you - i am an end user
<hoarycripple> timeless: i read most of the bug dialog - i still thing that 
UI is not needed for this.

I'm not sure about the need for a ui for this. But I do feel that the UI text 
should be correct.

Comment 51

[Jaime Rodriguez, Jr.]

shliang - when can you get this in?

Comment 52

[rudman]

Timeless: So suggest something different for the text.

I don't intend to get into a flame war in a bug, but I suggest you tone down
your bug comments. Comments like "I think the wording is currently insane"
aren't particularly helpful and only detract from your credibility.

Comment 53

[Ben Bucksch (:BenB)]

I have to say, I also don't see why this option has been added. The page usually
points to e.g. the Macromedia Flash page. Do you want to offer XPIs and
Macromedia  doesn't want to do so from their site, or what?

Comment 54

[timeless]

Ok, some quick reading of comments by [e-mail] 
Comment 7 had a fine suggestion.
Comment 20 had good observations.

about obtain and get. what I would have liked is 'find' in addition to get.

Can someone please summarize the purpose of this preference?

I was under the impression that Comment 9 was key.  After rereading, I'm 
totally lost.
If Comment 9 is the key then it should be just always or never.
If the purpose is to allow companies to say they always want to use netscape 
instead of the page author's suggestion, then I don't see the use of the gui 
preference.

Trudelle, I know you weren't really interested in spending time on this bug, 
but could you please find out what the intended audience was for this feature?

For now, I'd like to request that one of the mozilla UI peers (which has 
been named in recent bugs) sign off on this before it is checked into the mozilla tree. (afaik the following people are not among that list: me, jag, hewitt)

Comment 55

[Matthew T (active 1999-2002)]

If you're going to use a checkbox, it should be a clear on/off choice. 
Inserting lots of verbiage about what happens when the choice is off, as you're 
doing here, is a telltale symptom of using a checkbox for an either/or choice, 
where you should be using option buttons instead. (The same mistake has been 
made for the encrypting vs. obscuring pref for Wallet, but that's no excuse.)

As described in the screenshot, it appears as if there *still* isn't a way to 
turn the PFS off completely (`the PFS is [still] used only when ...') -- and 
isn't that why the GUI was introduced in the first place?

If the option does what the current GUI says it does, I'd present it as:
|
| When looking for a plug-in to download, first try:
| ( ) the download page suggested by the Web site
| (*) the Netscape Plug-in Finder Service

If the option does what I think it's supposed to do, I'd present it as:
|
| [/] Use the Netscape Plug-in Finder Service for missing plug-ins

In either case, it should be *below* the Reset button section, not above it. 
The Reset button section is much more closely related to the filetype 
associations than it is to your preferred source of plug-ins.

Will that be all, m'lud?

Comment 56

[shliang]

jaime- i'll get this in sometime later today

Comment 57

[shliang]

fixed in trunk and branch

Comment 58

[shliang]

took this out by accident

Comment 59

[shrirang khanzode]

v