0
Fixed

Built-in Preview window making several requests at the same time

Miguel 3 years ago in iPad updated 3 years ago 13

I am using the built-in preview to check my remote code after I upload it to the server. I do this periodically. Recently I started to notice that if I do it very often after a while my server started to reply with 508. I checked the logs and it seems the AppleWebKit is making several requests at once instead of just 1 normal request. The more I use it seems the more requests it makes. it seems it goes back to normal if kill Textastic and open it again. I suspect the Preview window is not getting killed properly and is running on the background.

GOOD, I'M SATISFIED
Satisfaction mark by Miguel 3 years ago

I am using Textastic 9.5

+1

I am writing a PWA. I.notice after closing the preview window to examine my code, that many of the 'Alerts' in my code keep 'popping up' on the code screen, even though to my knowledge the program has stopped running as I tapped DONE after running the code, and assume the program stops running. But as Miguel suggest, maybe the code is still executing or is still running in the background. In order to continue editing my code I have to close multiple alert windows that have their origin in my program code. After doing this I can continue editing code as expected. BTW thanks for a great code editor. Textastic is fantastic!

I also have seen what Doug reported when I added an alert to a javascript hence why I suspected the window was not getting closed from previous sessions. Sometimes I would have to close the alert several multiple times. This a bit more serious when using a shared hosting where the Entry Process limit is set to 30 or 20 making you hit the limit quite easily and getting 508s from the backend. This needs a quick fix.

+1
Under review

Thanks, I'll look into it and will try to reproduce the problem.

Any luck reproducing the problem? As someone suggested the best way might be to just add an alert() window in JS. You’ll notice it will start popping up more than once after using the preview window for a while. Thanks for the lovely app!

+1

I too would like to support Miguel's request for prioritizing attention being directed to fixing this 'bug'. Miguel was the OP who brought attention to this 'bug'. Textastic is an incredible app, and I would venture to say that for the iPad the ONLY app one needs to consider for editing code on an iPad. JavaScript must be one of the most frequently used languages by people editing code in Textastic, and I suspect other coders feel a bit of understandable frustration when coming across this bug. As I had previously mentioned above, I think it should be reproducible by adding some Alerts to the js testing code, and then multiple uses of the preview window should do the trick. I also find that after closing the program/code using the DONE button, and returning to re-run the program again after a period of several uses of the preview window, or even after just a 'time delay' that multiple pop ups of the alert windows in my program occur without any solicitation on my part, and after individually closing each appearance of the alert window (which seems to be the same alert each time?) the Textastic editor returns to its normal expected (fantastic) behaviour. There must be a ton of work required by Alexander and team? to maintaining this app...but rest assured that all that effort IS REALLY APPRECIATED BY TEXTASTIC'S DEVOTED USERS who depend on Textastic to keep the iPad in the forefront of usability for coding on iOS! WELL DONE Alex!


Thank you again Alexander for a FANTASTIC app!

Doug

+1

Using Textastic 9.5, iPad Pro 9.7" iOS 14.3

Thanks for reminding me. I'll try finding out more this week.

Fixed

I found the problem: Textastic's web preview view controller and the contained WKWebView instance was never freed and continued to run in the background because of a retain cycle:

The preview view controller registered itself as a JavaScript message handler for the web view to handle console log calls. Apparently WebKit creates a strong reference to script message handlers, so when the preview was closed, the preview view controller and, as a consequence, the web view was in fact never released and JavaScript continued to run in the background.

I fixed this retain cycle now, so that the all web view resources and script handlers are freed when tapping the Done button.

I'll prepare a new release.

+1

WOW, and THANKYOU! As a Textastic devotee I am really pleased that Alex was able to confirm, and fix the above issue! I have multiple iterations of event handlers and frequent use of console.log calls and alerts for troubleshooting and so my current Java script code was quite vulnerable to being bothered by WebKit not being nice to TEXTASTIC’S 'Done' button.  Thank you to  Miguel also for bringing this issue to light, as it would never have occurred to me that some debugging issues I was having related to WebKit and not my own amateurish code! Thank you again Alexander for sleuthing this out and fixing it! Rest assured that all of us iOS/ iPad devoted Textastic coders out there REALLY APPRECIATE all the work you do in bringing us Textastic!


Doug D.

The new version 9.5.1 includes the bug fix and should be available on the App Store now.

Please let me know if this does indeed fix the problem.

Thanks for the quick fix. I already updated the app but I have not tried it yet. I will give it a try later today or tomorrow.

+1

I have not done a lot of testing but seems fixed. I am no longer hitting the Entry Process of my shared hosting which was happening quite often before (the limit is 20 so I only had to open/close the window 20 times). Thanks again for fixing it and for the amazing app. Keep up the good work.