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

RESOLVED INVALID

Status

()

Firefox
Extension Compatibility
RESOLVED INVALID
4 years ago
4 years ago

People

(Reporter: Bob H, Unassigned)

Tracking

33 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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

4 years ago
Have you contacted dashlane about this? This is likely a problem on their end.
Component: Untriaged → Extension Compatibility
Flags: needinfo?(bobroch)
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(bobroch)
Resolution: --- → INVALID

Updated

4 years ago
Duplicate of this bug: 1098395
(Reporter)

Comment 4

4 years ago
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

4 years ago
(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... ;-)

Updated

4 years ago
Duplicate of this bug: 1099059

Comment 7

4 years ago
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.
(Reporter)

Comment 8

4 years ago
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.
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

4 years ago
(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?
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

4 years ago
(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).
You need to log in before you can comment on or make changes to this bug.