Details
-
Type: Bug
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: BridgeIt 1.0.5
-
Fix Version/s: BridgeIt 2.0
-
Component/s: BridgeIt
-
Labels:None
-
Environment:Bridgeit 1.0.5, ICEfaces EE 4.0
Description
We need to know why BridgeIt.js is triggering a submit--allowing components to encode (without user submitting the form), clobbering possible callbacks when services like camera and scan return from capturing data.
If this is a required behaviour, then the callback should be reworked to be triggered last (onafterupdate of the bridgeIt submit? rather than the hashchange event?) so the current workaround in the mobi components of using a none-deterministic timeout can be removed. Testing of showcase on slower networks that have larger latency than the timeouts will also show this issue.
If this is a required behaviour, then the callback should be reworked to be triggered last (onafterupdate of the bridgeIt submit? rather than the hashchange event?) so the current workaround in the mobi components of using a none-deterministic timeout can be removed. Testing of showcase on slower networks that have larger latency than the timeouts will also show this issue.
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.