Disable dom.ipc.plugins.asyncInit in Firefox 40.0.3

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: kohei, Assigned: aklotz)

Tracking

({dev-doc-needed, site-compat})

40 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox40+ verified, firefox41+ wontfix, relnote-firefox 40+)

Details

[Tracking Requested - why for this release]:

As Alice said in Bug 1196000, the add-on hotfix is not a complete way to solve the issue. Some are new users, some may disable their add-on auto updates, etc. The async pref should be disabled on 40 and 41 branches. Firefox 40.0.3 goes to build tomorrow, so the backout patch is needed ASAP.
Right, I will try to do the backout myself if nobody does that before me :)
Because of the timing issue, I pushed it myself.
https://hg.mozilla.org/releases/mozilla-release/rev/24cab2512daa

For beta, I don't know if we want to disable it now. Ritu? Aaron?
Flags: needinfo?(rkothari)
Flags: needinfo?(aklotz)
Setting for some quick verification in 40.0.3 (verifying pref and one issue under bug 1195607 should be enough).
Flags: qe-verify+
Added to the release notes "Disable the asynchronous plugin initialization (1198590)"

Comment 5

4 years ago
(In reply to Sylvestre Ledru [:sylvestre] from comment #2)
> For beta, I don't know if we want to disable it now. Ritu? Aaron?

If Aaron get get us fixes for all the issues we saw in 40 which caused us to disable it, and those fixes are low enough risk for beta, I think we should leave it on. If we can't get those fixes in time and with low enough risk, we should disable in 41.

That said, this takes us into a pretty problematic situation: async plugin init is AFAIK still disabled when e10s is on, and all the channels below beta have e10s on by default - which means that we never get any testing of any patches to it before we hit beta, so we technically do not have any avenue to do anything that is not a low-risk fix.
Assignee

Comment 6

4 years ago
There's a fix under review in bug 1194600 that takes care of everything (pending verification, of course). I recommend that we uplift that to beta.
Flags: needinfo?(aklotz)
I also feel that we should not be disabling it now, it seems too soon. We still have 1-2 weeks worth of Beta feedback to trickle in for FF41. Let's re-evaluate around Beta8/9 time frame.
Flags: needinfo?(rkothari)
(In reply to Ritu Kothari (:ritu) from comment #7)
> I also feel that we should not be disabling it now, it seems too soon. We
> still have 1-2 weeks worth of Beta feedback to trickle in for FF41. Let's
> re-evaluate around Beta8/9 time frame.

On a personal note here, keep in mind that the feature was enabled for a full Beta 40 cycle, no issues were found by the manual QA team (and all previously found issues no longer reproduced towards the end of the Beta cycle) and yet when we released 40 we got a whole bunch of problems coming in. I see this as the kind of feature that could use some more time in Beta, just because we need more real life user testing on it... my personal recommendation would be to keep it enabled towards the end of Beta 41, then disable it, and then give it another full Beta cycle in 42 before we decide to release.
Confirmed that dom.ipc.plugins.asyncInit is false by default on Firefox 40.0.3 (20150826023504), using Windows 10 Pro x64 (10525), Ubuntu 14.04 (x86) and Mac OS X 10.9.5.

I've also looked at a few of the issues attached to Bug 1195607 to make sure that they're no longer reproducible now that async plugin init was safely disabled via pref-- e.g. Bug 1195140, Bug 1195269, Bug 1195761.
Flags: qe-verify+
Assignee

Updated

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Summary: Disable dom.ipc.plugins.asyncInit in Firefox 40 and 41 Beta → Disable dom.ipc.plugins.asyncInit in Firefox 40.0.3
Assignee

Comment 10

4 years ago
Marking wontfix for 41 as long as it stays enabled on beta.

Comment 11

4 years ago
This is just a comment for clarity on my part. I found my addon's port messages were broken when called from iFrames (I can go into more details if needed). However, this was fixed in the latest release and now the issue is gone. 

So thanks if this was the fix. 

Michael
Assignee

Comment 12

4 years ago
(In reply to Michael Balazs from comment #11)
> This is just a comment for clarity on my part. I found my addon's port
> messages were broken when called from iFrames (I can go into more details if
> needed). However, this was fixed in the latest release and now the issue is
> gone. 
> 
> So thanks if this was the fix. 
> 
> Michael

I would suggest that you file a new bug with more detailed information about your problem. The feature in this bug is disabled for the remainder of the 40 release but will eventually be re-enabled.
Flags: needinfo?(Michael.Balazs)

Comment 13

4 years ago
(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #12)
> (In reply to Michael Balazs from comment #11)
> > This is just a comment for clarity on my part. I found my addon's port
> > messages were broken when called from iFrames (I can go into more details if
> > needed). However, this was fixed in the latest release and now the issue is
> > gone. 
> > 
> > So thanks if this was the fix. 
> > 
> > Michael
> 

Aaron, I apologize. It turns out this was not the cause of the issue but rather a change in the addon-sdk. I just happened to have FF update at the same time as switching to an older version. 

Michael 
> I would suggest that you file a new bug with more detailed information about
> your problem. The feature in this bug is disabled for the remainder of the
> 40 release but will eventually be re-enabled.
Flags: needinfo?(Michael.Balazs)
Aaron, what are your intentions about keeping Async Plugin Init enabled in Firefox 41? Do you want to release the feature enabled in Firefox 41, or do you intend to disable this and have it ride Firefox 42 beta as well? If you want to disable it then this would probably be the right time as we only have 2 builds left to release: 41 beta 9 and 41 RC.

In bug 1195607 I see that there still are some dependencies that are still open, and also not all dependencies that are Duplicate or Fixed have been confirmed by QA/reporters yet. Under these circumstances there is a risk that releasing the feature in Firefox 41 will still break things for users.
Flags: needinfo?(aklotz)

Comment 15

4 years ago
AFAIK, the current plan is to land a whitelisting approach for 41 that will only enable it for certain plugins.

Comment 16

4 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #15)
> AFAIK, the current plan is to land a whitelisting approach for 41 that will
> only enable it for certain plugins.

This was actually already done in bug 1194488.
Assignee

Comment 17

4 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #15)
> AFAIK, the current plan is to land a whitelisting approach for 41 that will
> only enable it for certain plugins.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #16)
> (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #15)
> > AFAIK, the current plan is to land a whitelisting approach for 41 that will
> > only enable it for certain plugins.
> 
> This was actually already done in bug 1194488.

Correct. The plan is to go to release with the feature enabled in 41. Some bugs blocking bug 1195607 are still unresolved but I don't consider them to be serious blockers.
Flags: needinfo?(aklotz)

Comment 18

4 years ago
OK so will this feature be released with version 41?
I'd like to know what will happens exactly.
THanks.
Assignee

Comment 19

4 years ago
Currently it is slated to release in 42.
You need to log in before you can comment on or make changes to this bug.