I'm assuming this is for version 5 SDKs? (https://aep-sdks.gitbook.io/docs/using-mobile-extensions/mobile-core/configuration ?)In launch, go to "Environments" in the left rail: Then click the little box icon for the appropriate environment (dev, staging, production- I'm assuming you're still in dev ...
I want to say sometimes the "submit" trigger is looking for the element of the FORM that is being submitted, not the submit button. If you can't get the developers to set a reliable direct call for you, I'd try either changing the trigger to be click-based on the submit button, or submit-based on t...
After testing, I can confirm- the global variables only fire on s.t beacons. They may hang around until an s.tl beacon, but they're not freshly set for s.tl beacons. If you fire clearvars after a page view, you will not have the global variables on subsequent s.tl beacons.
I only just got around to testing this and for me, the global variables still not fire on on an s.tl beacon (if I had set clearvars on the page view beacon- I suspect this might be the difference?).
For what it's worth, while Mobile Screen Size pulls from user agent and is wrongly getting lumped into 320x480... "monitor resolution" still pulls from the "s" param in beacons, which comes from javascript objects in the browser, and seems to still be correct. I believe this only works for javascrip...
@aahardy That would be slightly better, but the problem is that users are often on another tab (or off grabbing some coffee or something)- if they're inactive for long enough to auto-logout, they're probably not going to be there for the warning either.
Can I add my vote for making this something we could disable? Especially since our options for copying and/or cleaning up values in Launch or in Processing rules is so limited.