1117398 - Spotify Web Player crashes with Async Init enabled

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Eric Fowler]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150103030215

Steps to reproduce:

I have e10s enabled and my current build is:
Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20150103030215 CSet: 57e4e9c33bef

With the new setting of dom.ipc.plugins.asyncInit set to true, going to this page:
https://play.spotify.com/browse
as an already logged in user causes the browser to crash.


Actual results:

Here is the crash report from when loading: https://play.spotify.com/browse

https://crash-stats.mozilla.com/report/index/7abf9a76-bba4-4bc7-a3d3-54cc02150103


Expected results:

The page will load without crashing, with no audio playing.

Comment 1

[Eric Fowler]

Still occurring today with e10s enabled:
Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20150109030224 CSet: b3f84cf78dc2

But I did notice that with e10s disabled the crash doesn't occur with Async Init enabled, just fyi.

Comment 2

[(No longer employed by Mozilla) Aaron Klotz]

Thanks for the URL, Eric. I'm currently testing a fix.
(I must have written that code while I was sick with the flu!)

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Clean up handling of plugin entry points on Linux

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

Comment on attachment 8548432 [details] [diff] [review]
Clean up handling of plugin entry points on Linux

This patch fixes and reorganizes some stuff in the linux NP_Initialize.

I also removed some instances of NS_PLUGIN_INIT_PENDING when it was inappropriate to return that value. NS_PLUGIN_INIT_PENDING is really meant only for NPP_New, not NP_Initialize.

I also renamed mAsyncInitPluginFuncs to mNPPIface since it must now be used in some sync init places as well.

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

https://hg.mozilla.org/integration/mozilla-inbound/rev/590d6f515541

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/590d6f515541

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

Comment on attachment 8548432 [details] [diff] [review]
Clean up handling of plugin entry points on Linux

Approval Request Comment
[Feature/regressing bug #]: asynchronous plugin initialization
[User impact if declined]: feature won't be testable with aurora on linux
[Describe test coverage new/current, TBPL]: on m-c, plugin tests also pass with asyncInit activated on try
[Risks and why]: Low, changes are limited in scope and have been tested under both sync and async configurations
[String/UUID change made/needed]: None

Comment 8

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8548432 [details] [diff] [review]
Clean up handling of plugin entry points on Linux

Approving to get asyncInit testing on Linux on Aurora and to keep our options open wrt shipping this feature. Aurora+

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/c74b831b8c04

Comment 10

[Ryan]

Seems to be back 

https://bugzilla.mozilla.org/show_bug.cgi?id=1128255


https://crash-stats.mozilla.com/report/index/0411598b-fade-47a4-8e2a-0c15b2150219

https://crash-stats.mozilla.com/report/index/92779ab1-0f05-4cf9-b905-7b5e82150212

Comment 11

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Ryan from comment #10)
> Seems to be back 
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1128255
> 
> 
> https://crash-stats.mozilla.com/report/index/0411598b-fade-47a4-8e2a-
> 0c15b2150219
> 
> https://crash-stats.mozilla.com/report/index/92779ab1-0f05-4cf9-b905-
> 7b5e82150212

Same signature but a different bug.