CTP doorhanger is not showing the right corresponding pop-up

VERIFIED FIXED in Firefox 26, Firefox OS v1.2

Status

()

Core
Plug-ins
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: pauly, Assigned: Benjamin Smedberg)

Tracking

28 Branch
mozilla28
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox26+ verified, firefox27+ verified, firefox28 verified, b2g-v1.2 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Starting with Nightly 2013-10-28, FF 26b1 the CTP doorhanger doesn't show the right pop-up. Suspected bug 926605.
STR:
1. Set Flash to 'Ask to activate'
2. Open youtube video and activate Flash
3. Click on the doorhanger

AR: Pop-up shows 'Allow now' , 'Allow and remember'
ER: 'Block plugin', 'Continue allowing'
Which operating systems and Flash versions did you test?
(Assignee)

Comment 2

4 years ago
It doesn't matter. This was a good catch, although not a stop-ship issue because it only affects the case where you're changing a permission and load the doorhanger again.
(Assignee)

Comment 3

4 years ago
Created attachment 824916 [details] [diff] [review]
CTP doorhanger does not update to show the new plugin state after the user clicks allow or block; update pluginInfo.fallbackType with the new state in gPluginHandler._updatePluginPermission, r?jaws

I'm sorry jaws for throwing a bunch of things at your review queue like this. Let me know if you're backed up and if there's somebody else you think can help with reviews.
Attachment #824916 - Flags: review?(jaws)
(Assignee)

Updated

4 years ago
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Attachment #824916 - Flags: review?(jaws) → review?(dkeeler)
Comment on attachment 824916 [details] [diff] [review]
CTP doorhanger does not update to show the new plugin state after the user clicks allow or block; update pluginInfo.fallbackType with the new state in gPluginHandler._updatePluginPermission, r?jaws

Review of attachment 824916 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. r=me as long as my comments are addressed.

::: browser/base/content/browser-plugins.js
@@ +682,5 @@
>          permission = Ci.nsIPermissionManager.ALLOW_ACTION;
>          expireType = Ci.nsIPermissionManager.EXPIRE_SESSION;
>          expireTime = Date.now() + Services.prefs.getIntPref(this.PREF_SESSION_PERSIST_MINUTES) * 60 * 1000;
>          histogram.add(0);
> +        aPluginInfo.fallbackType = Ci.nsIObjectLoadingContent.PLUGIN_ACTIVE;

I'm concerned that this code could get out of sync with how fallbackType is calculated, but if the page has removed the plugin elements in question, then we can't query them for the value, so I don't really see any other option. Although, if we have tests that ensure these values stay correct, then that should be fine.

@@ +700,5 @@
>          expireType = Ci.nsIPermissionManager.EXPIRE_NEVER;
>          expireTime = 0;
>          histogram.add(2);
> +        switch (aPluginInfo.blocklistState) {
> +	  case Ci.nsIBlocklistService.STATE_OUTDATED:

Shouldn't this be STATE_VULNERABLE_UPDATE_AVAILABLE? Or both?
Attachment #824916 - Flags: review?(dkeeler) → review+
(Assignee)

Comment 5

4 years ago
https://hg.mozilla.org/integration/fx-team/rev/04fabfcc28c5
Version: 26 Branch → 28 Branch
https://hg.mozilla.org/mozilla-central/rev/04fabfcc28c5
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
(Assignee)

Comment 7

4 years ago
Comment on attachment 824916 [details] [diff] [review]
CTP doorhanger does not update to show the new plugin state after the user clicks allow or block; update pluginInfo.fallbackType with the new state in gPluginHandler._updatePluginPermission, r?jaws

[Approval Request Comment] Rollup approval summary being sent to firefox-dev and r-d.
Attachment #824916 - Flags: approval-mozilla-beta?
Attachment #824916 - Flags: approval-mozilla-aurora?
Comment on attachment 824916 [details] [diff] [review]
CTP doorhanger does not update to show the new plugin state after the user clicks allow or block; update pluginInfo.fallbackType with the new state in gPluginHandler._updatePluginPermission, r?jaws

Same as the others, approving for landing asap to get early beta feedback.
Attachment #824916 - Flags: approval-mozilla-beta?
Attachment #824916 - Flags: approval-mozilla-beta+
Attachment #824916 - Flags: approval-mozilla-aurora?
Attachment #824916 - Flags: approval-mozilla-aurora+
Paul, please verify this is fixed in all patched branches.
Keywords: verifyme
(Reporter)

Comment 10

4 years ago
Verified fixed FF 28.0a1 (2013-11-04) on Win 7, Mac OS X 10.7.5, Ubuntu 12.04
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox28: --- → fixed
(Reporter)

Updated

4 years ago
status-firefox28: fixed → verified
(Assignee)

Comment 11

4 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/82c4cd6c3b93
https://hg.mozilla.org/releases/mozilla-beta/rev/42519ce90e7f
status-firefox26: affected → fixed
status-firefox27: affected → fixed
tracking-firefox26: --- → +
tracking-firefox27: --- → +

Comment 13

4 years ago
Verified as fixed on Firefox 26b3 - 20131107161719 - on Windows 7 64bit, Ubuntu 13.04 32bit and Mac OS X 10.9.
QA Contact: ioana.budnar

Updated

4 years ago
status-firefox26: fixed → verified
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0

Verified as fixed on latest Aurora 27.0a1 (buildID: 20131122004001).
status-firefox27: fixed → verified
Keywords: verifyme
(Reporter)

Updated

4 years ago
Depends on: 943383

Updated

4 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.