Author: Shawn Wilsher

While talking with Edward last night about searching in the download manager, we came across an interesting idea. Instead of trying to guess a good substring of the URI to do a LIKE comparison for searching, we could process it with nsIEffectiveTLDService (there’s no devmo page for this sadly) after we query the DB. We then realized that that is not the most efficient way to do this, so we thought, “Hey, we can add functions to the database! We can just hook up eTLD that way!” Then it dawned on us on just how bad that could get, especially if we implemented that in JS like the download manager’s UI is in. We’d be crossing xpconnect quite a bit, and searches are already kinda slow. As a result, that idea got canned. We started thinking about how it could be done in C++ with the download manager component, which wouldn’t be as bad. That’s when I started to really think about this.

Places does some search stuff with the Awesomebar. I’m not sure if they do some guessing like we were thinking about doing, or if they post process it, or something entirely different. But, what if mozStorage automagically provided functions for you to perform eTLD things on strings in the DB? Storing URI’s in their string form seems to be fairly common in many of our sqlite databases. So, I’m looking to see what people think about providing some SQL functions that make people’s lives easier:

SELECT eTLD_GetPublicSuffix(referrer) AS suffix FROM moz_downloads
Where referrer is a column in the DB that stores an nsIURI. I don’t find this one so useful, but…

SELECT eTLD_GetBaseDomain(referrer, 1) AS referrer_search FROM moz_downloads WHERE referrer_search LIKE ?1
Again, with referrer being a column in the DB that stores an nsIURI. In this case, if the uri were “http://mxr.mozilla.org/seamonkey/source/netwerk/dns/public/nsIEffectiveTLDService.idl”, it’d return mxr.mozilla.org, and that is what would be searched by the LIKE expression. I can see this being potentially useful to many consumers, so I’m putting out feelers to see what people’s thoughts are. What do you think?

The Cookie Monster I was talking about previously has been spotted! Tracking and squishing him is currently being done in Bug 403372. It turns out that cookies were expiring based on their creation time instead of last accessed time. The details can be found in the bug. Congrats to Dan for tracking this down, and thanks to everyone that helped out! Hopefully we’ll get a fix before the next beta!

Have you been having your brower’s cookies just seem to disappear when they didn’t used to (in say, Firefox 2)? A few others and I have noticed this, but we haven’t figured out what is up yet. After talking to Dan Witte, the cookie module owner, we still don’t know what’s up. However, if you’ve been seeing this strange and unsettling behavior, you can help us get to the bottom of it! Dan is looking for cookie logs to see if he can spot the bug. Here’s how you can help:

1. Clear all of your cookies or start with a fresh profile.
2. Enable cookie logging. If anyone knows how to do that on the mac, please add those instructions too!
3. After you enable logging, start your browser, and use it normally. Whenever you think you lost a cookie, there are a couple of things you need to note:
   1. The site that you think lost the cookie.
   2. The day/time you lost the cookie.

   Send that and your log to dwitte at gmail.com and hope for the best!

The more people on this, the more likely we are to find out what’s going on! Your help is greatly appreciated!