Tag: bug

Posted on
by

Google Photos is overcompensating for the Daylight Saving Time switch on yesterday’s pictures. Photos taken at 6:00pm are labeled as 7:00pm. Everything from this summer/early fall (which might as well have been summer) is off, in the app anyway (the website shows the right time in PDT), which at least makes more sense than if it had only been one day. The weird thing: it’s not even showing the time in today’s timezone by mistake. It’s adjusting it the other way.

My best guess: There used to be a DST bug in Google Photos, but they adjusted for it. Now the bug’s been fixed, but the adjustment is still there.

Obligatory XKCD link:

Posted on
by

I recently tried to retrofit a mobile layout onto an old table-based site using CSS. It was a fairly simple layout: A banner across the top, two columns, and a footer. I figured I’d use CSS to “unwrap” the table and make the sidebar and main content area into full-width sections instead of side-by-side columns.

In theory this should be simple: CSS handles tables by using the display property and assigning it table, table-row and table-cell for the <table>, <tr> and <td> elements. You can assign these properties to other elements and make them act as tables, or you can assign block or inline to these elements and make the table act like a series of paragraphs.

Initial testing worked perfectly in Firefox 3.6 and Opera 10.5x. Internet Explorer 8, as expected, ignored the changes entirely. Chrome, however, did something very strange, and Safari reacted the same way: The banner shrank, and the columns changed from a narrow sidebar to a 50/50 split…making it actually worse for small screens.

Clearly WebKit didn’t like something I was doing. Unfortunately, WebKit powers the exact platforms I was targeting: the iPhone and Android!

I dug around with the developer tools a bit to see if I could figure out what was going on. Was the browser not applying the property? Were the table cells inheriting the “original” property from somewhere else? Did I need to change properties on thead and tbody as well?

What I found was that WebKit did recognize the display:block I had added, but somehow the computed style was reverting to display:table-cell. This only applied to table and td, though. Table rows actually did what I told them to, which was why the result ended up looking bizarre.

If it hadn’t changed anything, I probably would have chalked it up to the capability just not being implemented yet. But since it worked on table rows, but not on cells, I decided to treat it as a bug in WebKit and went looking for the best way to report it. I ended up creating a WebKit Bugzilla account and reporting it as bug 38527.

Check out the testcase in Firefox 3.6 or Opera 10.5 to see what it should look like, then take a look in Chrome 4 or 5 or Safari 4.

Posted on
by
  • SpamAssassin has been marking mail from 2010 as “grossly in the future.” It’s been fixed in the beta for months, but they issued an emergency update over the holiday. Of course, if they’d done the test by using math instead of pattern matching, it wouldn’t have been an issue in the first place. (via @pobox)
  • It turns out that in the digital age, the average American reads three times as many words today as thirty years ago. (via This Is True)
  • Medal of Honor recipient Ed Freeman has been co-opted by a political disinformation campaign. Remember: any time you receive a political email that asks you to forward it to everyone you know, check the facts first!

Posted on
by

The most annoying thing I’ve had to deal with in Firefox 1.5 is a Linux-only bug in which the first time you do something in a certain class of actions—drag-and-drop, Save As…, and a couple of other things—it will lock up for a period of time (1 second to 30+ seconds, depending on how many tabs & windows you have open), scroll all pages back to the top, and in some cases, bring up an unclickable extra copy of the pop-up menu.

The bug was fixed before Firefox 1.5 was released, but it was too late for the fix to make it in. I actually suspect this bug is one of the reasons that so few Linux distributions have upgraded their built-in Firefox releases to 1.5, though they could always have just added the patch to their build process. Fortunately, Mozilla has decided that it’s worth including in the first bugfix release in the 1.5 series, which is now available for testing. Firefox 1.5.0.1 should be out sometime in the next few weeks.