Skip to content

Conversation

@jordanpwood
Copy link

This change allows WebViewJavascriptBridge to send messages across the bridge without using setTimeout. This can lead to a significant performance improvement for the time it takes to send a message to and get a response from the Javascript code. I have observed at least a 10x improvement in many of my calls. However, it also makes the app hang if you use pop-up windows from the Javascript code. Therefore, this feature is only turned on if [self.bridge disableJavscriptAlertBoxSafetyTimeout:YES] is called or the disableAlertSafety flag on bridge.init is set to true.

@marcuswestin marcuswestin mentioned this pull request Jul 29, 2015
@lokimeyburg
Copy link
Collaborator

Hey @jordanpwood! I'm reviewing your PR and it looks good. Good call on making it "opt-in". I wasn't able to test out what you said about "app hangs if you use pop-up windows from the Javascript". I'm putting alert() calls everywhere without luck. Perhaps I'm missing something. Can you explain how I might be able to test that out?

@jordanpwood
Copy link
Author

@lokimeyburg, I can't seem to replicate the issue in the example app. However, in our app which uses WVJSB, when I put an alert in the javascript called by the bridge call handler (set up with bridge.registerHandler), it hangs on the alert if we set disableAlertSafety to true in bridge.init, doesn't hang if it is set to false. I am not sure what the difference between the two implementations is. @karlbecker, would you have any ideas about what could be different?

@marcuswestin
Copy link
Owner

Hi everyone! Wanted to give a quick update and add some notes:

  1. When ObjC calls javascript in a UIWebView, and the javascript uses any synchronous API which causes an OS-level UI to appear (e.g alert & confirm) then the main app's main thread will freeze. (This actually makes complete sense :) Objc calls into JS on the main thread, which is also the UI thread; the JS, running on the main thread, then creates an OS-native modal box with e.g alert(), and then blocks. The problem is that since that at this point the main thread is blocking/froze - since the JS is running on the main thread - but all UI events are also handled by the main thread in iOS! And so, the main thread deadlocks).

  2. I've made a bunch of improvements in master, but some of them are not backwards compatible. Thus, I plan to take advantage of the next release and improve the API a bit. One of the intended changes is to remove the default handler, and only use named handlers. The only change will be to include "options" during setup, e.g to disable alert safety, perhaps add timeouts to requests (Implemented timeouts. #106), etc.

  3. So... My plan is to delay this PR just a bit longer, but then merge it in after the next release. I hope this sounds good to everyone! If not, let me know :)

Cheers!

@marcuswestin marcuswestin self-assigned this Jan 29, 2016
@marcuswestin marcuswestin force-pushed the master branch 2 times, most recently from 23327d5 to 42bd969 Compare January 29, 2016 03:58
@marcuswestin
Copy link
Owner

Merged in through squashed commit 63d55ef in PR #215.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants