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

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.