1097137 - Dashlane (latest 3.1.2) extension doesn't work with latest Firefox (33.1)

Status: RESOLVED INVALID

(Firefox :: Extension Compatibility, defect)

Description

[Bob H]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141030112145

Steps to reproduce:

regular usage - Dashlane ext flags user/password fields it sees to allow for Dashlane to populate.    As of FF 33.1 (Mac) this morning, Dashlane doesn't recognize the fields.   Tried uninstalling & reinstalling the Dashlane extension - - no change.


Actual results:

Dashlane apparently not operating - no sign it recognizes user/pswd fields.


Expected results:

DL should have an icon in user/pswd fields to indicate it has stored credentials that can be used.

Comment 1

[:Gijs (he/him)]

Have you contacted dashlane about this? This is likely a problem on their end.

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

This is a known problem and Dashlane are working on a fix: https://twitter.com/dashlane/status/532219574360748032

The problem was introduced by the unexpected change in version number in 33.1 (https://blog.mozilla.org/addons/2014/11/11/firefox-33-1-compatibility/), and developers need to change their code to adjust to it. There's nothing to do here on our side.

Comment 4

[Bob H]

FF team:   Gijs, Jorge, ....
   I contacted them first.  fyi -  I worked in this field for many years - software integration across products.   It's always close as to which 'side' needs to act to fix;  the 'victim' or the 'changer'.   I don't disagree that you should continue to work/pressure Dashlane to fix;  but you should know that I (and likely others) have switched our default browser from FF to Safari to workaround this issue.
   I assume you provide pre-release version with technical notes to the various add-on/extension vendors?  At least the ones that need to be tightly integrated with things like security??   If not, then I think you own some of this problem too.
   Also, is it an option for folks like me to regress to prior version of FF until this is resolved??
Just my 2 cents.

Bob

Comment 5

[:Gijs (he/him)]

(In reply to Bob H from comment #4)
> FF team:   Gijs, Jorge, ....
>    I contacted them first.  fyi -  I worked in this field for many years -
> software integration across products.   It's always close as to which 'side'
> needs to act to fix;  the 'victim' or the 'changer'.   I don't disagree that
> you should continue to work/pressure Dashlane to fix;  but you should know
> that I (and likely others) have switched our default browser from FF to
> Safari to workaround this issue.
>    I assume you provide pre-release version with technical notes to the
> various add-on/extension vendors?  At least the ones that need to be tightly
> integrated with things like security??   If not, then I think you own some
> of this problem too.
>    Also, is it an option for folks like me to regress to prior version of FF
> until this is resolved??
> Just my 2 cents.
> 
> Bob

We provide public versions of our pre-release software to *everyone*. That's part of being open source. Here's links:

https://nightly.mozilla.org/
https://aurora.mozilla.org/
https://beta.mozilla.org/

Nightly will have anywhere between 18 and 12 weeks to go to being released, aurora 6 weeks less, and beta 6 weeks less than that (meaning that, right now for instance, it's just under 2 weeks from being released as Firefox 34).

We make appropriate amounts of noise for big changes, too, on https://blog.mozilla.org/ .

We're literally unable to contact every single add-on author privately if their stuff breaks. We're too small an organization for that considering our scale (hundreds of millions of users, a significant proportion of whom use add-ons), and the number of external vendors that interface with us. We depend on users reporting issues and/or vendors keeping up-to-date with updates such as the above.

In this case the issue was first reported, as best I can tell, 4 weeks after the release (I'm assuming this was broken in 33.0 from the start, not just in 33.1, which would be highly surprising considering the changes in that release). At that point, there's quite literally almost nothing we can really do. We have millions of people on beta - apparently none of them use dashlane and/or noticed it was broken and/or reported it to either us or them.

As to your question about old builds, they are available via http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ , all the way back to 0.8, now over 10 years old - not that I would recommend running that... ;-)

Comment 7

[:Gijs (he/him)]

https://twitter.com/dashlane/status/533020374653747200

says this is fixed on Windows, and should have OS X fixes today, and/or as soon as Apple deals with the app store approvals.

Comment 8

[Bob H]

Thanks  - - a little surprising no beta users on Dashlane;  I thought DL was more pervasive.   If FF betas are really for "anyone", perhaps I'll test with next go round - - especially since I can keep current production version to fall-back if necessary.    (As you noted, the 3-rd party update world has gotten complicated by Apple's App store:   they have the updated version on their site, but if you originally got from Apple Store, you have to wait for Apple to approve & post the update.    I ended up fully uninstalling the version I had, and got update from their website - which, so far seems to fix the problem.)
Thanks!

Bob H.

Comment 9

[Jorge Villalobos [:jorgev] (he/him)]

Actually, the problem occurred because of the surprise release of 33.1, so it isn't really their fault that their add-on broke unexpectedly: https://blog.mozilla.org/addons/2014/11/11/firefox-33-1-compatibility/.

Comment 10

[:Gijs (he/him)]

(In reply to Jorge Villalobos [:jorgev] from comment #9)
> Actually, the problem occurred because of the surprise release of 33.1

Do we know why this caused the add-on to break?

Comment 11

[Jorge Villalobos [:jorgev] (he/him)]

Yes, the blog post explains it. Some binary add-ons have chrome.manifest clauses that declare components to be compatible with, say, 33.0.*. The unexpected 33.1 version didn't meet those restrictions and caused the components to not be loaded. If they switched to checking for X.* instead, that could cause more breakage for ESR releases, since I don't think we keep binary compatibility for those releases.

Comment 12

[:Gijs (he/him)]

(In reply to Jorge Villalobos [:jorgev] from comment #11)
> Yes, the blog post explains it. Some binary add-ons have chrome.manifest
> clauses that declare components to be compatible with, say, 33.0.*. The
> unexpected 33.1 version didn't meet those restrictions and caused the
> components to not be loaded. If they switched to checking for X.* instead,
> that could cause more breakage for ESR releases, since I don't think we keep
> binary compatibility for those releases.

Not sure. Either way, they could still be using X.* for non-ESR branches (like 33).