By platform
Adobe Portfolio contact form not working
A visitor types a message, presses send, and either sees an error or sees a thank-you that never reaches you. Simulated visitors send the same kind of message from a phone and show which of the two happened.
Why does my Adobe Portfolio contact form fail when visitors type a message?
A contact form can fail in three places: the field refuses what the visitor typed, the send fails after the press, or the message is sent and never arrives. The clue is what the visitor saw after pressing send. A simulated test types a message the way a visitor would, from a phone, and records any error on the page and any failed request on that step.
What this looks like in a report
“I pressed send and the box sat there. I did not know if it sent, so I typed it all again. Then a message I could not read appeared at the top.”
The fix. Make the send button reachable above the on-screen keyboard, and show any validation message beside the field it names. Test a send from a phone with a several-paragraph message and a plus-sign address, then check the inbox and the spam folder for the arrival.
An illustration. Run a test to see your own.See a real sample report
Your own test message reached your inbox, so the form looked fine
You sent a test from the site while signed in, with a short message and an address you control. The message arrived, so the form seems to work. A visitor types a longer message on a phone, with autofill filling the name box and a line break in the middle of the text. That message can be refused by a rule on one field, and the refusal may show above the keyboard where the visitor cannot see it. Or the request goes out and fails quietly, and the visitor sees no change at all. From your inbox, all of these look the same: nothing arrived.
- On a phone, type several paragraphs and press send. Can you still reach the send button above the keyboard?
- Paste text with a line break into the message box. Does the field keep it?
- Enter an email address with a plus sign in it. Does the form accept the address?
- Press send and wait. Does the page show a confirmation, an error, or nothing at all?
- Check the inbox and the spam folder for the address you used. Did the message arrive?
Three places the message can fail, and what each looks like
A contact form fails in one of three places. The field can refuse what the visitor typed, the send can fail after the press, or the send can succeed and the message never arrives. The first usually shows a line of text near the field, or nothing the visitor can see. The second shows a press that goes nowhere, or an error that may sit off the screen. The third shows a thank-you line and an empty inbox. From your side all three look like no messages, which is why owners often blame the email and visitors blame the page.
Long text, line breaks and the on-screen keyboard
Typing on a phone is where the message box is most likely to fail a visitor. If the form has a length limit, a long message can run into it without the visitor knowing where the limit is. A line break can be dropped, or it can submit the form early when the box is a single line rather than a text area. The on-screen keyboard can also cover the send button, so the visitor never reaches it and the form seems to ignore them. Test with paragraphs, not one short line, because a short line hides all three problems.
A thank-you line can show while the message is lost
A thank-you line only shows that the browser sent something. Check where it goes: the inbox the form is set to write to, and the spam folder of that inbox. Send one message from an address that is not yours, so you see the route a real visitor's message takes. If the thank-you line appears and nothing arrives, the fault is in delivery, and the page is no longer the first place to look.
Mimiq is independent and not affiliated with the platforms it names. Names belong to their owners.
What you get with Mimiq
- 01
Run it by hand, or on every pull request
Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.
- 02
Bugs and usability problems in one report
The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.
- 03
Visitors that behave like your audience
Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.
- 04
A prompt to fix each problem
Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.
- 05
Follow every visitor
See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.
The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.
A theme change or a copied contact block can reset the form's settings
A new layout, a copied contact block or an edit to the form's fields can change where messages go, which fields are required and how the send button behaves. After each change, send one message from a phone with several paragraphs, then check the inbox and the spam folder. Keep the address you tested with, so the next check follows the same route.
Starter
Try it on one launch
About 4 tests of 5 visitors
- Visitors on your landing page, signup and checkout
- Where they left and why, with a fix to copy for each problem
- Run it in the app or on every pull request
- Ask any visitor a question, included
- Test accounts and protected previews
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Can a simulated visitor send the contact form?
Yes, when the form is public and has no step in front of it. A simulated visitor types the fields, presses send and reports what appeared. If the form asks for a code sent by text message, the run stops there, because a simulated visitor cannot receive one.
Does the test show whether I will get enough inquiries?
No. It does not predict how many inquiries the page brings in. It shows whether a message can be sent, what the page showed the visitor, and whether a failed request appeared on that step. Take the count from your own inbox.
Can the run check my inbox for the message?
No. The run does not read your email, so check the destination yourself, using the address you entered in the test. Look in the spam folder too, because a message the form sent can still be filtered out.
Will a failed request show up in the report?
It can. The browser records failed app requests and relevant JavaScript errors on the step where they happened. A message that looks sent to the visitor but never reaches you will not show up as an error, so check the inbox separately.
Should I replace the form with a plain email link?
Maybe, if the form keeps failing for the visitors you need. A plain address is harder to break, but it gives the visitor no confirmation and no fields to fill in. If you use one, write the subject line you want, so your inbox sorts the inquiries.
Keep reading
Send visitors and see what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.