Closed Bug 1117398 Opened 10 years ago Closed 10 years ago

Spotify Web Player crashes with Async Init enabled

Categories

(Core Graveyard :: Plug-ins, defect)

37 Branch
x86_64
Linux
defect
Not set
normal

Tracking

(firefox36 unaffected, firefox37 fixed, firefox38 fixed)

RESOLVED FIXED
mozilla38
Tracking Status
firefox36 --- unaffected
firefox37 --- fixed
firefox38 --- fixed

People

(Reporter: hroo772, Assigned: bugzilla)

References

()

Details

Crash Data

Attachments

(1 file)

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.
Crash Signature: https://crash-stats.mozilla.com/report/index/7abf9a76-bba4-4bc7-a3d3-54cc02150103
Crash Signature: https://crash-stats.mozilla.com/report/index/7abf9a76-bba4-4bc7-a3d3-54cc02150103 → [@ mozilla::Monitor::Lock() ]
Flags: needinfo?(aklotz)
Assignee: nobody → aklotz
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(aklotz)
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.
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 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.
Attachment #8548432 - Flags: review?(jmathies)
Attachment #8548432 - Flags: review?(jmathies) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
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
Attachment #8548432 - Flags: approval-mozilla-aurora?
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+
Attachment #8548432 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: