Battling data passing issues on an iframe close gadget

by Mike Levin SEO & Datamaster, 02/03/2012

Note: The project I did this work for went public: tiger.360i.com. You can give it a try to see an iframe with a close gadget that’s using inter-window communication to close the iframe.

I figured out an 80/20 rule approach to the fail-safe forced stop of site crawling that I was talking about yesterday. I simply added the link that can force the crawl to stop, which is normally on the close-gadget of the bookmarklet’s pop-up and vulnerable to JavaScript hiccups, to being a clickable link under the config tab, labeled “FORCE STOP”. That should be clear enough, and spares me from making a spreadsheet-based file-lock, which could potentially double the network traffic of the app, checking for the file-lock with each loop iteration, which would probably require grabbing a new document XML feed every time, just to check a single cell value. Okay, well I dodged that bullet. Between yesterday’s squashed bug, and today’s fail-safe FORCE STOP link, Tiger is a big step further towards public consumption.

I only have 15 minutes before my next meeting phone-call, and then only a half-hour of business hours after that. Remember, I leave promptly every day these days because of my 15-month old daughter. I have to size the next thing I try to do appropriately.

Change the messaging from “Would you like to do a quick [sitename] spot check” to “Would you like t o crawl the [sitename] website?”. Okay, done.

Pshwew! The 4:30 meeting was cancelled. Make the most of this found time. 4:30 to 6:00 PM.

Okay, it’s 5:45, and I had a very productive time cleaning up the messaging of Tiger’s pop-up panel. I’ts much more ready for public consumption. I turned off a bunch of the interactive options when beginning a crawl. Advanced users here at the company just just do a one-page crawl, then go into the configuration tab, adjust parameters, and continue the crawl from there. Tiger needs to be fine-tuned to make most people happy most of the time, and to always confer a positive first experience.

But I did encounter a bug as I was going. I fear it’s something I broke yesterday, but that is that in making the close-gadget on the pop-up panel successfully stop question-mark replacement, it no longer stops site-crawls. In hindsight, I am not surprised. What that close gadget is doing is actually rather complex.

Miracle of miracles. I successfully fixed that bug in my last 5 minutes. For those actually curious what the heck I’m talking about, a document has a key which is known if you begin your work in an existing spreadsheet, so feeding that key to a function is easy. But if you begin from a site-crawl, the document is made on the fly and the key is not known, so the close-gadget cannot know what processing to stop until it exists, at which time the close-gadget takes on the key of the newly created document. Ugh! Timing.

And I just tested trying to stop question-mark replacement… not working. Ugh! More debugging tomorrow morning or during the night tonight. I am determined to get this rock-solid!

It’s Friday now. I didn’t get done the debugging that I tried to yesterday. It’s a tricky bit of debugging, because there are so many moving parts. And my work environment is vastly different. At the office, I’m on by Commodore C64x with clicky cherry blue switches and two huge arm-mounted wide-screen monitors. The C64x is running Ubuntu 11.10 Unity with compiz Expose workspaces stacked vertically 3-high. With dual monitors, that’s 6 workspaces with muscle memory dedicated to jumping between these fixed locations with ease. It’s a very nice work environment indeed, except for the fact it’s open offices and headphones and inhuman self-control are the only way to focus enough to program.

At home, I’m on a Macbook Air laptop with a comparatively tiny screen, and Lion’s new horizontal-scrolling full-screens now taking the place of Workspaces. So instead of work’s fixed 2x3 virtual screen grid, it’s on-the-fly horizontally accumulating full-screens that I swipe between with the 3-finger left/right gestures. A three-finger swipe up gives you something like the old Expose heads-up overview from which you can pick up and arrange your virtual screens—which in Mac-land are now getting blended together with the full-screen concept. Echo’s once again of the Amiga computer. If everyone switched tomorow from Oscar Madison windows-style UI’s to Felix Unger full-screen UI’s, it wouldn’t be soon enough for me.

Anyway, that little rant is just on the state of virtual screens gradually replacing windows as a way of organizing and switching between apps. It will be the subject of another article. I feel it is being driven by a combination of the nVidia AMD arms-race that have given almost all computers now enough video-memory, and people in general just being fatigued by and fed up with windowing user interfaces, now that mobile has shown them that there is a better way. Amiga users knew this 25 years ago. Even though the Amiga had its own windowing user interface called Intuition, almost all applications opened their very own full and entire screen, which is what made video RAM such a big issue on Amigas. Most computers swap all alls in and out of the same video memory space, but Amigas let an app have its whole own screen, and just swapped out which was showing on the monitor. That’s the direction all OSes seem to be going these days.

Enough commentary on my work environment. So long as I can work quickly and efficiently wherever I sit down, I will be fine. But it does take getting your mind around these new user interfaces, forming new habits, and committing it all to muscle memory. I guess it’s worth writing about, because you have to be hyper-attuned to what you are doing before it becomes second nature and fades into the background. One way on the Mac laptop. Another way on Ubuntu. Okay, got it. I’m in 3-finger swipe land.

I know that clicking the close-gadget on the pop-up window truly stops a crawl. Interesting! Testing on Chrome, the stop gadget seems to be working in both the case of the question-mark replacement and crawl. What am I missing? It was Firefox on Linux where I was having the inconsistency. Test Firefox on Mac. Yep, confirmed. It’s a Firefox thing. But I’m not wholly surprised, because I’m relying on a querystring value from an iframe that doesn’t actually have that value available to it. It’s actually surprising it works at all from Chrome. This is the whole reason we’re passing messages around with window event listeners. There is no known key at the time the crawl begins, because there is no document created yet for it in Google spreadsheets. Okay… think it through logically.

You need better output. Show what key is being unlocked all the time.

Okay, when the close gadget is clicked, I now always show the key of the document you just closed. I also leave the panel up a little bit longer, and have some messaging about where to look for the FORCE STOP link if Tiger doesn’t stop. It’s time to carry enhanced messaging through a little further and start giving links to the documentation site.

Pshwew! I got everything working correctly. The key was always showing the key on the panel when closing it, so if the baton passing of values broke down, it was immediately apparent. Also, I did a number of cosmetic touches to get it ready for the public.