LastPass is a featured add-on for managing passwords https://addons.mozilla.org/en-US/firefox/addon/lastpass-password-manager/ When logging in to a website there should be prompt to save the password, instead nothing happens. When accessing a website with saved log-in credentials there should be a prompt to fill the fields, instead nothing happens. Using the option to fill a registration form with stored data doesn't work (should work on any URL).

I am able to reproduce the problem on Win 7 x64 with latest Firefox 32 Nightly - Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:32.0) Gecko/20100101 Firefox/32.0 - BuildID: 20140605030202. To reproduce this I installed the add-on, created an account and activated it, then tried what Jake suggested on Yahoo: - first login - no prompt to save the password appeared - next login - no options to fill the fields with saved credentials - registration - no options to fill the fields with saved credentials.

This has absolutely nothing to do with plugins. Florin please triage more carefully.

I'm unable to reproduce; LastPass is working fine in conjunction with yahoo.com in Firefox 32 for me. Regardless, this isn't really the best place to report LastPass issues. Feel free to file a support ticket at: https://lastpass.com/supportticket.php

Have you tried it in an e10s window? Not working for me. This should be the right place, it's also listed on http://arewee10syet.com/

Ahh, I was unaware of what e10s meant until you used it in context. Yes, it's definitely expected that LastPass isn't compatible with electrolysis. Making it compatible would be quite a large undertaking. Does electrolysis have a renewed timeline? I'm sure thousands of other extensions are in the same boat.

