Blog
RS2012 DOM Page Leak Fix
NOTE: do not contact Real Software about this bug. They have already addressed it. The fix will be available in 2013r1. If you experience any problems with this code, please contact me, NOT Real Software.
When you close a web page in Real Studio WE 2012 the div element for the page is not removed from the client browser DOM. This results in a memory leak on the client browser and presents a potential security issue. On a public computer someone could see previously displayed WE pages even if the previous user has logged out.
A quick and simple work around is to reset the Session whenever a user logs out. To do this simply call ShowURL with your web app’s address on log out. However, this does not work if the app disconnects before log out or if the user forgets to log out.
I’m releasing a class under the BSD license, SessionTD, which fixes both issues. When you close a page, SessionTD removes the page from the DOM. And it loads JavaScript which clears the DOM in the event that the app disconnects.
WebLink and Styles = WebLinkTD
It was recently noted on the Real Software Forums that when you set the Style of a WebLink not all of the attributes take hold. I quickly checked Web Custom Controls and discovered that WebStyleTD and WebStyleExt had the same issue. The fix will be available in the next release (1.3.1).
The fix was relatively simple, so I decided to make a subclass of WebLink with a similar fix for Real Studio WE users who do not have a license to Web Custom Controls. You can download the WebLinkTD class by clicking here.
To use it:
- Add the WebLinkTD class to your project.
- Change the Super of your WebLink controls to WebLinkTD.
- If you assign styles in code, use WebLinkTD.StyleTD instead of WebLink.Style.
This class is released under a BSD license and is free to use. I’ve tested it on 2011r3 and 2012r2.1.
Please note that in fixing this I discovered another issue with WebLinks: once a link has been visited it will display in the visited color even on hover and click. This is not due to the WebLinkTD class. I think I know what’s going on and will report this in Feedback, and possibly try to patch this as well in a later version of WebLinkTD.
Getting back into the swing of things…
I know it’s been two months since the last update. My intention has been to deliver 1-2 updates per month, and I have several new controls pending completion. I hate to publish personal issues or have work dragged down by them, but I have a health issue that has impacted my work, especially in November. Not a major issue (thankfully). But something that limited my time in front of my Mac. Think chiropractor type issues.
I’m starting to work the kinks out and am able to return to a normal work pattern. I’m going to be working on releasing a bug fix update this week, and an update with at least one significant new control next week.
My apologies to those I’ve talked to personally about various bugs and feature/control requests. I know you’re waiting, and I appreciate your patience. Things should be back on track shortly.
Reporting Bugs with Web Custom Control Projects
Just a quick note: if you encounter a problem in a project which uses Web Custom Controls or any of the freeware code I post on this blog:
- If the problem is clearly related to Web Custom Controls, please contact me directly and do not contact Real Software or file a feedback report. I don’t want Real Software staff to have to sort through problems that are part of my toolkit and are therefore my responsibility to fix. If the problem is ultimately due to a Realbasic issue, I can confirm it and file a feedback report.
- If the problem appears to be unrelated to Web Custom Controls, please verify this before contacting Real Software or filing a feedback report. You can do this by creating a separate test project which does not include Web Custom Controls and replicating the problem there. You should have such a test project for a feedback report any way as it helps Real Software staff to quickly identify the problem. Once you have this, go ahead and contact Real Software. If you don’t have time to do this, please contact me first so that I can evaluate whether or not the problem has anything to do with Web Custom Controls.
I don’t consider this a major problem, but it has come to my attention that a user reported a bug to Real Software that should have come to me. I want to make sure this does not happen in the future as it wastes their time and delays the fix.
Using Web Custom Controls with Real Studio 2012
I’ve had user reports of problems using Web Custom Controls 1.3 with Real Studio 2012. Basically after you add the control classes to a project some controls cannot be dragged onto a web page. It appears that the 2012 IDE is having trouble resolving the parent classes for some controls. The same thing can happen if you open an older project with Web Custom Controls in 2012 and Web Custom Controls is an external item or you make it an external item.
I can replicate the errors and have filed a Feedback report. For now there are two ways to work around the issue:
- Instead of dragging the Web Custom Controls folder into your project from disk, open the demo project and copy/paste the folder from the demo project to your project. After you’ve done this, do not make any items in Web Custom Controls external. This is the easiest work around.
- Optionally, you can drag Web Custom Controls >> Core, then Web Custom Controls >> jQuery Controls >> jQueryBase, then the rest of the controls into your project. This requires more steps but also seems to work. I wanted to mention it just in case the first work around doesn’t work for any users. Again, I recommend leaving all Web Custom Control items internal to the project.
If you have any problems getting Web Custom Controls working in RS2012, please contact me for assistance.
CLEditor and Safari 5 for Mac
A quick note that CLEditor on Safari 5 for Mac (and possibly earlier) does not function correctly. The scroll bar does not work, and if you scroll using the cursor the text becomes garbled on screen. No other browser, including Safari for Windows, exhibits this behavior.
This is a bug in Safari 5 for Mac that shows up in some (not all) CLEditor configurations. I do not believe that there is a way to work around it. The solution is to upgrade to Safari 6.
I wish I had a better answer. But I literally spent a couple days looking for a work around for this one before releasing 1.3, and I found none.
Squashing bugs…
I’m working on a 1.3.1 update to address some issues that have come up with 1.3. Namely…
jQueryFileUpload – Add Files… button does not work in Windows FireFox.
2012r1 CGI – if the web browser cache is empty, the controls will sometimes take forever (i.e. 10-15s) to load. Naturally I didn’t see this during the 2012 beta period. I’m not sure where WE is hanging or why it is intermittent. Unfortunately I don’t know if this is one I can fix or work around, or if it will become a Feedback item.
Animation Timing – mainly a demo issue, but some users have reported that the demo animations jump quite a bit, and also that the introduction animation doesn’t always fire. That said, I can only make animation so smooth. Even with entirely client side JavaScript web browser animation is not perfectly smooth. This is because JavaScript timers are not preemptive and not guaranteed to fire at fixed intervals. (Funny how we are reliving the same issues in web browsers that we saw on desktop OSes in the early days. Remember Mac OS classic cooperative multitasking?)
I should also note that one person has reported JavaScript errors with jCanvas, but I can’t reproduce them. I’m trying to find time to do a remote session and see what’s going on. If you encounter this, please let me know.