sorted by: recent | see :
popular
Content Tagged with User:alex + Firefox
Firefox needs a kick in the pants
For some reason or another, despite millions pouring in and heavy sponsorship by Google, the Firefox project has ceased gaining market share for the past 6 months.
According to the w3c’s browser usage statistics, in December of last year, Firefox had “24.0%” share.
This past month of June, Firefox has increased their share to “24.9%” – less than a percentage difference.
By the way, every 6 months previously Firefox was increasing their share by around 5 percent.
Less than 1% feels like progress has ceased. To my dismay, I’ve started even in SWiK’s traffic numbers to see an erosion of Firefox users, with IE users slowly creeping towards the majority.
What happened? Most likely a less than revolutionary last release: 1.5. Here is the graph of Firefox searches on Google:
The last data point (F) is the release of 1.5. The release made improvements, no doubt, but Firefox needs to work harder if they want to beat the entrenched IE.
And there is a lot of room for improvement. One of the biggest complaints since 1.5 has been a perception of increased memory usage, which has been shrugged off by the Firefox development team as ‘by design’. But they aren’t looking at the real problem, which is that Firefox is still way too slow and bulky compared with IE.
The marketing of Firefox is all wrong as well. Firefox has spent a lot of time and effort on user videos and posters, but really they have saturated the market for people who will be influenced by those. They now need to focus on winning developers, because developers are the ones who can carry the torch forward with Firefox by building killer applications that IE just isn’t capable of rendering.
And there’s no need to be evil about it, or lock people in to Firefox, there’s so much in open standards that IE doesn’t support you could drive a truck through it. IE is at a natural disadvantage when it comes to playing towards developers, because Microsoft can’t afford to lose Win32 developers to the Web.
Google lobbies against Microsoft Search Bar
A new article in the New York Times today reveals that Google is now lobbying in Washington to stop Microsoft from including MSN search functionality in the upper right of their upcoming IE7 browser.
The new browser includes a search box in the upper-right corner that is typically set up to send users to Microsoft’s MSN search service. Google contends that this puts Microsoft in a position to unfairly grab Web traffic and advertising dollars from its competitors.
Google seems to consider Microsoft’s previous monopoly convictions an ace in the hole they can use in competition with the lumbering giant that is Microsoft.
What’s interesting though is that Google has their own monopoly in search that they are happy to exploit to gain market share. Virtually everyone now searches through Google, and Google uses that fact to advertise their other services – and dictate to web sites how they should lay out their content to avoid being blacklisted from Google.
While Microsoft is obviously nefarious, Google has their own browsers that default to their search engine, namely Firefox, Opera, Camino and Safari—plus others I’m sure.
In the middle of this heating up ‘search defaults’ war, poor Yahoo just has Flock.
Rocky Shoals of Ajax Development
A year ago, I started a list of Ajax Mistakes that grew and eventually moved to a collaborative page, where other people could post or edit what they saw as issues in Ajax development.
That list focuses on basic application design mistakes when working with Ajax, such as breaking the back button and using GET and POST requests improperly.
But the specifics of Ajax development are equally perilous to basic application design. The siren’s call of the XMLHTTPRequest object can lead many brave scripters to a demise on the rocky shoals of browser limitations and bugs.
So in the interests of charting out these limitations and bugs, I’ve started another list devoted to these limitations, quirks, and bugs. It’s separated into 3 parts: Basic Browsers, IE, and Firefox.
Again, this post will live on in a collaborative wiki page for future updates.
Basic Browser quirks and limitations
- XMLHttpRequest can’t access remote servers. For some odd reason, although there are ways in javascript to send and receive data to remote servers, such as through script or iframe elements, XMLHTTPRequest cannot have a remote server as a target. This is a basic cross browser security rule that may not be immediately obvious to the newcomer to Ajax development.
- Multiple Ajax Requests are not fired in order. IE, breaking from a long tradition of ignoring independent standards, chooses to follow the HTTP 1.1 RFC 2616 to the letter, which means that IE may only have two XMLHTTPRequests open at a time; after which IE will retain an internal queue of requests which will be serviced in no particular order. Even if the requests are fired in order, the nature of the internet dictates that they will not be received in order, so never write code that assumes xmlhttprequests will be sent in a particular order.
- Firefox also has a similar albeit more liberal limitation in the number of simultaneous xmlhttprequests that may be open; however In Firefox 1.5, the developer may modify the priority of the internal request queue.
- Asynchronous XMLHTTPRequests responses will arrive in no particular order. As implied by the word Asynchronous, XMLHTTPRequest responses may arrive at any time in an unpredictable order that is ignorant of developer intent, happily executing callbacks in the random order in which they eventually wind up on the client.
- XMLHTTPRequest does not requires the use of XML. While Ajax is aptly named when it comes to asynchronous execution, it is poorly named when it comes to XML. The XMLHTTPRequest object has a useful method called responseText that delivers the straight text of the response, be it XML, JSON or just simple unadorned text. Using JSON or simple text can be much faster, easier, and more concise than XML.
- Ajax uses UTF-8. Normal forms are sent using the encoding of the parent page. Thus a SJIS encoded page will default to sending form content encoded in SJIS. Ajax submitted forms on the other hand will be sent as UTF-8. If for some strange reason, UTF-8 is not the character set of choice for the server, this will require a solution such as the server recognizing and translating UTF-8 responses to a desired character encoding.
- Ajax requests are url encoded. A bug relating to this can currently be seen on Digg.com. Submit a comment to digg, and then edit the comment to include a unicode character. The updated comment, sent via Ajax will be added to the database as the url encoded string: resulting in an odd looking url encoded comment.
- XMLHTTPRequest cannot transmit files. In a javascript heavy application, a developer might need to include the ability to send files without completely refreshing the page. XMLHTTPRequest however does not include this ability. Instead, a hidden iframe can be used to send the file, and Javascript can simply inspect the iframe. Ajax techniques can further complement this, for example the open source project Uber-Uploader can show a progress bar while uploading a file.
Firefox quirks or bugs
- Synchronous XMLHTTPRequests lock up Firefox. The XMLHTTPRequest method provides a third argument, which defines whether the Ajax requests are submitted synchronously or asynchronously. (xmlhttprequest.open(‘GET’, ‘http://www.mozilla.org/’, false);) On Firefox, setting this value to false will submit the xmlhttprequest synchronously and lock up the entire browser.
IE quirks or bugs
- XMLHTTPRequest Objects are not reused in IE. Unless the abort method is used, XMLHTTPRequest objects in IE won’t function after the first use, unlike in other browsers such as Firefox. A solution to this is to create a new XMLHTTPRequest object for each connection, although some fear this causes memory leaks, there seems to be no conclusive proof of this, as long as the known closures memory leak issue is avoided, as detailed in the next gotcha.
- IE doesn’t use cached images when Javascript inserts HTML with images. This is a general Javascript behavior, but with Ajax heavy applications that insert a lot of HTML snippets, this can lead to a lot of unnecessary image redownloading. The way to solve this is to send all images with proper Cache-Control, ETag, and Last-Modified headers. IE will request images with a ‘If-Modified-Since’ header and the server should send back a 304 header which will tell IE not to redownload the image, and use its cached image.
- Closures with circular references in IE cause memory leaks. It’s common in Ajax to use closures, however in IE if a closure has a circular reference, it will cause IE to start leaking memory. In Javascript it’s easy to create closures with circular references, so care should be taken to avoid memory leaks.
- Avoiding aggressive caching in IE – even with proper ‘no-cache’ headers, IE caches get requests – this can be solved by changing the get request query string with every request.
- IE corrupts gzipped javascript files. Although this is a more general issue with IE’s handling of gzipped content, in Ajax applications where there is a lot of Javascript, developers may be tempted to gzip their javascript to allow for faster page loading and lowered bandwidth consumption. However IE has a known bug where it cuts off downloads in mid-file, corrupting the javascript file.
- IE doesn’t cache gzipped Javascript files. Adding to IE’s poor handling of gzipped content is IE’s lack of support for simultaneous gzip and ETag cache headers. Again, this is wider scope than simply Javascript, but it means that even if IE didn’t corrupt the gzipped javascript, it wouldn’t cache it anyways.
I sometimes make mistakes, or overlook things. If you know of something that I’ve overlooked or have found something that I’m wrong about in this post, please contribute your knowledge directly to the wiki page for this list.
Further reading
Create keyword searches in FireFox
There’s a really easy way to create keyword searches in Firefox, but it’s hidden away in a context menu where you might never find it.
If you are in a search box, right click and select ‘add keyword for this search’
after that, you can just type the word in your location bar, and your custom search will execute. Super easy, but kind of hard to find if you gloss over the context menus.