I believe I've encountered a bug with the v4 print widget, which is causing a postback when clicking button elements. For instance, "Advanced Options", "Refresh", "Map Only", "Export" causes a postback on an aspx in Chrome.
However, the built-in widgets are designed to make it easier to develop and to stay within the widget "ecosystem", so this isn't a preferable solution for me.
Another solution is to add the "type" attribute, as "button", which is actually something recommended by W3 - https://www.w3docs.com/learn-html/html-button-tag.html:
The <button> tag doesn’t have required attributes; however, we recommend always use the type=”button” attribute, if the tag used as an ordinary button.
The recommendation is made as browsers determine default behavior. In my case, when using Chrome on an aspx, it is using "submit" behavior.
I have a solution to iterate over the widget elements in jQuery to add the type attribute, but it's a kludge (we have to detect when the widget is loaded and when hidden elements are made visible). Also, styling of the "Layout" and "Map Only" buttons at the top changes, so that's something else that will need manual correction.
Is there a better solution/recommendation? Is Esri working on a fix?
Solved! Go to Solution.
I'm experiencing this issue using 4.17 when using the Search Widget. The buttons Search and Clear search result in a page submission for on-click. It seems to be related since when manually adding the type="button" attribute, it behaves as expected.
I'm having the same issue with the search widget as well.
Doh. Thanks for reporting. Let me take a look.
The search widget buttons also did a postback in 4.17. I added the JS to prevent the form from being submitted as a workaround.
Following up that this is still an issue with the Search widget, even in 4.22. Simple fix is to make sure all the buttons in the source code are correctly attributed as type=button.