The submit is being triggered by the checkExecResponse() function in bridgeit.js, which is called after the native utility returns to the browser:

	function checkExecDeviceResponse()  {
		var data = getDeviceCommand();
		if (null == data)  {
			data = pendingData;
			//record URL/hash changes that are not device commands
			storeLastPage();
		}
		var deviceParams;
		if (null != data)  {
			pendingData = data;
			isDataPending = true;
			if (!isLoaded)  {
				console.log("checkExecDeviceResponse waiting for onload");
				return;
			}
			var name;
			var value;
			var needRefresh = true;
			if ("" != data)  {
				deviceParams = unpackDeviceResponse(data);
				if (deviceParams.name)  {
					name = deviceParams.name;
					value = deviceParams.value;
					setInput(name, name, value);
					needRefresh = false;
				}
			}
			if (needRefresh)  {
				console.log('needs refresh');
				if (window.ice.ajaxRefresh)  {
					ice.ajaxRefresh();
				}
			}
...

The logic appears to be that the form post is the default behaviour. If the parameters encoded in the data sent by the native utility include a parameter 'name', this is added to the form fields and ice.ajaxRefresh() is not called. I'm not sure what the logic behind this is.

The original change to bridgeit.js to default to a post capture form post seems to have been added with this checkin, but no reasons were documented as to why this was needed:

Repository Revision Date User Message
ICEsoft Public SVN Repository #37032 Thu Jul 18 17:19:04 MDT 2013 ted.goddard refresh page if response does not contain local data (MOBI-827)
Files Changed
Commit graph MODIFY /icemobile/trunk/icemobile/jsf/components/component/resources/org.icefaces.component.util/component.js

Testing removing the automatic form post did not show any serious side effects on Android. Neither normal push nor cloud push was working locally though, so that would still need to be retested with the proper configuration. Some components may need to be refactored though. With IF-EE-2, Camera was not automatically updating the thumbnail even though the callback is firing and the thumbnail is being passed back to the web page. Most other components show no feedback when returning successfully, so we should consider adding js callbacks to update a capturedLabel on the button or something similar.

All other platforms will have to be tested as well. Including the Javascript demos.

Note that original issues with the mobi:thumbnail were eventually resolved via ICE-10536, negating the need for this fix to resolve that issue.

However, there is still a network bandwidth and performance issue due to the fact that the bridgeit.js submit that occurs when a picture or movie is captured send the image/video content to the server (for no apparent reason, since it isn't decoded), and then, when the application submits the form the component is in the image/movie data is again submitted to the server, but this time it is decoded. Thus, it would be beneficial if the initial server submit being triggered by bridgeit.js could be avoided via configuration.