Has anybody else found that form prefill on a Marketo LP is no longer working from a clicked link in an email when SSL is enabled since the implementation of the Form Pre-Fill Feature Upgrade?
I noticed it on testing an email today, and after bashing my head against a brick wall for hours, performed some tests across a selection of my clients. Prefill worked for those that don't have SSL enabled but didn't for those that do.
In the process of testing, I also discovered that mktoPreFillFields is no longer accessible to js on any of the LPs tested.
Has it been replaced with something else?
This is actually still an issue for me... but for me, it seems to be google chrome incognito related...
Can anyone else please test?
We have not seen any reproducible issues. Can you tell me how you are testing?
It seems like a Chrome browser issue (both normal browsing and incognito) that happens if you're already cookied as person A and you click an email link for person B.
I've tested this in firefox and haven't had the same issue.
It's not an email client issue - I reversed the link click order and am still getting pre-fill failure
Methodology:
Email asset:
Landing page and form asset:
Smart campaign to send the emails:
Email received as person A in gmail:
Clicked on link and form is pre-filling on landing page as intended
Email received as person B in outlook 365
Clicked on link and form is not pre-filling on landing page as intended
In case of a mismatch between the already-associated person and the person linked to the mkt_tok, you shouldn't expect Pre-Fill to work.
I find it vanishingly unlikely that this could be a User-Agent issue, because Marketo would have to be specifically reacting to the Chrome U-A (that's all it knows during the initial HTTP request). I mean, not impossible, but low on the list...
Ok, you're right. Looks like the reason the above worked in Firefox private browsing was because Firefox doesn't store cookies. Guess it is working as intended.
Good to figure it out either way. I know one can get paranoid when there was one (intended) regression and see others that aren't there!
(Same happened to me above in fact -- the instance where I thought I'd repro'd the behavior actually was a form that had Pre-Fill disabled at the field level. Serves me right for not creating a new form in that case.)
Hi folks, we had a support ticket come in for this but it was closed and the behavior was verified as working as designed. Please, please, please don't hesitate to continue to reach out to me directly if you still are experiencing any issues. We haven't been able to reproduce anything but this is a priority so don't be shy!
Justin
I'm not sure if it's related but at some point in the last two weeks, our forms stopped displaying options based on a member status each person has. Regardless of member status, it only shows the options that should be displayed to non-members. I submitted a support case last week and they came back to me on Friday with the suggestion to turn off pre-fill. That didn't help my situation, but it leads me to believe Marketo was aware of the issue at least by then.
(Program) member status isn't something you can directly use in a form, so this doesn't sound related to Pre-Fill. Have you segmented the form on the LP?
We have a custom field for member status, which uses our custom membership codes. It (usually) works just fine. I should have just said I submitted a case for something else about a form and they seemed aware of the pre-fill issue at that time.
Sanford Whiteman This looks like a real issue. Didn't give it much thought at first, but our instance has SSL and prefill is not working after clicking a tracked email link through to a landing page with a native marketo form - I just thought it'd be the same for everyone. But indeed, in another non-SSL instance, after doing the same test, pre-fill works.
Charlie Marketo consultant in uk the bug you pointed out just now actually got me to create this workaround last week https://nation.marketo.com/thread/50485-pre-fill-workaround because our email preference centre was broken after the update - which I thought would affect everyone, turns out it only affects some users on SSL.
OK, didn't find it on a 3rd instance but did find it on a 4th instance.
It's per-instance or per-pod. you. My working tests were on app-sj01, the failed one is on app-sjp.
I wouldn't exactly say mktoPreFillFields isn't "accessible" though. I'd say it's an empty object, i.e. consistent with the idea that Pre-Fill is being attempted on the server side but the mkt_tok lookup is broken.
console.log(mktoPreFillFields) throws an error ReferenceError: mktoPreFillFields is not defined
I described it as not accessible as I wasn't sure that it hadn't been moved
sj02 here
OK, anyone/everyone want to open a Support case?
Can we just tag a Marketo employee here? (I don't know any)
We can try to let Kenny Elkington and Justin Cooperman know this way. Mass support cases are still a good idea.
Is this reproducible 100%? Is there a support ticket that's been filed? Definitely issues like this better handled through support channels, as you noted it would not be the expected behavior as documented. Please send me directly any added color or details about support cases you've filed.
Well this is strange and probably proves that I have been an idiot somewhere along the line - but Marketo support set up the same sort of test as I have been running and all is working fine.
I ran my own tests again... and all is working fine i.e. I can no longer replicate the issue.
Sanford Whiteman Jay Jiang , are you still seeing the issue?
It looks like it's fixed now. You definitely weren't imagining things. I had to write a script just to fix our email preference centre because of it.
In fact the script is still relevant, with this, once you refresh the page, your prefill still remains. Also works if people navigate directly to the page rather than clicking an email link.