I just tested out LastPass with e10s enabled in the latest Nightly (Built from https://hg.mozilla.org/mozilla-central/rev/3be45b58fc47) and LastPass was working correctly (dirty profile). Can anyone verify this behavior?

The behavior has definitely improved, but it's not fully working yet. It seems to detect webpages properly, clicking the fill option in the menu works and if you enter new credentials the infobar for saving them appears. The data is saved correctly even though the browser hangs for some time when the entry is saved or deleted. Filling registration forms doesn't work and it did not add the autofill icons to the input fields. Clicking on an saved entry should open the login webpage, fill the inputs and submit the credentials, that caused my tab to crash. https://crash-stats.mozilla.com/report/index/5c7f0fcf-7553-4ba4-b4d1-24cf12140828 Great improvements, the add-on is actually usable now, but it still needs some fixing.

I am not able to get LastPass to work consistently on sites. Sites that did work only did so after refreshing the page several time or using the LastPass option of "Recheck Page". about:buildconfig Build Machine B-2008-IX-0087 Source Built from https://hg.mozilla.org/mozilla-central/rev/98ea98c8191a Build platform target x86_64-pc-mingw32 Build tools Compiler Version Compiler flags cl 1600 -TC -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -wd4244 -wd4819 -we4553 cl 1600 -TP -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -wd4251 -wd4244 -wd4345 -wd4351 -wd4482 -wd4800 -wd4819 -we4553 -GR- -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -O1 -Oi -Oy- Configure arguments --target=x86_64-pc-mingw32 --host=x86_64-pc-mingw32 --enable-crashreporter --enable-release --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --with-google-api-keyfile=/c/builds/gapi.data --enable-signmar --enable-profiling --enable-js-diagnostics

I just tried it with trunk nightly (204996:49fc0135c256) built with trunk clang-3.6 on OSX 10.9.4. It's not detecting input forms correctly. When I tried to autofill the form (via the right click menu) I got the follow output in terminal and the browser just hangs: ###!!! [MessageChannel][Child][/Users/adm/Documents/Sources/FirefoxNightly/ipc/glue/MessageChannel.cpp:626] Assertion (!DispatchingUrgentMessage()) failed. sync messages forbidden while handling urgent message MessageChannel 'backtrace': [(0) in async ???(actor=-4) ] [(1) out sync PBrowser::Msg_GetInputContext(actor=4) ] remote Interrupt stack guess: 0 deferred stack size: 0 out-of-turn Interrupt replies stack size: 0 Pending queue size: 0, front to back: [Child 34386] ###!!! ABORT: sync messages forbidden while handling urgent message: file /Users/adm/Documents/Sources/FirefoxNightly/ipc/glue/MessageChannel.cpp, line 1826 Buildconfig: --enable-optimize --enable-strip --enable-strip-libs --enable-install-strip -q --enable-macox-target=10.9 --with-macos-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk --enable-llvm-hacks --enable-jemalloc --enable-skia --enable-chrome-format=jar --enable-replace-malloc --with-gcc-arch=native --enable-ctypes --enable-bundled-fonts --disable-tests --disable-debug-symbols --disable-debug

(In reply to Andrew Zitnay from comment #5) > Ahh, I was unaware of what e10s meant until you used it in context. > > Yes, it's definitely expected that LastPass isn't compatible with > electrolysis. Making it compatible would be quite a large undertaking. > > Does electrolysis have a renewed timeline? I'm sure thousands of other > extensions are in the same boat. It does. The plan is to flip it on on Nightly very soon (possibly next week). It looks like there is a CPOW + synchronous message passing in comment 9, which aborts the content child process. Since Bug 1054094 - [e10s] LastPass addon calls dispatchEvent directly, causing assertion (!mozilla::ipc::ProcessingUrgentMessages()) and crash in mozilla::EventDispatcher::Dispatch has been resolved, this may be fixed as well? Is there any particular function or object that you need access to that I can interpose for you at the border of the addon js compartment?

Is there a timeline for it making it to stable (or at least beta)?

If the higher ups have their way, eoy is not unlikely. juanb: can you run down how this addon is doing on current nightly & grab the console log. The reports above are conflicting so I'd like to get a fix on how this is doing right now to see if there is anything we can do to help Andrew.

Here is the output from mach run with the latest trunk: Process: ./mach run install lastpass quit browser ./mach run login to lastpass navigate to tumblr.com CC= trunk clang 3.6 CXX= Apple clang 6.0 Build config: --enable-optimize --enable-strip --enable-strip-libs --enable-install-strip -q --enable-macox-target=10.9 --with-macos-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk --enable-llvm-hacks --enable-jemalloc --enable-skia --enable-chrome-format=jar --enable-replace-malloc --with-gcc-arch=native --enable-ctypes --enable-bundled-fonts --disable-tests --disable-debug-symbols --disable-debug FirefoxNightly adm$ ./mach run 0:00.13 /Users/adm/Documents/Sources/FirefoxNightly/obj-ff-dbg/dist/Nightly.app/Contents/MacOS/firefox -no-remote -foreground -profile /Users/adm/Documents/Sources/FirefoxNightly/obj-ff-dbg/tmp/scratch_user ###!!! [MessageChannel][Child][/Users/adm/Documents/Sources/FirefoxNightly/ipc/glue/MessageChannel.cpp:626] Assertion (!DispatchingUrgentMessage()) failed. sync messages forbidden while handling urgent message MessageChannel 'backtrace': [(0) in async ???(actor=-4) ] [(1) out sync PBrowser::Msg_GetInputContext(actor=2) ] remote Interrupt stack guess: 0 deferred stack size: 0 out-of-turn Interrupt replies stack size: 0 Pending queue size: 0, front to back: [Child 53315] ###!!! ABORT: sync messages forbidden while handling urgent message: file /Users/adm/Documents/Sources/FirefoxNightly/ipc/glue/MessageChannel.cpp, line 1826 [Child 53315] ###!!! ABORT: sync messages forbidden while handling urgent message: file /Users/adm/Documents/Sources/FirefoxNightly/ipc/glue/MessageChannel.cpp, line 1826 ###!!! [Parent][MessageChannel::SendAndWait] Error: Channel error: cannot send/recv ###!!! [Parent][OnMaybeDequeueOne] Error: Channel error: cannot send/recv ###!!! [Parent][OnMaybeDequeueOne] Error: Channel error: cannot send/recv ###!!! [Parent][OnMaybeDequeueOne] Error: Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv Here's the output from the browser console: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create Preferences.jsm:381 Could not read chrome manifest 'file:///Users/adm/Documents/Sources/FirefoxNightly/obj-ff-dbg/dist/Nightly.app/Contents/MacOS/browser/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/chrome.manifest'. While creating services from category 'profile-after-change', could not create service for entry 'MobileConnection Service', contract ID '@mozilla.org/mobileconnection/mobileconnectionservice;1' OpenGL compositor Initialized Succesfully. Version: 2.1 NVIDIA-8.26.26 310.40.45f01 Vendor: NVIDIA Corporation Renderer: NVIDIA GeForce GT 755M OpenGL Engine FBO Texture Target: TEXTURE_2D SyntaxError: An invalid or illegal string was specified 1410966702964 Services.HealthReport.HealthReporter WARN Saved state file does not exist. 1410966702964 Services.HealthReport.HealthReporter WARN No prefs data found. OpenGL compositor Initialized Succesfully. Version: 2.1 NVIDIA-8.26.26 310.40.45f01 Vendor: NVIDIA Corporation Renderer: NVIDIA GeForce GT 755M OpenGL Engine FBO Texture Target: TEXTURE_2D NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] FileUtils.jsm:63 NS_ERROR_UNEXPECTED: Unexpected error multiprocessShims.js:80 Handler function threw an exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMessageSender.sendAsyncMessage]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js :: DebuggerServer.connectToChild/onMessageManagerDisconnect< :: line 607" data: no] Stack: DebuggerServer.connectToChild/onMessageManagerDisconnect<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:607:10 makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:13 updateBrowserRemoteness@chrome://browser/content/tabbrowser.xml:1456:12 updateBrowserRemotenessByURL@chrome://browser/content/tabbrowser.xml:1482:19 onxbloop-browser-crashed@chrome://browser/content/tabbrowser.xml:3446:10 Line: 607, column: 0 DevToolsUtils.js:59

You're using a cpow somewhere that causes a sync message (forbidden). hmm Sam, does your addon hook into dev tools? I see the debugger server in your stack Bill, what do you make of "NS_ERROR_UNEXPECTED: Unexpected error multiprocessShims.js:80" & the devtools output? Does this look like a problem that your new messaging system will handle gracefully?

Bug 1049879, along with some fixes for IME messages, will fix the crash. I'm not sure what's up with the rest, but we can figure that out when the crash is fixed.

Allison, I'm just using the lastpass extension that shows up when searching for "lastpass" in the addons page. I'm unsure about any hooks or anything like that, I was mostly just trying to provide the data you requested in comment 12.

(In reply to Sam N from comment #16) > Allison, > > I'm just using the lastpass extension that shows up when searching for > "lastpass" in the addons page. I'm unsure about any hooks or anything like > that, I was mostly just trying to provide the data you requested in comment > 12. It's okay, what you have provided is very helpful & I appreciate it. We'll wait to see what happens after billm's rejiggering of the ipc has fixed the crash. Again, thank you for the help.

Adding "dogfood" keyword so this bug shows up on the e10s wiki's list of known issues: https://wiki.mozilla.org/Electrolysis#Known_Issues

It seems that the needed information was provided, so removing "qawanted" for now.

Bug 1049879 has now been fixed, so how are things looking here? I can't use e10s at all until LastPass is working correctly, and I think it's the same for anyone using this add-on to manage their passwords, so if we're planning to turn e10s on by default in Nightly soon I think this should be prioritized. Note there's also bug 1065110, which implicates IME (but perhaps the crashes there were also fixed by bug 1049879).

Most of the work has been done to fix the crashes, but we still have to do some IME-specific stuff. I'm hoping that will happen in bug 1056018.

I opened up a ticket with LastPass inquiring when they will have support for e10s. Only on a beta build of Fx will they begin to work on it I was told.

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #20) > Bug 1049879 has now been fixed, so how are things looking here? I can't use > e10s at all until LastPass is working correctly, and I think it's the same > for anyone using this add-on to manage their passwords, so if we're planning > to turn e10s on by default in Nightly soon I think this should be > prioritized. Note there's also bug 1065110, which implicates IME (but > perhaps the crashes there were also fixed by bug 1049879). I also cannot test e10s without lastpass so again hope this can be made a top priority for e10s so we can get more testing sooner than later.

Latest nightly, when opening lastpass I get a crash every single time when typing a password.

Can someone please post steps to reproduce? I tried a simple test case with LastPass and it seems to work fine now. Michal, can you post a link to a crashdump?

Note that performance is still very poor. We're aware of that and have plans to fix it. But I want to know whether the add-on is working at all first.

(In reply to Bill McCloskey (:billm) from comment #25) > Can someone please post steps to reproduce? I tried a simple test case with > LastPass and it seems to work fine now. > > Michal, can you post a link to a crashdump? It seems to be resolved in Nightly (20141112030202) however what Michal was experiencing two days ago has happened to me everytime I tried so I do not know if something changed on our side or their side but it works now albeit the performance is slow.

(In reply to Bill McCloskey (:billm) from comment #26) > Note that performance is still very poor. We're aware of that and have plans > to fix it. But I want to know whether the add-on is working at all first. I take that back after enabling e10s it restarting and then closing browser and opening the behavior of crashing is here: https://crash-stats.mozilla.com/report/index/16f3c09a-6893-485e-bc69-fc0712141113

Seems this is related to Bug #893973

That sounds like a Mac-specific issue. I can look into it. Can someone using LastPass on Windows or Linux test it out and see if it works? If it doesn't work, can you please list the steps to reproduce the incorrect behavior?

Masayuki, please see comment 28. This might be a way to reproduce bug 893973 if you're interested.

If it's caused by e10s, not bug 893973. It must be bug 1051842.

Let me give you my results when using LastPass. 1. Using the option to run an e10 window, LP doesn't fill in anything or even know that a site has a LP password. I thought opening e10s in a new window was fixed so it works like number 2 below. 2. Using the option to enable e10s from Fx startup LP is working. I do get a tab crash sometimes on a site that uses LP but found that if I click on the link again I get to the site.

Let me add I run with the latest tinderbox-builds/mozilla-inbound-win64-pgo/.

(In reply to Gary [:streetwolf] from comment #33) > 2. Using the option to enable e10s from Fx startup LP is working. I do get > a tab crash sometimes on a site that uses LP but found that if I click on > the link again I get to the site. Can you give more specific instructions? I've never used LastPass before. What does "a site that uses LP" mean? A site that has a password form field that LP tries to fill in? Or is there some way that LP integrates with specific web sites?

What does "a site that uses LP" By this I mean if you bring up the LP menu either via the icon on the toolbar or the right-click context menu it will show the name of site if it is setup to use LP. From here you have options like editing the LP entry for the site and lots of other stuff. When I run e10s as a new window from a non-e10 window I don't see this which makes sense because LP doesn't know the site uses LP. As I said running e10s as a new window was supposed to be fixed so it runs the same way if I enable the option to run e10s as the default. If people are running e10s in a new window then some add-ons won't work, as in the case of LP. I'm curious why LP is even working now? There was no change to the LP add-on. Seems some patch fixed LP except for the tab crashes I occasionally get.

I don't have any crashes with e10 and recent nightly. I'll test again in a few seconds. That's on OS X 10.10. Opening a new window as e10 while the browser has e10 disabled globally - no problem, everything is fine (e10 is terribly slow, but I hope that's known).

I find LP very usable now under e10s as long as Fx is defaulted to e10s. Yes, I get tab crashes once in awhile going to a site that uses LP to fill in my login/form info but as I said clicking on the sites bookmark get's it working again. btw.. the crash doesn't bring down Fx, I just get a message it crashed. The button to try again doesn't do anything.

Gary, are you on a Mac? Could you post a link to some of the crash dumps? We have a bunch of shims that try to make add-ons work with e10s even if they haven't been specifically written to do so. That's why LP works as well as it does.

OS X 10.10 recent nightly, just updated - 36.0a1 (2014-11-13). Opened Nigthly with e10 enabled globaly. Loaded a few web pages in two-three tabs, total of three windows. Nothing special, things like CNN, BBC, etc. Logged off the LP. Closed browser. Started browser again, tabs were restored, LP icon "gray" - logged off. Clicked on the icon and started typing password (rapidly). Got a crash of entire browser. Sent report using crash reporter (how do I get a link to give it to you?).

If you go to about:crashes, you'll see a list of links to crash reports.

I've restarted Nightly, waited for it to load all tabs, waited some more, clicked on LP icon, wait, clicked in the password input field, wait, started typing password, no crash.

https://crash-stats.mozilla.com/report/index/47004a85-d04b-4739-b2da-127802141113 On inbound don't think there is any debug info.

https://crash-stats.mozilla.com/report/index/a1c022a6-70b3-4d87-8b58-45d3e2141113 https://crash-stats.mozilla.com/report/index/48fa7324-ce6d-4f1f-8e47-93faa2141113

Hm, I don't miss auto-filling, and I don't think I've been crashing, so LastPass has been mostly usable in e10s-by-default-Nightly for a while. However, I am now having problems seeing my LastPass vault in my (default) e10s window. I launched a non-e10s window and the vault came up. That's a workaround, but I'd love to see it working. Not sure if we want a new bug or keep it in the e10s LastPass bug. I'm using OSX 10.9.5, Firefox Nightly 36.0a1 (2014-11-13), but I think I saw the same vault behavior in 2014-11-06.

I started out with a new profile and gradually added back all my add-ons. LastPass while itself appears to be working so far has the nasty habit of hanging/crashing Flash videos. Not all the time but most of the time. A site where I always seem to hang/crash is cnn.com. Not the video on the upper left for some reason but any of the others.

I just disabled my other enabled add-on (which was, funny enough, the Firefox Interest Dashboard) such that I now only have LastPass enabled, and I restarted. LastPass now seems to be filling in login forms again; however, the vault will not open, just a blank tab.

The vault doesn't open for me on startup. Maybe I mentioned this before but running an e10 window from a non-e10 window does not behave the same as enabling e10s via the Options menu. For example... LP won't fill in forms in an e10 window but will if I enable e10s as the default.

Also, I'm getting a fair bit of random beach balling again, which went away when LastPass wasn't working for me. So it seems clear that LastPass is somehow causing lots of short periods of unresponsiveness.

Thanks. I feel like I now have a good understanding of all the things that are going wrong now. Bug 1093693 will probably fix the Flash issue. Bug 1082849 is intended to address the general slowness with LastPass. I'll post a patch for the vault issue here. It looks like an easy fix.

Thanks much Bill. You seem to be really on top of things. Great job!

The add-on Configuration Mania was just updated to support e10s. While CM now works it also stops LastPass from filling in forms and other things. Basically LP now acts as it did in my previous posts. Disabling CM gets LP working again. Is this fixed by one of the patches you mentioned above or perhaps another one? I'll let the developer of CM know of the problem.

For me on OSX: * Login fields *are* filled correctly. * But "*" icon on the fields (where I can select from multiple accts etc) doesn't. * Main toolbar dropdown *does* work and many things work fine. * But attempting to open my vault shows chrome://lastpass/content/home2.xul as a blank tab.

I've disabled LastPass addon and enabled e10. Boy, Nightly with e10 is crazy fast now! No spinning ball of death anymore. This is on OS 10.10, recent Nightly, etc. If you want me to provide more debug info, let me know. TL;DR LastPass enabled in Nightly kills the performance.

I would also be able to provide debugging info for OSX, if given instructions on what to gather and approximately how to do it.

Adding "e10s-lastpass" alias for this bug.

The developer has been notified through AMO.

Today I'm seeing a crash when trying to sign in to lastpass with e10s enabled (no crash in a non-e10s window). Here's an example: https://crash-stats.mozilla.com/report/index/8e561100-f04b-4dee-b08c-f646e2141119 Per comment 29, the app notes for the crash mention: > Bug 893973: A password editor has focus, but not in secure input mode

Regarding timeline, I think I read somewhere that while Firefox 36 Nightly has e10s enabled, it won't be enabled in Firefox 36 Aurora and beyond. Is that correct? If so, how likely is it that it'll be enabled in Firefox 37 Aurora and beyond? If my calculations are correct, Firefox 37 will hit beta on February 23, 2015, and stable on April 6, 2015. How likely is it that e10s will make it stable by then? Regarding issues, I'm counting 4 main issues that people are currently having: 1) The vault is broken, because it's a XUL page that we attempt to load in a tab. I seem to be able to fix this by registering an about: URL and loading that page instead. However, it appears Bill is working on a patch as well. Should I bother fixing it on the LastPass side? 2) Field icons are broken. In the error log, I'm seeing "Unable to run script because scripts are blocked internally." I don't see this in non-e10s. Does anyone know what it means? 3) People are seeing some crashes. Am I correct that most if not all these crashes are Mozilla's to fix? 4) We're currently accessing web content synchronously, and are thus relying on multiprocess shims to remain compatible. It seems that some people are reporting slowdown issues (which I'm personally not seeing). It sounds like these shims be optimized. Will these optimizations be enough for now? Also, it's my understanding that they'll eventually be removed from Firefox. What's the timeline on that? I'm trying to get a better handle on whether or not we'll be able to rely on them for a while, since this is by far the biggest hurdle in making LastPass fully e10s-compatible (we access web content synchronously in hundreds if not thousands of places). It would take many, many hours to rearchitect. Am I missing any other issues? I've also considered another option which I assume would make us fully e10s-compatible: migrating to the add-on SDK. This wouldn't be a decision we make lightly, since it would completely change the extension's look and feel (no more XUL, etc). However, there would be significant benefits as well, including full e10s-compatibility. I've come up with some questions surrounding it: 1) Is the add-on SDK fully stable at this point? 2) How difficult is it to augment/modify a Google Chrome extension to be compatible with the Firefox add-on SDK? That's what we did with Safari when Apple first released the Safari extension API, and it was relatively painless, so that's the path I could see going down. 3) Can add-on SDK extensions still use js-ctypes (or another method) to access native code?

One other question about the add-on SDK that I thought of: 4) If we develop and add-on SDK extension, and want people to upgrade from our XUL extension to it, is there a clean upgrade path, or will it require manual intervention from the user?

