I have been using Trisquel 11 since its launch, and Abrowser's payment-auto-fill never worked properly.
On the same OS on the same machine, I tried the same operation in the corresponding version of Firefox, and it worked perfectly. So I am sure it is an issue of Abrowser.
I think it is either a configuration defect or a defect that is related to the Default keyring's associated "Firefox Encrypted Storage".
SYMPTOM
The auto-filled payment card number is always empty.
STEPS TO REPRODUCE THE ISSUE
Step 1: In Abrowser, open a payment Web page, select a saved payment method to fill the HTML element, expecting the card number to be filled correctly.
Step 2: MATE desktop pops up a modal dialog box, saying ‘An application wants to access the keyring "Default keyring", but it is locked.’. Input the Default keyring password.
Now the modal dialog box disappears, and the auto-fill completes with an empty card number in the HTML element.
Step 3: In Abrowser's Setting > Privacy & Security > Saved Payment Methods, check the saved payment methods. They are all there but the card numbers are all missing, the other fields are good.
PRELIMINARY INVESTIGATION
I checked the file ~/.mozilla/abrowser/py6nefmq.default-release/autofill-profiles.json ($HOME/.mozilla/abrowser/<MY_ACTIVE_PROFILE>/autofill-profiles.json), and find all the encrypted card numbers in the field cc-number-encrypted. So the card numbers are not empty in the local storage.
I also found the corresponding autofill-profiles.json in the firefox folder ~/.mozilla/firefox/. It looks normal and similar to that for Abrowser.
It means that the information is stored properly, but somehow Abrowser cannot decrypt them properly or cannot read them properly.
Hello and welcome to the issue tracker, thank you for posting the details of the issue.
This is a very specific issue, firefox code is a huge network of information moving around, so it is possible that some of the customization do indeed break the feature at hand, since it doesn't render the package unusable, nor affect the privacy, it will be addressed when possible.
I appreciate that you be patient as these issues require plenty of time to be addressed, which is a limited resource lately with the development of T12, Ecne.
@ruiduan have you seen if the issue is reproducible on a clean profile?
There is an early testing release on the testing repo (Redundancy Intended™ :), you might like to check it out.
As for any testing you might like to backup your .mozilla folder at $HOME so you prevent issues due to the update, or maybe use a test VM. To enable the testing repo you can use:
echo "# Testing updates repository.deb http://builds.trisquel.org/repos-testing/aramo aramo main" | sudo tee -a /etc/apt/sources.list
Hi @Ark74 , I ran into the same issue with Abrowser version 133 which was installed from the testing repo.
I installed Trisquel 11.0 freshly on a physical machine, then used your method to upgrade Abrowser, then disabled the testing repo. Then I started Abrowser for the first time on that machine to start my test.
In my test, I did not use the Firefox online account at all, I just used the local account with a clean profile. In such a clean environment, the same issue occurred.
$ abrowser --versionMozilla Firefox 133.0$ uname -aLinux rui-Latitude-D620-15 5.15.0-67-generic #74+11.0trisquel18 SMP Sun Mar 5 03:14:11 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux$ cat /etc/os-releaseNAME="Trisquel GNU/Linux"VERSION="11.0, Aramo"...
Hi @Ark74 , thank you for your inspiring video! I made a very simple Web page cc.html like yours, and did some tests in it.
No, I don't think it is any plugin that causes the issue. Because I used a fresh Trisquel installation to do the test on web site https://www.cibconline.cibc.com .
Steps to reproduce the issue
Using my cc.html, here are the steps to reproduce it. The key is to log-out and log-in Trisquel again.
Opened cc.html in Abrowser, and I could see the autofill pop-up. When I selected the newly added entry, the autofill was successful! All the card numbers, card holder name, and the expiration time were filled correctly.
Log out my current user of Trisquel.
Log in again.
Opened cc.html in Abrowser, and tried to do the same autofill. I could see the pop-up, and I could select the newly added entry, however, after the selection, MATE desktop popped up a window to ask me to input the password for the Default keyring. After I input the password, the autofill silently failed with empty filling. None of the card number, card holder name, or the expiration time was filled.
Checked the Saved Payment Methods setting, selected the newly added record, clicked "Edit" button, then I found that the card number is empty!
Checked the autofill-profile.json file under the Abrowser's active profile's directory, and I saw the newly added credit card information, including card number, card holder name, and the expiration time, all were there!
Why did Abrowser displayed empty card number in the editing dialog box, and why did Abrowser failed to do autofill?
Firefox also fails if log-out and log-in
When I opened this issue, I said Firefox worked well. But today I logged-out and logged-in and tested Firefox, it had exactly the same symptom as Abrowser.
Both Firefox and Abrowser can succeed in autofill when a new entry is added and then used without logging out Trisquel. However, log-out and log-in can trigger the issue. Every time the Default keyring password dialog box appears, the autofill fails.
My investigation
My investigation has not completed yet. Here are what I have done.
I have checked some source code of Firefox and package-helpers/helpers/make-firefox. I did not see any suspect in package-helpers/helpers/make-firefox. I read some code in firefox-132.0.2+build2/toolkit/components/formautofill/, but I have not been able to run a live debugging session to find the root cause.
I also compared some name-related about:config settings between Abrowser and its Firefox counterpart, and did not find any difference. For example, I searched "autofill" and "credit" in about:config and compared the settings.
I think it is not a defect of Abrowser but something wrong with the external system (outside of Abrowser). A suspect is MATE's Default keyring.
I think you can close this issue and release version 133 without worries. In the future, if needed, I can reopen the issue if I am sure it is Abrowser's fault.
It took me some time to actually be able to trigger the right steps order and session match the environment details.
I will try to follow up, seems like some sort of keyring + app-armor + javascript issue, sadly I won't delay 133 any longer, so I'll continue digging for the next release, I've spent too much time on Mozilla software lately O_o, I need a break.