Closed Bug 522975 Opened 15 years ago Closed 15 years ago

reduce severity of .NET Framework Assistant and WPF plugin block to 1 ("soft block")

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: shaver, Assigned: morgamic)

References

Details

To allow OS-patched FF 3.5 users to override the block, in the absence of reliable version information for the plugin itself, we want to reduce the severity of the blocklist entry to "1".

We should also update the blocklist page to indicate that it's now a soft block; we can make up some words for that, or just put "(overridable)" next to the entry for now.
Depends on: 462433
Assignee: nobody → morgamic
Status: NEW → ASSIGNED
Push bug filed, waiting on IT.
(will do the www update after)
What will users see exactly?  I'm working on the SUMO article for this.
I just tried updating the blocklist. (tested twice) Each time, this is the entry saved in my blocklist.xml:

  <pluginItem severity="1">
    <match name="name" exp="Windows Presentation Foundation"/>
    <versionRange>
      <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
        <versionRange minVersion="" maxVersion="*"/>
      </targetApplication>
    </versionRange>
  </pluginItem>

This is with Firefox 3.5.3 on Windows XP.

If I reset and reupdate it counts as a hard block. "severity" was supposed to end up in "versionRange", wasn't it?...
Yeah, I think morgamic is fixing that now...
I moved severity="1" to <versionRange> in r53670
Preview seems to work for me. Updated and restarted Firefox, then the lock on the entry was off and re-enabling was allowed. Reset and restarted and the optionality seems to work as advertised.

However, I see that on preview the extension is back in, this time at soft block level. Just double checking: this is correct? (personally, I'd prefer this, but it was previously fully removed) Problem for me with this, though. I haven't been able to get the extension to show in my blocklist window at all. Always only the plugin. (bug 522777 comment 20) This time, this seems to have the effect of a hard block for me because I can't opt out without it showing at all.
(In reply to comment #8)
> Problem for me with this, though. I
> haven't been able to get the extension to show in my blocklist window at all.
> Always only the plugin. (bug 522777 comment 20) This time, this seems to have
> the effect of a hard block for me because I can't opt out without it showing at
> all.

Scratch that. I figured out what the problem is. It doesn't show in the blocklist window because it's not compatible with 3.5.3 and was disabled anyway. Override the version check and it's all good with the option to block or not. Should probably not be hiding it in that instance.
(In reply to comment #8)
> However, I see that on preview the extension is back in, this time at soft
> block level. Just double checking: this is correct?

I hadn't run the removal SQL on preview because I didn't think it would matter, but so as not to confuse people, I've updated it.
The effect in comment 9 seems to be intentional: bug 422900. Mine wasn't manually disabled, but I don't know if that distinction is worth bothering with. Just tripped me up when testing. (sorry for the bugspam with that) Thanks for the clarification, in any case.

One more hiccup: The "Known to cause security or stability issues." warning label and "More Information" link for the soft blocked plugin does not show in 3.5.3, but it does work with latest Minefield. Extension's works fine.
The blocklist dialog intentionally only displays items that need to be disabled or warned about and aren't already disabled. There really isn't anything to be gained in warning a user about an extension that they aren't using or can't use anyway.
(In reply to comment #7)
> We need some a+'s from people on
> https://preview.addons.mozilla.org/blocklist/1/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/3.5.3/
> before pushing live.

This appears to be correct to me though I haven't been able to test properly on a windows machine.
Latest Namoroka has the fix to show the Add-on Manager's soft blocked plugin warning line and info link too. Latest Shiretoko does not. I don't suppose a fix could be brought over for 3.5.4 or 3.5.5 so the WPF plugin gets the warning and link in the manager? (should I file a bug for this?)
(In reply to comment #6)
> I moved severity="1" to <versionRange> in r53670

In case I'm AFK when this gets reviewed, the actual fix spans several revisions in SVN.  Just look at the commits on blocklist.php and you'll see them.
(In reply to comment #14)
> Latest Namoroka has the fix to show the Add-on Manager's soft blocked plugin
> warning line and info link too. Latest Shiretoko does not. I don't suppose a
> fix could be brought over for 3.5.4 or 3.5.5 so the WPF plugin gets the warning
> and link in the manager? (should I file a bug for this?)

I'm not aware of any code difference between Namoroka and Shiretoko where this is concerned. Please file a bug.
This is fixed and in production (bug 523116)
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
> We should also update the blocklist page to indicate that it's now a soft
> block; we can make up some words for that, or just put "(overridable)" next to
> the entry for now.

Hmm, this hasn't been done yet though
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 523133
Filed bug 523133 for the missing warning and link with Firefox 3.5.
Blocklist webpage also still has "Microsoft .NET Framework Assistant" listed.
This was fixed and then fully removed later. Page was also updated again.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.