1.0.4
Submitted 23 September 2026, not yet installable. This version goes live when the Chrome Web Store and Microsoft Edge Add-ons finish review. Until they do, the current release is 1.0.3 — everything below describes what is on its way, not what you have.
New
- Eight common field types are now recognised in five languages. First name, surname, street, city, postcode, country, phone and email are matched by many of their German, French, Spanish and Portuguese names and labels, not only their English ones. A date of birth is recognised in those languages too. Some short words are deliberately left out because they are also ordinary English and would misfire on English forms: German "Land" and French "Pays" for country, and French "portable" for a mobile number. Every other field type is still matched on its English name.
- A gender question is answered to match the generated first name. Radio buttons and dropdowns both, when the options use wording FormForge recognises — Male/Female, männlich/weiblich, Homme/Femme, masculino/femenino, masculino/feminino, and courtesy titles such as Mr/Mrs, Herr/Frau and Monsieur/Madame, which is how many German forms put the question under "Anrede". "Other" and "Prefer not to say" are recognised, and are never chosen when an option matching the person is available. If no option can be matched, one is chosen at random and the popup says that is what happened. Before this, the choice was random on every form, so a form could come back with a man's name and Female ticked.
- Brazilian pages get Brazilian data. A CEP written 99999-999, a +55 mobile number, Brazilian names, cities and states, and Brasil as the country. Pages marked as Portuguese from Portugal, or simply as Portuguese, get Portugal's data as before. A page that does not say what language it is in gets the data for your browser's language, as it always has; what is new is that a browser set to Brazilian Portuguese now gets Brazilian data on those pages, where it used to get Portugal's. Settings lists Português (Portugal) and Português (Brasil) separately.
- A keyboard or right-click fill now reports what it did. Alt+Shift+F filled the form and said nothing, because the result only ever appeared in the popup and the popup is not open when you use a shortcut or the right-click menu. A brief summary now appears in the corner of the page, with the same counts the popup shows. It cannot be clicked, it does not move the page, and it disappears on its own — except when its counts do not add up, described next, when it stays until you press Esc. You can turn it off in Settings.
- Every fill checks that it accounted for every field it found. If the numbers ever fail to add up, the popup and the page summary both say so — how many fields were found and how many were accounted for — and ask you to email the page's address to support@flinthive.com. That would mean FormForge lost track of a field without telling you. It did not happen on any page this release was tested on; the check is there so that if it ever does, you see it.
Fixed
- A date of birth could be filled with a date in the future. A field named "bday", "bdate" or "born" was not recognised as a birth date, and neither was one named in German, French, Spanish or Portuguese. Those are recognised now. A date field FormForge cannot identify at all is filled with a past date rather than an upcoming one, because a past date shows up as a validation error you can see, while a future date of birth passes quietly.
- A checkbox the page had already ticked could be unticked by a fill. A pre-ticked box is now left ticked. Boxes the page leaves unticked are filled as before, and a tick from an earlier fill is not treated as the page's own.
- A control that navigates the page when you change it is now left alone. A currency switcher in a site header, for example — where the page declares that behaviour in the control's own markup. On sites that use one, filling it reloaded the page and lost the rest of the form. The summary now names any control left alone for this reason.
- A phone number or a card expiry date written into a numeric field was thrown away by the browser, leaving the field empty. Values that are digits wearing separators — phone numbers, postcodes, card numbers, security codes and expiry dates — are now written as digits only when the field is numeric. Values that are not digit strings are left as they are and reported if the field does not keep them, rather than being reduced to whatever digits they happen to contain.
- The popup blamed a web framework for values a field did not keep. It said "framework rejected the value" including on pages with no framework at all. It now reports what the field held instead, empty or some other value, and does not name a cause it has not established.
- Whether a field kept its value was checked in the same instant it was written. A page that emptied the field a moment later was reported as filled, and a page that accepted a card number and spaced it into groups was reported as not keeping it. Every field is now read back once the whole fill has finished, and a value counts as kept when the field holds the same letters and digits, in whatever format the page chose. A field left empty, or holding only a mask's placeholder such as (___) ___-____, is reported as not kept. Each fill takes about a tenth of a second longer: that is the wait before the read.
- Portugal's data mixed in Brazil. A form filled in Portuguese could get a Lisbon postcode beside São Paulo as the city, and a country list could come back with Brazil chosen. Portugal's data now describes Portugal only, and Brazil has its own.
- A field rule written with a dash or a dot in it matched nothing, silently. "first-name", exactly as the page's own HTML spells it, found no fields. Rules now match whether you write the separator or a space.
- The self-test page reported the wrong time, looked stuck, and was slow. It gave the duration of one of its five internal passes as if it were the whole run, and showed a motionless "Running…" until it finished. It now reports the time the whole run took and counts through its passes as it goes. It is also faster — about 14 seconds instead of about 32 on the machine it was measured on — because three of its five passes no longer drive the dropdown and date-picker widgets they do not test.
Removed
- The Pro tier listed "per-site rules" as a feature. It was never built. Field rules match on the field's name, id, label and placeholder — they have never been scoped to a particular site, and nothing in the extension read a rule's site. The claim appeared on the Pro card in Settings and in the upgrade panel in the popup, and both have been corrected. If you bought Pro partly for that line, email support@flinthive.com and I will sort it out.
- The "Site access" panel. It asked you to grant a site permanent access and said fills would then run without a gesture. Nothing in the extension ever read that permission, so granting it did nothing at all. The panel is gone, and any access you granted through it is handed back automatically when you update. FormForge holds no standing access to any website, which is how it was always meant to be.
If you use seeds
- A seed recorded on 1.0.3 still produces the same person — the same name and the same email — on every page except a Brazilian one. On a form with none of the fields this release changed, it replays exactly.
- Only that field changes for a date of birth, a date field FormForge cannot identify, and a phone number in a numeric field.
- The values after it change too for a pre-ticked checkbox, a gender control, a field named in another language that this release now recognises, and a control that navigates the page — the navigating control only where 1.0.3 had not already matched it to the page, as it had for dollars on an English page or euros on a German one.
- On a Portuguese page the city and region change in most seeds, because Portugal's data no longer includes Brazilian places.
- On a Brazilian page, or on a page with no stated language in a browser set to Brazilian Portuguese, a 1.0.3 seed gives a different person altogether, because those pages now get Brazilian data.
- Measured, not inferred: 1.0.3 against 1.0.4 on seven page languages, eleven forms and 25 seeds each.
Unchanged, and worth saying
- Everything else Pro does is the same: unlimited saved profiles, unlimited field rules, and seeded fills that reproduce exactly on the same version of FormForge.
Testing
- As of this release the suite covers 140 fixtures across 165 graded cases, reading 148 passed · 0 failed · 17 correctly skipped.
- Gender agreement is checked with 60 seeded personas through each of 12 radio and dropdown controls — 720 cases — rather than the single persona a normal run uses, because one seed tests one gender and an engine that always chose the same answer would pass by luck.
- A field rule is now checked to fire on its target and on no other field. The suite had filled every field with test rules active and then read only the two it expected; a rule that also fired somewhere else would have passed.
- The build now fails if a generator name has no gender tag, if a rule token would be split by a letter the classifier does not fold, if seeded reproducibility is promised anywhere without saying it holds on the same version, if any page language other than Brazilian Portuguese starts resolving differently, or if the fill summary stops carrying its accounting to the popup and the page summary.
Permissions
- Unchanged —
storage,activeTab,scripting,contextMenus. Nothing new was requested, and the optional host permission this extension never used was removed entirely.
Availability
- Submitted to the Chrome Web Store and Microsoft Edge Add-ons on 23 September 2026, from the same package.