The default bug view has changed. See this FAQ.
Bug 1116806 (asyncplugininit)

Let Asynchronous Plugin Initialization ride the train

RESOLVED FIXED in Firefox 40

Status

()

Core
Plug-ins
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: aklotz, Assigned: aklotz)

Tracking

(Depends on: 1 bug, {dev-doc-complete, site-compat})

unspecified
mozilla39
x86
All
dev-doc-complete, site-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox39+ disabled, firefox40- fixed, firefox41 fixed, relnote-firefox 39+)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

2 years ago
Tracking bug for enabling Async Plugin Init by default.
(Assignee)

Updated

2 years ago
Depends on: 998863
(Assignee)

Updated

2 years ago
Depends on: 1115437
(Assignee)

Updated

2 years ago
Depends on: 1115436
(Assignee)

Updated

2 years ago
Depends on: 1116827
(Assignee)

Updated

2 years ago
Depends on: 1116825
(Assignee)

Updated

2 years ago
Depends on: 1117244

Updated

2 years ago
Depends on: 1117398
(Assignee)

Updated

2 years ago
Depends on: 1117864
(Assignee)

Updated

2 years ago
Blocks: 869208
(Assignee)

Updated

2 years ago
Depends on: 1119060
(Assignee)

Updated

2 years ago
Depends on: 1119565

Updated

2 years ago
Depends on: 1121011
(Assignee)

Updated

2 years ago
Depends on: 1121158
(Assignee)

Updated

2 years ago
Depends on: 1121162
(Assignee)

Updated

2 years ago
No longer depends on: 1119565

Updated

2 years ago
Depends on: 1123549
(Assignee)

Updated

2 years ago
No longer depends on: 1123549
(Assignee)

Updated

2 years ago
Depends on: 1123916
(Assignee)

Updated

2 years ago
Depends on: 1125128
(Assignee)

Updated

2 years ago
Depends on: 1127888

Updated

2 years ago
Alias: asyncplugininit
Depends on: 1130747
No longer depends on: 1125128
(Assignee)

Comment 1

2 years ago
Created attachment 8566383 [details] [diff] [review]
Enable asyncInit

This will land in tandem with bug 1115437 and bug 1127888 which will ensure that all tests pass both with e10s and without.
Attachment #8566383 - Flags: review?(vdjeric)
Comment on attachment 8566383 [details] [diff] [review]
Enable asyncInit

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

Post an announcement on m.d.platform informing them of this change, types of bugs to look out for, where to report them, and who to CC
Attachment #8566383 - Flags: review?(vdjeric) → review+
Depends on: 1129174
(Assignee)

Updated

2 years ago
No longer depends on: 1129174
(Assignee)

Comment 3

2 years ago
Filed bug 1135130 for e10s-specific issues. Since this bug deals with riding the trains, and e10s is not yet riding the trains, e10s-specific bugs should not be blocking this one.
Georg: Where will the asyncPluginInit value appear in the environment section? User-changed prefs?
Flags: needinfo?(gfritzsche)
(Assignee)

Comment 5

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/aec4384126ef
(Assignee)

Updated

2 years ago
Depends on: 1135491
(Assignee)

Comment 6

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/d1f1624d615c

