Hello.

Debugging web pages on the Nokia 8110 (KaiOS) can be tricky due to the lack of traditional developer tools. This post outlines the steps I used to successfully debug, involving enabling Developer Mode on the phone, forwarding a port using adb, and connecting to the phone's runtime via Firefox 48's Web IDE.

In this follow-up post, I've revised my blog's Service Worker and caching strategy to address previous issues, particularly the Firefox incompatibility due to the use of waitUntil and a misunderstanding of cache.put. The updated strategy now correctly fetches from the network, caches the result, and serves content from the cache, falling back to the network request if not found. The code has also been improved for readability and reliability.

I needed to figure out how to monitor events on an element (like when a field is autofilled) and Chrome DevTools has a monitorEvents function, but Firefox doesn't. Since I couldn't find an equivalent in Firefox DevTools, I created my own JavaScript function that iterates through an element's properties, finds event listeners (e.g., "onclick"), extracts the event name (e.g., "click"), and attaches a console logger to each event. The code snippet and a corresponding gist are provided.

I've updated DeliTag. Currently, it only supports Del.icio.us integration with Firefox. To enable broader compatibility, I'm actively seeking proxy scripts for SIMPY and SHADOWS.

I've just added a new feature to my website! Now, you can easily tag any page (except the main page) with relevant keywords and submit them directly to Del.icio.us. Just select the text, click "Generate Tags," choose the tags you want, enter your Del.icio.us credentials, and hit "Submit Tags." It's all AJAX-powered for a smooth experience. Currently works in IE6 and above, with Firefox compatibility coming soon. Try it out on this post!

This post kicks off documenting the requirements for the next version of AJAXTagger. The goal is to create a successful application (by my definition) by outlining features across functional areas, UI/UX, client/server-side business logic, data access, and dependencies. Key features include easy journal tagging, related information retrieval (tags, articles, blogs, websites), diverse search provider integration, streamlined results presentation, image inclusion, and efficient article pulling/saving. The UI should minimize user effort, provide immediate feedback, and offer information hiding. Performance is crucial, targeting IE6/7 and Firefox, with emphasis on minimal server round trips, client-side optimization, and error handling. Data storage is preferably client-side, with external access optimized for speed and resilience. External dependencies include various search engines/services, while internal constraints involve limited server access and reliance on HTML, JavaScript, and XmlHTTPrequest.

In this final part of "The Failures of my First AJAX Application" series, I reflect on the cross-browser compatibility issues I encountered. Focusing on Internet Explorer during development led to problems in Firefox, particularly with security errors (cross-domain data retrieval) and differences in the XML DOM model. The key takeaway is to consider cross-browser support from the outset, anticipating discrepancies between browsers and coding around missing features, similar to CSS development. The next version will prioritize cross-browser compatibility, potentially including Safari. This series has been invaluable for shaping the requirements of the upcoming version.

In part two of this series on the failures of my first AJAX application, I discuss how my initial plan to reduce bandwidth by having the client directly access third-party web services didn't work out. Due to cross-domain scripting issues in Firefox and IE 6/7, I had to implement proxy scripts on my server. This means all client requests now go through my server, increasing my bandwidth demands. While using a proxy server offers benefits like hiding security information (like Technorati developer tokens) and enabling data manipulation/request merging, it comes with the major downside of increased bandwidth usage and the need to create/maintain proxy scripts. I hope to support cross-domain data sources in the next version to mitigate these issues but acknowledge there might still be scenarios where proxy scripts are necessary.

I've been reflecting on the direction of my blog, "C#, .Net Framework." I feel the name is too limiting, given my recent posts on topics like IE7, AJAX, Firefox, and XMLHttpRequest. I plan to broaden the scope while keeping the content technical. I also want to increase reader interaction, possibly by crowdsourcing a new name for the blog.

In part 2 of my AJAX application journey, I'm tackling browser compatibility issues between Firefox and Internet Explorer. Key differences include handling XML node text, event triggers for synchronous XmlHttpRequests, and table object model inconsistencies. Looking ahead, I'm planning to componentize my JavaScript for better management and browser caching, and create an event-driven object model for my next application to improve structure and cross-browser functionality. My focus will be on supporting the lowest common denominator for broader browser compatibility.

My first foray into Ajax was a mixed bag, yielding both valuable lessons and frustrating setbacks. On the plus side, it sparked a deeper understanding of asynchronous coding, cross-browser compatibility (especially between Firefox and IE), and the potential of APIs like Yahoo! and Technorati. It also reignited my interest in Perl and prompted reflection on my blogging practices. However, the application fell short in several areas: it lacked search functionality, didn't reduce bandwidth, had a poor visual design, and wasn't user-friendly or impactful enough to generate feedback or traffic. Moving forward, I'll share my design process and desired improvements, starting with a clear requirements document. I'm eager to learn from this experience and create a more effective application.

I've noticed a difference in how Internet Explorer (versions 6 and 7) and Firefox handle synchronous XmlHttpRequests. In both browsers, you can send requests using JavaScript. However, after the synchronous send() call, Internet Explorer still triggers the onreadystatechange event, while Firefox does not. I need to research which behavior is correct and according to spec. If you happen to know, please email me!

My AJAX application has a minor cross-site data access security issue, similar to one I've encountered in Firefox. A workaround in IE6/7 involves enabling "Access data sources across domains" in Internet Options -> Security -> Custom Level, though this isn't ideal.