(In reply to Andrew Zitnay from comment #59) > Regarding timeline, I think I read somewhere that while Firefox 36 Nightly > has e10s enabled, it won't be enabled in Firefox 36 Aurora and beyond. Is > that correct? If so, how likely is it that it'll be enabled in Firefox 37 > Aurora and beyond? If my calculations are correct, Firefox 37 will hit beta > on February 23, 2015, and stable on April 6, 2015. How likely is it that > e10s will make it stable by then? > > Regarding issues, I'm counting 4 main issues that people are currently > having: > > 1) The vault is broken, because it's a XUL page that we attempt to load in a > tab. I seem to be able to fix this by registering an about: URL and loading > that page instead. However, it appears Bill is working on a patch as well. > Should I bother fixing it on the LastPass side? Not sure where Bill is working on this part but I'm seeing if we should make chrome: pages run in the main process after all in bug 1098808 > 3) People are seeing some crashes. Am I correct that most if not all these > crashes are Mozilla's to fix? Yes, but there are good chances that they will be fixed by breaking whatever behaviour is causing them, so you still may need to solve whatever your add-on is doing that is causing the crashing. > 4) We're currently accessing web content synchronously, and are thus relying > on multiprocess shims to remain compatible. It seems that some people are > reporting slowdown issues (which I'm personally not seeing). It sounds like > these shims be optimized. Will these optimizations be enough for now? > Also, it's my understanding that they'll eventually be removed from Firefox. > What's the timeline on that? I'm trying to get a better handle on whether > or not we'll be able to rely on them for a while, since this is by far the > biggest hurdle in making LastPass fully e10s-compatible (we access web > content synchronously in hundreds if not thousands of places). It would > take many, many hours to rearchitect. We can optimise to a point, beyond there they will just be slow so avoiding them entirely is your best best for a fast stable add-on, and as you mention we plan to deprecate at some point. I don't think we have a specific timeline for this, it will be at least a few releases after e10s makes it out the door and will depend on the number of add-ons making use of them at that time.

I went ahead and fixed the vault issue. If anyone wants to try it, the fix is in our latest pre-build: https://rodan.lastpass.com/dlpre/ If anyone has any insight into my other questions, please let me know.

A temporary work around for those who want both LastPass and e10 working fast. Does not cover all the cases but works most of the time. https://helpdesk.lastpass.com/features/bookmarklets/

I've started looking into why the field icon popups aren't working. It appears to boil down to this code: var xhrObserver = { observe: function(request, topic, data) { request = request.QueryInterface(Ci.nsIHttpChannel); var interfaceRequestor = request.notificationCallbacks.QueryInterface(Components.interfaces.nsIInterfaceRequestor); var DOMWindow = interfaceRequestor.getInterface(Components.interfaces.nsIDOMWindow); } } var observ = Cc["@mozilla.org/observer-service;1"].getService(Ci.nsIObserverService); observ.addObserver(xhrObserver, "http-on-modify-request", false); The code works fine in non-e10s, but in e10s, the call to interfaceRequestor.getInterface() throws the following exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: file:///C:/Users/drew/AppData/Roaming/Mozilla/Firefox/Profiles/bhx0sdfi.default/extensions/support@lastpass.com/components/lastpass.js :: LastPassContainer/xhrObserver.observe :: line 4234" data: no] If anyone can make sense of that, or suggest a workaround, I'm all ears.

(In reply to Andrew Zitnay from comment #64) > The code works fine in non-e10s, but in e10s, the call to > interfaceRequestor.getInterface() throws the following exception: > > [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) > [nsIInterfaceRequestor.getInterface]" nsresult: "0x80004002 > (NS_NOINTERFACE)" location: "JS frame :: > file:///C:/Users/drew/AppData/Roaming/Mozilla/Firefox/Profiles/bhx0sdfi. > default/extensions/support@lastpass.com/components/lastpass.js :: > LastPassContainer/xhrObserver.observe :: line 4234" data: no] > > If anyone can make sense of that, or suggest a workaround, I'm all ears. Is that code running in the main process or in a frame script. I'm sure it will fail in the main process, I'd expect it to work in a frame script though.

It's definitely in the main process, since LastPass doesn't have frame scripts yet. Is this simply a case the shims don't cover? If so, will they ever? Are there more cases like this?

(In reply to Andrew Zitnay from comment #66) > It's definitely in the main process, since LastPass doesn't have frame > scripts yet. Is this simply a case the shims don't cover? If so, will they > ever? Are there more cases like this? We've largely wound down our shims effort at this point as it seems like we've hit most of the common cases. I don't know if we'll ever implement this case, Bill might know though.

Hmm, no dice within a frame script either. I added a frame script with: LP.messageManager = Components.classes["@mozilla.org/globalmessagemanager;1"].getService(Components.interfaces.nsIMessageListenerManager); LP.messageManager.loadFrameScript("chrome://lastpass/content/content.js", true); Then tried the same code above within content.js. The same line throws the same exception.

Anyone else crashing immediately after inputting a single character into the addon login password field? Happening to me on both my OSX nightlies, since about the beginning of December. One's Mavericks and the other's Yosemite.

(In reply to Aki Sasaki (not actively reading bugmail) from comment #69) > Anyone else crashing immediately after inputting a single character into the > addon login password field? > Happening to me on both my OSX nightlies, since about the beginning of > December. One's Mavericks and the other's Yosemite. Resolved by installing LastPass 3.x.x from addons.mozilla.org; LastPass 2.x.x was crashing but doesn't show an update.

(In reply to Aki Sasaki (not actively reading bugmail) from comment #70) > (In reply to Aki Sasaki (not actively reading bugmail) from comment #69) > > Anyone else crashing immediately after inputting a single character into the > > addon login password field? > > Happening to me on both my OSX nightlies, since about the beginning of > > December. One's Mavericks and the other's Yosemite. > > Resolved by installing LastPass 3.x.x from addons.mozilla.org; LastPass > 2.x.x was crashing but doesn't show an update. I still get this crash with LastPass 3.1.54

I still get the crash too with the latest 3.x.x LastPass Addon whenever trying to login. In talking with LastPass they definitely think it is on Firefox's side.

Can we split out the LastPass crashing stuff from this bug? And then get some crash stacks into that new bug?

The crashes are almost certainly caused by bug 1051842.

(In reply to Andrew Zitnay from comment #59) > Regarding timeline, I think I read somewhere that while Firefox 36 Nightly > has e10s enabled, it won't be enabled in Firefox 36 Aurora and beyond. Is > that correct? If so, how likely is it that it'll be enabled in Firefox 37 > Aurora and beyond? If my calculations are correct, Firefox 37 will hit beta > on February 23, 2015, and stable on April 6, 2015. How likely is it that > e10s will make it stable by then? We expect e10s will probably ship around the middle of the year. I think Firefox 38 is probably the earliest we could release, and that will be released in mid-May. > Regarding issues, I'm counting 4 main issues that people are currently > having: > > 1) The vault is broken, because it's a XUL page that we attempt to load in a > tab. Thanks for fixing this, > 3) People are seeing some crashes. Am I correct that most if not all these > crashes are Mozilla's to fix? Yes, these crashes are our responsibility. > 4) We're currently accessing web content synchronously, and are thus relying > on multiprocess shims to remain compatible. It seems that some people are > reporting slowdown issues (which I'm personally not seeing). It sounds like > these shims be optimized. Will these optimizations be enough for now? > Also, it's my understanding that they'll eventually be removed from Firefox. > What's the timeline on that? I'm trying to get a better handle on whether > or not we'll be able to rely on them for a while, since this is by far the > biggest hurdle in making LastPass fully e10s-compatible (we access web > content synchronously in hundreds if not thousands of places). It would > take many, many hours to rearchitect. We're trying to make the shims faster, but we can only do so much. The code that iterates over iframes, forms, and <input> fields really needs to be in the content process or else performance will be bad. > I've also considered another option which I assume would make us fully > e10s-compatible: migrating to the add-on SDK. This wouldn't be a decision > we make lightly, since it would completely change the extension's look and > feel (no more XUL, etc). However, there would be significant benefits as > well, including full e10s-compatibility. I've come up with some questions > surrounding it: It's hard to give advice about this. I don't know enough about the add-on SDK or LastPass to know whether it provides everything LastPass. > 1) Is the add-on SDK fully stable at this point? If you stick to the "high-level APIs" in the SDK, it should be pretty stable and e10s-compatible. Please avoid the low-level APIs, though. Not all of them are e10s-compatible, so they rely on shims. > 2) How difficult is it to augment/modify a Google Chrome extension to be > compatible with the Firefox add-on SDK? That's what we did with Safari when > Apple first released the Safari extension API, and it was relatively > painless, so that's the path I could see going down. The add-on SDK is definitely more similar to the Chrome extension API than the XPCOM/frame script APIs is to the Chrome API. > 3) Can add-on SDK extensions still use js-ctypes (or another method) to > access native code? Not sure what sort of native code you mean, but this should work in the main process. There's a good chance it won't work in the content process. (In reply to Andrew Zitnay from comment #64) > I've started looking into why the field icon popups aren't working. It > appears to boil down to this code: > > var xhrObserver = { > ... > > If anyone can make sense of that, or suggest a workaround, I'm all ears. Unfortunately we don't have any way to get the DOMWindow out of an http-on-modify observer right now. It doesn't work in either process. I filed bug 1108827 to get this fixed.

For the most part LP is filling in forms. However, there are times that doing so results in tab crashes. Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:37.0) Gecko/20100101 Firefox/37.0

Telemetry data indicates that LassPass is throwing a js exception. No file is found attached to the exception, which probably means that loading a particular file throws immediately.

With LP enabled I've been getting tab crashes going to this site: http://windowsmatters.com/2014/05/15/standalone-win8-1update_pe-x64-or-x86-2/ Browser log attached.

As of a few days ago LastPass will crash it's tab if LP is setup to do an auto login for the site. Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:38.0) Gecko/20100101 Firefox/38.0

I can confirm LastPass does not work properly on FireFox Developer Edition 40 with "Enable multi-process Firefox Developer Edition" ticked.

(In reply to joshuabg5000 from comment #80) > I can confirm LastPass does not work properly on FireFox Developer Edition > 40 with "Enable multi-process Firefox Developer Edition" ticked. It would appear that something has major has changed or been broken in the latest Firefox Developer Edition. It's still working relatively well in the latest Nightly, but in the latest Firefox Developer Edition, I don't even see our DOMContentLoaded listener being called. Perhaps someone from Mozilla can advise.

(In reply to Andrew Zitnay from comment #81) > (In reply to joshuabg5000 from comment #80) > > I can confirm LastPass does not work properly on FireFox Developer Edition > > 40 with "Enable multi-process Firefox Developer Edition" ticked. > > It would appear that something has major has changed or been broken in the > latest Firefox Developer Edition. It's still working relatively well in the > latest Nightly, but in the latest Firefox Developer Edition, I don't even > see our DOMContentLoaded listener being called. Perhaps someone from > Mozilla can advise. Hello Andrew - do you see anything suspicious in the Browser Console? (Cmd-Shift-J) gabor - should the event shims be working properly on Aurora?

Some shims are broken unfortunately I have a patch for it that'll land soon in Bug 1164011. It should be related, I'm not sure, I will try it out tomorrow.

I think the Aurora issue is caused by bug 1166886.

I know this may not be the best place to put it, but this is a top search result when searching "lastpass electrolysis" or "lastpass e10s" I contacted LastPass support regarding this and they're response was: > Hello there, > > Thank you for contacting LastPass Support and We do apologize for the inconvenience it may have caused you. > > We are not fully compatible with E10s but you may try this download link https://rodan.lastpass.com/dev/lp_e10s.xpi > > Thank you and have a great day! So users who just want to be able to use LastPass and e10s at the same time can use the development build in that message. Developers, keep up the good work on the shims and everything!

Did something change with regard to sdk/hotkeys in the 2015-05-23 build of Firefox Developer Edition? Loading a simple extension whose main.js only contains: g_ff_hotkeys = require('sdk/hotkeys'); is causing performance issues within certain textareas (the textarea I'm typing this comment into is an example of one). If you hold down a keyboard key, the keystrokes will populate very slowly with such an extension enabled. No interaction with g_ff_hotkeys is necessary, you just need to load it. The 2015-05-22 build doesn't have the problem.

It's also worth noting that the issue only occurs with e10s enabled, and it also occurs on Nightly (although I didn't go through and see which Nightly build it started on).

Unfortunately the SDK still uses add-on shims in some places. We're working to fix this. I just filed bug 1168597 about the hotkeys issue. The reason it only started happening recently is that, until bug 1166886 landed on Aurora, shims were broken on Aurora.

Here's an official e10s pre-build link for LastPass I received today via email. So far it appears to be working fine. https://rodan.lastpass.com/dev/lp_e10s.xpi

Here's the email I received. Hi Prebuild Team, We need your help testing our update to the LastPass extension for Firefox. Our new release will support the changes Firefox is making to its browser architecture, which is promising better overall security, performance, and stability. Get started with our new prebuild by using this download link: https://rodan.lastpass.com/dev/lp_e10s.xpi Your comments and feedback help us immensely. Please send comments and reports to feedback_firefox@lastpass.com. If you encounter bugs, please include your exact steps to reproduce the problem and any additional details about your setup that may help us investigate. More details about Firefox's upcoming changes are available here: https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox. Thanks PreBuild Team! LastPass Dev

I started testing it for few hours on Linux x64 on Nightly and I had to disable it again. How can I determine if the slow downs are from LastPass instead of related to the new nightly? Are there any metrics that I can paste?

W(In reply to Armen Zambrano G. (:armenzg - Toronto) from comment #93) > I started testing it for few hours on Linux x64 on Nightly and I had to > disable it again. > > How can I determine if the slow downs are from LastPass instead of related > to the new nightly? > Are there any metrics that I can paste? Well... You can always disable the addon in question and restart firefox to compare. I did it. It's the LastPass.

Not seeing any slowdown under Windows 8.1. You should run the xpi link I gave periodically as they update LP fairly frequently. I just reinstalled it again and notice the date is newer than a few hours ago. Report any problems to the feedback link I gave in comment 92.

I'm running... Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0

(In reply to Gary [:streetwolf] from comment #95) > Not seeing any slowdown under Windows 8.1. You should run the xpi link I > gave periodically as they update LP fairly frequently. I just reinstalled > it again and notice the date is newer than a few hours ago. > > Report any problems to the feedback link I gave in comment 92. (In reply to Gary [:streetwolf] from comment #96) > I'm running... > > Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0 I'm on Windows 8.1 64bits, too. Try to fill some form which uses to much JS, like facebook. It's almost impossible to write.

It looks like is related to https://bugzilla.mozilla.org/show_bug.cgi?id=1168597

Yeah, I notice that it take a few seconds for logins to be filled whereas before it was almost instantaneous. That's why it's called a pre-build ;-). At least no more tab crashes so far.

As per bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1168597 if you add this line to the LastPass extension's install.rdf file it seems to fix the filling in forms and text field problem. <em:multiprocessCompatible>true</em:multiprocessCompatible> I added this at the end of the first section before where it says <!-- Firefox -->

Well it was working until now. Wonder why it worked when I first added the line.

I think the problem lies in the fact that in the pref 'extensions.bootstrappedAddons' LastPass's multiprocessCompatible entry is being changed to False. I take it that this get's filled in from the install.rdf? As long as multiprocessCompatible is true I have no problem with text. Something is changing it back to False. What can be doing this?

(In reply to Gary [:streetwolf] from comment #102) > I think the problem lies in the fact that in the pref > 'extensions.bootstrappedAddons' LastPass's multiprocessCompatible entry is > being changed to False. I take it that this get's filled in from the > install.rdf? As long as multiprocessCompatible is true I have no problem > with text. Something is changing it back to False. What can be doing this? Please file a bug so we can investigate this

Filed Bug 1172888

I've made a change to https://rodan.lastpass.com/dev/lp_e10s.xpi to stop using sdk/hotkeys if we detect e10s for now. This should work around the slowness. The caveat is that we're forced to fall back to the way we handle hotkeys in Chrome, where they only work if a web page has focus.

Yeah, entering text is now much faster with the new version.

I'm on Firefox Nightly and installed the xpi Andrew posted. It works to bring back functionality but it also breaks Firefox Menu. If you hit the hamburger button it will not open. If I disable LastPass it will open.

(In reply to Luke from comment #107) > I'm on Firefox Nightly and installed the xpi Andrew posted. It works to > bring back functionality but it also breaks Firefox Menu. If you hit the > hamburger button it will not open. If I disable LastPass it will open. I'm unfortunately able to reproduce. Can anyone else?

Did you mean "unable"? The menu works great on my 2 computers (latest nightly, windows 8.1 x64). Maybe there is a conflict with another extension?

ibaquumosh(In reply to annaeus from comment #109) > Did you mean "unable"? > > The menu works great on my 2 computers (latest nightly, windows 8.1 x64). > Maybe there is a conflict with another extension? Do you have multi process enabled? It conflicts when multi process is enabled, can you check in options-general.

I have, on both computers.

(In reply to annaeus from comment #109) > Did you mean "unable"? Yep, oops.

(In reply to Andrew Zitnay from comment #112) > (In reply to annaeus from comment #109) > > Did you mean "unable"? > > Yep, oops. OK I'll try disable all extensions except LastPass and see if the issue is resolved.

I tried with clean install nightly and no issues. Appears to have been a bad install so issue resolved.

Sorry to report but I need to rebut my last post. The issue was resolved for a moment but returns. Sometimes it works and other times it doesn't. You can see that the hamburger button is still clicked-highlighted but the menu wont open. Let me clarify that I am running Nightly on Windows 10 natively. The only way to reproduce this is to open a tab and then open another and clicking the menu button. Now if this a Windows 10 problem" might have to file a bug. The odd thing is if I disable E10 LastPass Extension all is normal, if I also remove E10 LastPass and install the current version and then disable E10 in Nightly all is normal with LastPass and Menu button.

Just for the record: Firefox 41 (aurora), Windows 7 - couldn't reproduce the problem, the LastPass version that Andrew given above works fine here.

(In reply to Luke from comment #115) > Sorry to report but I need to rebut my last post. The issue was resolved for > a moment but returns. Sometimes it works and other times it doesn't. You can > see that the hamburger button is still clicked-highlighted but the menu wont > open. > > Let me clarify that I am running Nightly on Windows 10 natively. The only > way to reproduce this is to open a tab and then open another and clicking > the menu button. Now if this a Windows 10 problem" might have to file a bug. > > The odd thing is if I disable E10 LastPass Extension all is normal, if I > also remove E10 LastPass and install the current version and then disable > E10 in Nightly all is normal with LastPass and Menu button. I'd be curious if anyone else running Windows 10 can reproduce, as I'm not yet running it. Also: - Does it occur if you disable e10s? - Does it occur on Aurora (with or without e10s enabled)? - Are there any errors in the browser console?

I have now tried and failed to reproduce on Windows 10.

(In reply to Andrew Zitnay from comment #118) > I have now tried and failed to reproduce on Windows 10. What version of Firefox are you running on Windows 10?

(In reply to Luke from comment #119) > (In reply to Andrew Zitnay from comment #118) > > I have now tried and failed to reproduce on Windows 10. > > What version of Firefox are you running on Windows 10? Nightly.

LastPass E10 updated itself and now issue is resolved...Thanks!

While I see no slowness, there is still an issue with autofill, and I can consistently crash the browser with it. See bug 1187448

(In reply to Jerod Lycett from comment #122) > While I see no slowness, there is still an issue with autofill, and I can > consistently crash the browser with it. See bug 1187448 Is this with the production version of LastPass, or the e10s build? If the former, try the e10s build: https://rodan.lastpass.com/dev/lp_e10s.xpi

(In reply to Andrew Zitnay from comment #123) > (In reply to Jerod Lycett from comment #122) > > While I see no slowness, there is still an issue with autofill, and I can > > consistently crash the browser with it. See bug 1187448 > > Is this with the production version of LastPass, or the e10s build? If the > former, try the e10s build: > > https://rodan.lastpass.com/dev/lp_e10s.xpi I've tried both. It happens with both. I sent you an email with the support ticket number so you can see that too. The autofill behavior I see is as follows: 1. http://www.dreamincode.net/forums/index.php?app=core&module=global&section=register&coppa_user=&termsread=1&coppa_pass=1&agree_to_terms=1 2. Click on the autofill arrow thing in the Username field. 3. It turns into an x button, but nothing else happens. 4. Repeat with the password generation buttons.

(In reply to Jerod Lycett from comment #124) > The autofill behavior I see is as follows: "me too" - I've been using the e10s version since I first heard it existed and autofill has been almost completely broken for a few months.

Regarding the crashes, they're presumably Mozilla's responsibility to fix. LastPass is nowhere to be found in the backtraces, so at worst we're tickling a bug in Firefox itself. Regarding the field icon popup not showing up, that's definitely expected behavior in the current production version of LastPass with e10s enabled in Firefox (you should still be able to fill from the menus, though). However, they should work fine in the e10s build of LastPass, even with e10s enabled in Firefox. I've just tested, and can't reproduce the problem. So, I'd like to make sure you're actually using the e10s build of LastPass. Can you go to LastPass button -> Tools -> About, and paste what you see there in here?

Andrew: Version: 3.1.95 Built: 2015-07-14 09:43:21 Binary Component: true (ctypes version 3.1.97, built Apr 16 2015 16:01:41)

Still not seeing popup with: Version: 3.2.16 Built: 2015-07-28 11:37:35 Binary Component: true (ctypes version 3.1.97, built Apr 16 2015 16:01:41)

No popup with: Version: 3.2.16 Built: 2015-07-27 10:46:00 Binary Component: true (ctypes version 3.2.11, built Jun 29 2015 09:44:02) FYI, Firefox addons page says I have version 3.2.17a so one of these versions is incorrect. Also seeing "LastPass might be making Nightly run slowly" a lot

Same here: on the mentioned above page, with LastPass 3.2.17a, no popup is shown; only the icon inside the input changes (exactly as described above).

The version number isn't really important. However, if it says "binary component" instead of "fast encryption", then it is indeed the e10s version, and field icon popups should show up. If you disable e10s within Firefox, do field icon popups show up? Do you have any other Firefox extensions enabled? If so, disable them temporarily and see if field icon popups show up. uBlock is one known extension that's causing this right now.

I do have uBlock Origin - it actually seems to be a part of the cause. Once I disabled it in Firefox (clicking the big power button inside uBlock is not sufficient) LastPass started showing the popup - but only in a non-e10s window. If (with uBlock still disabled) I open the same page in a e10s window, the popup doesn't show up.

Tested it in a clean profile. Seems it is a conflict with other addons.

If extensions other than uBlock are causing problems, I'd like to know what they are. If no other extensions are enabled and the problem still occurs, check to see if anything shows up in the browser console.

Is there a version of the e10s lastpass add on that is signed? Firefox just decided to disable it unconditionally. So now I am back to nothing or something that freezes the browser when I use it the wrong way.

I don't know why they decided to enable the signing requirement on Nightly, but you can disable it in about:config by setting xpinstall.signatures.required to false (note, I believe this option does *not* exist on beta or release).

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #137) > I don't know why they decided to enable the signing requirement on Nightly, > but you can disable it in about:config by setting > xpinstall.signatures.required to false (note, I believe this option does > *not* exist on beta or release). This is what they did, you need to set xpinstall.signatures.required to false for the e10s build of LastPass to work.

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #137) > I don't know why they decided to enable the signing requirement on Nightly, > but you can disable it in about:config by setting > xpinstall.signatures.required to false (note, I believe this option does > *not* exist on beta or release). Can confirm this change allows the addon to be used in developer edition again. Once there is a lastpass e10s version signed this should no longer be required. A restart of the browser is needed for the addon to be restored after the about:config change.

(In reply to Andrew Zitnay from comment #131) > uBlock is one known > extension that's causing this right now. Is there any more information on this (eg, a uBlock issue or Firefox bug), or anything I/we can do to help here? I've been wondering why LastPass has been so broken recently even ignoring the e10s issues, and it turns out it was this all along...

(In reply to Mark Hammond [:markh] from comment #140) > (In reply to Andrew Zitnay from comment #131) > > uBlock is one known > > extension that's causing this right now. > > Is there any more information on this (eg, a uBlock issue or Firefox bug), > or anything I/we can do to help here? I've been wondering why LastPass has > been so broken recently even ignoring the e10s issues, and it turns out it > was this all along... There's a thread on uBlock's GitHub page regarding the problem: https://github.com/gorhill/uBlock/issues/443 It seems like a bug in Firefox to me, but it's hard to say for sure. The uBlock developer wasn't very willing to help find a workaround. It's possible that https://bugzilla.mozilla.org/show_bug.cgi?id=1161831 will allow me to work around the problem. I see that it's marked as resolved fixed. Does that mean it's now available, at least in nightly, and if so, is there any documentation on how to use it?

Thanks - I'll see if I can make any sense of that

(In reply to Mark Hammond [:markh] from comment #142) > Thanks - I'll see if I can make any sense of that Any progress on this?

I made some investigations after reproducing the issue and emailed Andrew for some more information on how LastPass is expected to work, and he replied back late last week indicating that while drafting a response he stumbled across a work-around and uploaded a new version. My short testing the most recent version of https://rodan.lastpass.com/dev/lp_e10s.xpi does indeed work fine with uBlock :)

FYI, I traced the freezing in https://bugzilla.mozilla.org/show_bug.cgi?id=1188912 to calling focus() on an input field. It definitely seems like a CPOW bug in Firefox.

You may want to look at https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ specifically this quote: Six months past enabling Electrolysis on Release. The deprecation of CPOWs and compatibility shims will begin. We will release further scheduling information as appropriate, but developers should be aware that any add-ons that depend on them will stop working within six to twelve months of the general availability of Electrolysis. That is planned to be 2015-12-15 for release, June 2016 for beginning, and December 2016 for, will no longer work. So while it may be a CPOW bug, the reliance on CPOWs seems like a bug to me (a user of Lastpass). I'm sure you're working on ways to work around on them, and Web Extension is likely great news for you in this, but you guys seem to just point out where CPOWs aren't working.

(In reply to Mark Hammond [:markh] from comment #144) > I made some investigations after reproducing the issue and emailed Andrew > for some more information on how LastPass is expected to work, and he > replied back late last week indicating that while drafting a response he > stumbled across a work-around and uploaded a new version. My short testing > the most recent version of https://rodan.lastpass.com/dev/lp_e10s.xpi does > indeed work fine with uBlock :) I can confirm it works :D

(In reply to Jerod Lycett from comment #146) > You may want to look at > https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox- > add-ons/ specifically this quote: > > Six months past enabling Electrolysis on Release. The deprecation of CPOWs > and compatibility shims will begin. We will release further scheduling > information as appropriate, but developers should be aware that any add-ons > that depend on them will stop working within six to twelve months of the > general availability of Electrolysis. > > That is planned to be 2015-12-15 for release, June 2016 for beginning, and > December 2016 for, will no longer work. > > So while it may be a CPOW bug, the reliance on CPOWs seems like a bug to me > (a user of Lastpass). I'm sure you're working on ways to work around on > them, and Web Extension is likely great news for you in this, but you guys > seem to just point out where CPOWs aren't working. I'm well aware of the CPOW deprecation timeline. LastPass already has a build that doesn't depend on CPOWs at all, linked to many times within this bug. However, I think it's in Mozilla's best interest to look into things that could end up freezing Firefox completely.

For what it's worth, I've been trying the last pass dev xpi listed on this ticket, and while it works, it slows FF to a crawl when rendering new pages or generally doing anything. I'm not sure if it's the extension's fault or Firefox itself, but it's really quickly becomes unusably slow with e10s enabled and this plugin, but it's fine when I disable Lastpass.

What version of LastPass are you seeing this with? Are you only seeing this in nightly/aurora with e10s enabled, or are you also seeing it in production/beta and/or nightly/aurors with e10s disabled?

Right now I'm using the 3.2.41a e10s version (I come back here to update occassionally). I have been using it with Firefox Developer Edition with e10s enabled, since at least FFDE 42.0, but I'm now using 43.0a2 I will try it without e10s enabled for a while today to see if the problem still exists and report back. I've not tried it on the firefox release, as the normal (non-e10s) extension is still working there.

@jackson: for me LastPass on its own is fine, it's only when used with µBlock/Adblock that it becomes super slow. µBlock/Adblock on their onw are fine too...

A very good example is the http://www.wunderground.com/ website, it takes about 3x slower to load completely with those AddOns.

@Andrew Zitnay: I have tried it (latest dev builds here) for a few days with e10s disabled on FFDE, too, and it still becomes unbearably slow eventually (though sometimes it takes a little more browsing). Note that I do not (and have never) installed any ad blockers such as AdBlock / mBlock, and have been able to reproduce the laggy behavior with nearly all other extensions aside from LastPass disabled.

(In reply to jackson from comment #154) > @Andrew Zitnay: > I have tried it (latest dev builds here) for a few days with e10s disabled > on FFDE, too, and it still becomes unbearably slow eventually (though > sometimes it takes a little more browsing). This is my experience too. Further, some sites seem to trigger an immediate slowdown that goes away once the page has been closed. I can only assume this latter problem is related to the content on the page. Unfortunately the 1 site where this is particularly obvious requires a login.

Digg Reader seems to do a good job of producing a slowdown with this plugin.

(In reply to Andrew Zitnay from comment #126) > Regarding the crashes, they're presumably Mozilla's responsibility to fix. > LastPass is nowhere to be found in the backtraces, so at worst we're > tickling a bug in Firefox itself. I've looked into this and this should be fixed now. (bug 720589)

(In reply to jackson from comment #149) > For what it's worth, I've been trying the last pass dev xpi listed on this > ticket, and while it works, it slows FF to a crawl when rendering new pages > or generally doing anything. I'm not sure if it's the extension's fault or > Firefox itself, but it's really quickly becomes unusably slow with e10s > enabled and this plugin, but it's fine when I disable Lastpass. There were some optimizations quite recently, and I'm trying to reproduce these slowdowns with the xpi on this bug, but so far it seems to be smooth. If you still see it with the latest nightly, could you provide me an STR? Also, there is an about:config flag: dom.ipc.shims.enabledWarnings if you set it to true, it will log warnings on the JS console every time the add-on hits the shim layer (which can be a reason for slowdowns). If you're still experiencing the slowdown with the latest version could you please also check if you see warnings there? Thanks!

I'm not able to reproduce these slowdowns either. For people who are, do the sites that experience the slowdowns perhaps contain a ton of iframes? I could potentially see that cause issues, since we're now injecting JavaScript into every frame.

I just downloaded a nightly (first time I've tested a nightly, so bear with me) with e10s enabled and the lastpass e10s xpi above, and it was quite slow. The only noticeable change is that now a bar comes up at the bottom telling me that lastpass extension is probably making firefox slow.

Is there any additional information

I started it up again to get some more info and had to force quit nightly and disable lastpass again. Firefox complained about this resource: Script: resource://gre/modules/commonj...com/lastpass/data/onloadwff.js:9 However, it was too slow to debug the issue. Is there any more information I can provide?

While the e10s version from comment# 87 indeed enables form fill, syncing state between browsers (Chrome and Firefox) seems broken. Likely not a Mozilla issue but still thought I'd mention it here, because the issue does not exist with the latest production xpi and browser.tabs.remote.autostart disabled.

LastPass just release version 4 and it looks like it fixed (all?) issues for me on DevEdition

(In reply to zawaideh from comment #164) > LastPass just release version 4 and it looks like it fixed (all?) issues for > me on DevEdition Not for me, quite the contrary. Lastpass 4 isn't able to fill any fields automatically anymore with e10s enabled.

Autofill works here, but Secure Notes attachment upload in 4.0.4a with e10s times out (ERROR: Sorry, this request is taking longer than normal.) and/or freezes the whole browser for up to 15 seconds (8 byte test file), but still creates a note with the file (checked integrity). Opening an attachment for the first time takes multiple seconds without any feedback, leading to multiple clicks and then suddenly getting a bunch of popups (read: download indicator would be nice).

Deleting a secure note also pretty much freezes the whole browser for multiple seconds after the 'Success' bar is shown (Firefox is barely able to open the slow script dialog).

Adding needsdiagnosis before outreach. It would be necessary to explain why is it broken and how to fix it for LastPass developers. See http://www.otsukare.info/2016/02/05/bug-ready-for-outreach-howto

Using Lastpass 3.2.42 w/ DevEdition 46.02a it doesn't autofill forms. The usual popups to auto-fill also don't work. However, using LastPass in the menu bar and choosing the correct site + autofill does work.

(In reply to Benson Wong [:mostlygeek] from comment #169) > Using Lastpass 3.2.42 w/ DevEdition 46.02a it doesn't autofill forms. The > usual popups to auto-fill also don't work. However, using LastPass in the > menu bar and choosing the correct site + autofill does work. True, but I have experienced that even then, it tends to crash the tab.

Probably a duplicate of this issue on webcompat https://webcompat.com/issues/2391

LastPass 4.1.5a works perfectly for me with e10s nightly. LastPass 4.1.7a works, but trying to view/edit/add a site brings up a blank window. I'm guessing we could resolve this bug if LastPass 4.1.5a shipped. https://addons.mozilla.org/en-US/firefox/addon/lastpass-password-manager/versions/

I'm using LastPass 4.1.7a with Developer Edition (48.0a2) w/ E10S and no problems at all.

4.1.7a works fine on Aurora (48.0a2) for me too. Just broken on Nightly 49.0a1 (save site or show matching sites->edit opens a blank window).

Looks like my nightly+4.1.7a issue is tab center: https://github.com/bwinton/VerticalTabs/issues/265 . Sorry for the noise. Should we get LastPass to ship 4.1.7a on amo so we can close this bug?

4.1.15a Looks like it has no issues in nightly 50.0a1 (2016-06-20) and Aurora 49.0a2 (2016-06-20), I don't see alerts about the addon running slowly and fields are correctly found without crashing the browser in some cases.

I have trememndous performance problems with lastpass 4.1.x and nightly (as of a week ago when I had to uninstall lastpass). Particularly with politico.com on windows open 5 or 6 new tabs on politico.com and watch it grind things to a halt. Otherwise clean profile. There isn't anything to acutally log in to on that side, just open the tabs in parallel. It takes about 5 minutes for the dust to settle on my core i7.

On Firefox nightly, it looks like the issue with forms detection is back since the beginning of the week.

(In reply to Francois Guerraz from comment #178) > On Firefox nightly, it looks like the issue with forms detection is back > since the beginning of the week. Yes, I also see this with roughly the same timeframe.

That was bug 1286126. I think today's Nightly will have the fix.

blassey and andym verified working now with latest nightly. blassey has same error that mark and francois had seen this week.

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #180) > That was bug 1286126. I think today's Nightly will have the fix. I confirm it works for me on the latest nightly.

FF 51 has a big issue with LastPass, fill forms doesn't work and LastPass matches all sites on every page potentially leading to password leaks? Also, especially in conjunction with uBlock0, LastPass slows down the browser massively (most noticeable when working with AWS Console on API gateway for example).

LastPass offered on addons.mozilla.org is in version 3.3.1 which does hang Firefox with e10s (see bug 1301771 for an example with a profile). LastPass released an updated version of the addon - 4.1.29a - which is currently in "development channel" - https://addons.mozilla.org/en-US/firefox/addon/lastpass-password-manager/versions/beta The new version (4.1.*) does not hang the browser and is usable both in Nightly and Aurora. Not sure what has to happen in order to get this version out to users (the public version on AMO seems to be *very* old and it seems that lastpass submitted many 4.x revisions since then), but since it's a top20 extension, I hope we can prioritize it in the AMO review queue.

The difference between LastPass 3.3.1 and 4.1.29a on Nightly is night and day. about:newtab loading, tab switching, browser animations, page loading, ... pretty much everything feels faster. It's like a brand new browser. This must be what e10s is supposed to feel like. Oh, and form filling and the search field in LastPass's UI actually works now too (that's been broken for a few weeks on Nightly).

Lastpass is now working on a WebExtension version, I don't think this bug has much value anymore. Duping over to the relevant WebExtension bug.