Backed out due to the sudden emergence of bug 1135431 when asyncInit is turned on :-(. According to try it goes orange ~50% of the time on Win64 debug.
(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #4)
> Georg: Where will the asyncPluginInit value appear in the environment
> section? User-changed prefs?

Yes. We have it in the list in bug 1122046, bug 1131138 will take care of adding the requested prefs.
Flags: needinfo?(gfritzsche)
(Assignee)

Updated

2 years ago
Depends on: 1136930
(Assignee)

Comment 8

2 years ago
Release Note Request (optional, but appreciated)
[Why is this notable]: It will significantly improve browser responsiveness when NPAPI plug-ins are instantiated in a web page.
[Suggested wording]: Asynchronous initialization of NPAPI plug-ins has been enabled.
[Links (documentation, blog post, etc)]:
http://dblohm7.ca/blog/2014/06/17/asynchronous-plugin-initialization-an-introduction/
http://dblohm7.ca/blog/2014/12/31/asynchronous-plugin-initialization-nightly/
relnote-firefox: --- → ?
Backed out for frequent Linux e10s browser_tab_dragdrop.js timeouts.
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b1064f9e770

https://treeherder.mozilla.org/logviewer.html#?job_id=7664554&repo=mozilla-inbound
Assignee: nobody → aklotz
(Assignee)

Updated

2 years ago
Blocks: 1135130
https://treeherder.mozilla.org/logviewer.html#?job_id=7670090&repo=mozilla-inbound looks like fallout from this as well.
(Assignee)

Comment 11

2 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #10)
> https://treeherder.mozilla.org/logviewer.html#?job_id=7670090&repo=mozilla-
> inbound looks like fallout from this as well.

No, that looks like bug 1128064.
(Assignee)

Comment 12

2 years ago
Comment on attachment 8566383 [details] [diff] [review]
Enable asyncInit

Approval Request Comment
[Feature/regressing bug #]: Asynchronous plugin initialization
[User impact if declined]: Feature won't be available in 38 and will not be able to ride the trains ahead of e10s.
[Describe test coverage new/current, TreeHerder]: Flag enabled and tested extensively on try.
[Risks and why]: Moderate. Feature has been in the tree and tested for some time now. New unexpected issues may be encountered with a larger audience. It hasn't landed on Nightly yet because of e10s issues. Because this feature has a different implementation on e10s, it really needs to be activated on Aurora to be able to properly determine its effects in the non-e10s case. At the same time, we can always pref it off again if there are too many problems.
[String/UUID change made/needed]: None.
Attachment #8566383 - Flags: approval-mozilla-aurora?
As 38 is going to be an ESR release, can we postpone that change for 39? The merge is next monday.
It is a nice feature but I don't see the point of rushing here... Especially with a moderate risk.
(Assignee)

Comment 14

2 years ago
(In reply to Sylvestre Ledru [:sylvestre] from comment #13)
> As 38 is going to be an ESR release, can we postpone that change for 39? The
> merge is next monday.
> It is a nice feature but I don't see the point of rushing here... Especially
> with a moderate risk.

I'd really like to try it out now. The non-e10s case has barely seen any testing because it's been stuck on nightly. Since it is trivial to revert (by preffing off again), I'd really like to uplift ASAP.
Flags: needinfo?(sledru)
It is too late in the 38 cycle to take a new feature or important change.
Moreover, the 38 release is one of the two major releases that we do now. I would like to avoid "noise" on this release with new features to focus on the one we have...
39 in aurora is just in a few days...
Flags: needinfo?(sledru)
(Assignee)

Comment 16

2 years ago
(In reply to Sylvestre Ledru [:sylvestre] from comment #15)
> It is too late in the 38 cycle to take a new feature or important change.
> Moreover, the 38 release is one of the two major releases that we do now.

You're the release manager so it's your call, however I do protest: The fact that 38 is a "big" release is precisely why it would be really good to take this feature! Performance *is* a feature, and this particular one eliminates 1/2 of our top ten hangs. To me that is something that is worth including in a "big" release.
This is all about risk management. I agree with Sylvestre that this is not the right kind of risk to take late in the aurora cycle for 38.
Attachment #8566383 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
(Assignee)

Updated

2 years ago
Depends on: 1119565
Target Milestone: --- → mozilla39
(Assignee)

Comment 18

2 years ago
Created attachment 8584106 [details] [diff] [review]
Enable asyncInit (r2)

Modified to enable off-nightly only. Carrying forward r+.
Attachment #8566383 - Attachment is obsolete: true
Attachment #8584106 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/28dca8aee584
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED

Comment 20

2 years ago
There are nightly users still testing e10s off. Isn't possible/worthy to detect that e10s is off and enable asyncInit?
Relnoting this for 39. Also tracking for 39.
tracking-firefox39: --- → +
relnote-firefox: ? → 39+
Aaron does this apply to desktop only? Or should I add a release note for mobile too? Thanks.
Flags: needinfo?(aklotz)
(Assignee)

Comment 23

2 years ago
Desktop only.
Flags: needinfo?(aklotz)
(Assignee)

Updated

2 years ago
Depends on: 1149358
(Assignee)

Updated

2 years ago
Depends on: 1152395
(Assignee)

Updated

2 years ago
Depends on: 1151804
(Assignee)

Updated

2 years ago
Depends on: 1153173
(Assignee)

Updated

2 years ago
Depends on: 1156903
(Assignee)

Updated

2 years ago
Depends on: 1157237
(Assignee)

Updated

2 years ago
Depends on: 1156800
(Assignee)

Updated

2 years ago
Depends on: 1156861
(Assignee)

Updated

2 years ago
Depends on: 1170231
Depends on: 1170486
Depends on: 1171948
(Assignee)

Updated

2 years ago
Depends on: 1170676
(Assignee)

Comment 24

2 years ago
Created attachment 8621011 [details] [diff] [review]
Patch for disabling by default on beta

(I know it's still awaiting r+ but I hope in this case that Liz will forgive me)

Approval Request Comment
[Feature/regressing bug #]: Async plugin init
[User impact if declined]: Crashes, hangs, and instability. Oh my!
[Describe test coverage new/current, TreeHerder]: Disable configuration is in release and on e10s builds.
[Risks and why]: None, this reverts to existing behavior in release.
[String/UUID change made/needed]: None
Flags: needinfo?(lhenry)
Attachment #8621011 - Flags: review?(vdjeric)
Attachment #8621011 - Flags: approval-mozilla-beta?
Attachment #8621011 - Flags: review?(vdjeric) → review+
Comment on attachment 8621011 [details] [diff] [review]
Patch for disabling by default on beta

Approved for uplift to beta. :)
Flags: needinfo?(lhenry)
Attachment #8621011 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
https://hg.mozilla.org/releases/mozilla-beta/rev/534a78bbabb4
status-firefox39: fixed → disabled
status-firefox40: --- → fixed
status-firefox41: --- → fixed

Updated

2 years ago
Depends on: 1173879

Updated

2 years ago
Depends on: 1187724
(Assignee)

Updated

2 years ago
No longer depends on: 1187724
Looks like there are some site compatibility issues due to this async initialization. I have added compatibility note for developers:

https://developer.mozilla.org/en-US/Firefox/Releases/40/Site_Compatibility#Plug-ins
Keywords: dev-doc-complete, site-compat
(Assignee)

Comment 28

2 years ago
(In reply to Kohei Yoshino [:kohei] from comment #27)
> Looks like there are some site compatibility issues due to this async
> initialization. I have added compatibility note for developers:
> 
> https://developer.mozilla.org/en-US/Firefox/Releases/40/
> Site_Compatibility#Plug-ins

Do you have any examples? If there are some issues then we need to file some bugs so I can look at them!
Bug 1121011, a dependency of this bug, may be an example. A Flash-based Japanese online stock trading system is also broken, but it's not reported yet.
(Assignee)

Comment 30

2 years ago
(In reply to Kohei Yoshino [:kohei] from comment #29)
> Bug 1121011, a dependency of this bug, may be an example. A Flash-based
> Japanese online stock trading system is also broken, but it's not reported
> yet.

I can't reproduce bug 1121011. A bug report for the latter issue would be nice.

Updated

2 years ago
Depends on: 1194488

Comment 31

2 years ago
See bug 1194833 for reproduction case where this breaks any video using Google's Flash-IMA toolkit for ads. Ads and video playback are both broken.

Updated

2 years ago
Depends on: 1194833
(Assignee)

Updated

2 years ago
Depends on: 1194600

Updated

2 years ago
Depends on: 1194958

Comment 32

2 years ago
I don't understand why you enabled API in FF40, it's clearly still bugged, I triaged 3 or 4 new bugs about Flash apps failling to load, even famous apps like FarmVille 2 on Facebook.

IMHO, API should be disabled in a chemspill release until these bugs are fixed.

Updated

2 years ago
Depends on: 1193393

Updated

2 years ago
Depends on: 1194778
[Tracking Requested - why for this release]: This breaks various Flash content in Firefox 40, including video players, games, online stock trading system. I know 40.0.2 is already out, but this might be another chemspill driver. The risk should be pretty low, just change the dom.ipc.plugins.asyncInit pref to false as before.
tracking-firefox40: --- → ?

Comment 34

2 years ago
This is affecting all the players on Farmville 2 on Firefox, can we please release an urgent fix for this?
https://bugzilla.mozilla.org/show_bug.cgi?id=1194958
We need a back-out patch then.
Flags: needinfo?(aklotz)

Comment 36

2 years ago
(In reply to Loic from comment #32)
> I don't understand why you enabled API in FF40, it's clearly still bugged, I
> triaged 3 or 4 new bugs about Flash apps failling to load, even famous apps
> like FarmVille 2 on Facebook.

I can easily tell you why: Nobody - yes, nobody at all - reported any issues with it while it was on Firefox 40 Beta, and everything that was tested by our QA engineers worked as well. So it was not "clearly" having issues. That said, it seems like this is one more piece that shows us that too few of the right people are using Beta at this time or those that are may not report their issues.

Comment 37

2 years ago
We don't need a back-out patch. If we decide we need to get this disabled for users, we can and should do this with an add-on hotfix, which does not need an actual point-release.

Updated

2 years ago
Depends on: 1194929

Updated

2 years ago
Depends on: 1193484

Updated

2 years ago
Depends on: 1195140

Comment 38

2 years ago
any plans as to when we would be rolling out the add-on hotfix for this?

Comment 39

2 years ago
duplicate
Any idea as to when we would be rolling out the add-on hotfix for this?

Updated

2 years ago
Depends on: 1195269
(Assignee)

Comment 40

2 years ago
(In reply to Loic from comment #32)
> I don't understand why you enabled API in FF40, it's clearly still bugged, I
> triaged 3 or 4 new bugs about Flash apps failling to load, even famous apps
> like FarmVille 2 on Facebook.

None of these ended up attached to bug 1116806. If these things aren't being reported and/or the right people aren't being notified, then it's very difficult to get this right in time for release.

(In reply to Kohei Yoshino [:kohei] from comment #35)
> We need a back-out patch then.

As KaiRo indicated, we'll do this via hotfix addon if necessary. I will be engaging with the appropriate parties to come to a decision on this.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #36)
> (In reply to Loic from comment #32)
> > I don't understand why you enabled API in FF40, it's clearly still bugged, I
> > triaged 3 or 4 new bugs about Flash apps failling to load, even famous apps
> > like FarmVille 2 on Facebook.
> 
> I can easily tell you why: Nobody - yes, nobody at all - reported any issues
> with it while it was on Firefox 40 Beta, and everything that was tested by
> our QA engineers worked as well. So it was not "clearly" having issues. That
> said, it seems like this is one more piece that shows us that too few of the
> right people are using Beta at this time or those that are may not report
> their issues.

+1.
(Assignee)

Updated

2 years ago
Flags: needinfo?(aklotz)

Comment 41

2 years ago
This is affecting our plugin as well in 40+. I had to disable dom.ipc.plugins.asyncInit. Is there guidance on what not to do from the plugin side to avoid the problem?
(In reply to akorchemniy from comment #41)
> This is affecting our plugin as well in 40+. I had to disable
> dom.ipc.plugins.asyncInit. Is there guidance on what not to do from the
> plugin side to avoid the problem?

Is this the affect plugin? http://downloads.asperasoft.com/connect2/
How can we reproduce the issue?

Aaron, can you take a look?
Flags: needinfo?(akorchemniy)
Flags: needinfo?(aklotz)

Comment 43

2 years ago
1. Install Connect from http://downloads.asperasoft.com/connect2
2. Login https://faspex.com 
3. mozilla / Mozilla1!
4. Visit the "New Package" page to repro hang
Flags: needinfo?(akorchemniy)
(Assignee)

Updated

2 years ago
Depends on: 1195607
(Assignee)

Updated

2 years ago
No longer depends on: 1193393
(Assignee)

Updated

2 years ago
No longer depends on: 1193484
(Assignee)

Updated

2 years ago
No longer depends on: 1194488
(Assignee)

Updated

2 years ago
No longer depends on: 1194600
(Assignee)

Updated

2 years ago
No longer depends on: 1194778
(Assignee)

Updated

2 years ago
No longer depends on: 1194833
(Assignee)

Updated

2 years ago
No longer depends on: 1194929
(Assignee)

Updated

2 years ago
No longer depends on: 1194958
(Assignee)

Updated

2 years ago
No longer depends on: 1195140
(Assignee)

Updated

2 years ago
No longer depends on: 1195269
(Assignee)

Comment 44

2 years ago
(In reply to akorchemniy from comment #41)
> This is affecting our plugin as well in 40+. I had to disable
> dom.ipc.plugins.asyncInit. Is there guidance on what not to do from the
> plugin side to avoid the problem?

I filed bug 1195609 to track your bug. Async plugin init is supposed to work seamlessly with existing plugins without modification, provided that the plugins are correctly abiding by the API contract. In particular, make sure that your plugin is checking return codes from NPN functions.

Other than that, we're probably going to push a hotfix to disable the feature while the compatibility issues are being ironed out.
Flags: needinfo?(aklotz)
Not tracking this bug as it is about letting the feature riding the train.
We should have a new bug. For now, tracking bug 1195609
tracking-firefox40: ? → -

Comment 46

2 years ago
Hi all, thanks for looking into this, do we have any plans as to when the hotfix would be rolled out?
Blocks: 1195761
No longer blocks: 1195761
Depends on: 1195761
(In reply to sspn from comment #46)
> Hi all, thanks for looking into this, do we have any plans as to when the
> hotfix would be rolled out?

The hotfix will be in bug 1196000.
(Assignee)

Updated

2 years ago
No longer depends on: 1195761

Comment 48

2 years ago
For reference: This also breaks Oracle Enterprise Manager 11g Database Control.
(Assignee)

Updated

2 years ago
Depends on: 1200698
Depends on: 1203517
See Also: → bug 1204036
You need to log in before you can comment on or make changes to this bug.