IE not responding to button clicks

[aabiabdallah]

There seems to be an issue with buttons that reside outside the form element on IE (I've tested on IE 11). This issue can be reproduced on IE using the "Test Login (John Doe)" button. I believe this also affects the form-list with multi=true.

Proposed Solution 1: Include a hidden submit in the form element and reference it outside the form.

<form method="get" action="something.php">
     <input type="text" name="name" />
     <input type="submit" id="submit-form" class="hidden" />
</form>
<label for="submit-form">Submit</label>

Proposed Solution 2: Use a JavaScript call instead of the form attribute. I was able to achieve this by setting the button onclick attribute in DefaultScreenMacros.html.ftl.

form="${linkFormId}" onclick="$('#${linkFormId}').submit()"

References:

• http://stackoverflow.com/questions/28762128/form-button-not-working-in-ie11
• http://stackoverflow.com/questions/7020659/submit-form-using-a-button-outside-the-form-tag

[jonesde]

It will take a fair bit of testing and work to add the shims/etc to support IE11 as moqui-runtime has moved more and more over time to use HTML5 features. Using the form attribute is one of them, and as of 2.0.0 it is used quite a bit to avoid issues where the form element is not valid HTML when used under tr elements (to wrap various td elements, to have one form per row).

From my limited research there are JavaScript workarounds for this, including in open source libraries, that will find all elements with the form attribute and run some JS to make them part of the form. It isn't just the submit buttons that are the issue, but the input fields and such as well.

For a few reasons supporting IE11 is not a high priority for me. The OOTB moqui-runtime HTML macros are meant primarily for ERP/CRM/etc applications and not for something like ecommerce where supporting older browsers is a high priority. Even the POP Commerce ecommerce app (/popc) is a demo app and a real Moqui based ecommerce app should have much more custom HTML. Another reason is that I do all development on Linux (used to be on Mac) and don't have a good test platform for IE11. You can do so much more, and run so much better, on modern browsers including Google Chrome, Mozilla Firefox, and even Microsoft Edge that will all run on Windows.

I'll leave this open and marked as an enhancement but don't plan to work on it myself.

[jonesde]

On a side note, the Login screen now has JavaScript that does a browser check, specifically for IE, and recommends using a more modern browser (with links to Edge, Firefox, Chrome).

Still leaving this open in case someone wants to work on it, but sooner or later my guess is that IE support in JavaScript libraries and other tools we use will go away and it will be not be reasonable to support these older browsers at all. At least with the Edge browser Microsoft has realized that having totally non-standard browsers is a bad idea, but unfortunately they also don't care about users of older versions of Windows. This is totally out of our control as long as massive companies like Microsoft continue to play these games.

On a side note, this is only important for internal use web applications. For public facing applications you should generally use custom HTML that supports any browser you want and not the HTML produced by the macros for XML Screens/Forms/etc.

[chunlinyao]

unbelievable Edge still not support form attribute.

[jonesde]

Closing as part of general cleanup for the move to HiveMind and for no recent activity on this issue. If this comes up again or anyone wants to pursue it feel free to create a request on moqui.org. For more information see:

https://www.moqui.org/m/docs/moqui/Community+Guide