Tag: Bugs

Safari vs. WordPress 6.7 Block Editor: Who’s to blame for forced PNG-to-HEIC conversion?

Look at this image:

Now look at this one:

What if I told you those were the same image? Well… I mean… they’re not. Obviously. But they’re supposed to be. They were both the same image when they were on my computer. The same exact file. But I uploaded them to this page in two slightly different ways, and that made all the difference.

The one on top — the screwed-up one — I placed by inserting an Image block in the WordPress Block Editor, and then clicking the Upload button in that block, navigating my hard drive, and locating the image. The one on the bottom, I placed by again inserting an Image block, but this time I just dragged the image from a Finder window into the Safari window. WordPress supports drag-and-drop uploads.

Looking “under the hood,” I discovered that the file on top was somehow getting converted to Apple’s “High Efficiency Image Format,” HEIC (the reason for the C instead of an F is something I’ll leave to the Apple podcasters). WordPress just added HEIC support in version 6.7, which was released this week. Since browsers (other than Safari, I assume) can’t display HEIC images, WordPress automatically converts uploaded HEIC files to JPEG. And that’s why these two images look different. JPEG doesn’t support transparency, so the areas that were transparent in the original PNG got flooded with the nearest available colors¹.

But, why should the results of these two upload processes be any different?

Well, after starting in the WordPress Support Forums and then moving over to the Make WordPress Core Trac and finally searching until I stumbled upon a year-old, barely active thread on the Apple Developer Forums, I discovered that Safari has a bug — I mean it has to be a bug, right? — where, if a file upload input field says it accepts HEIC format, Safari automatically converts the uploaded file to that format, apparently with no option not to do that. (I looked around all of the settings, even the developer ones, and didn’t see anything about this “feature” at all.)

And sure enough, WordPress 6.7 is a bit haphazard with its “support” of HEIC uploads, which made it easier to confirm the cause. There are two ways, generally speaking, that WordPress handles file uploads: the browser upload, via an <input type="file"> HTML field, and a JavaScript/AJAX/React/whatever drag-and-drop option.

The <input type="file"> field in the Image block of the Block Editor has added HEIC support via the accept="image/heic" attribute. But the input field in the old school Media Library upload page has not been similarly updated. (It’s become a fact of life in the WordPress world that most of the core team’s attention is on Block Editor stuff these days, and older features get ignored.) Uploading images in the Media Library does not do the conversion. Likewise, whatever exactly is going on with the drag-and-drop method also does not involve the accept="image/heic" attribute that causes Safari to do its mischief.

Unfortunately, it looks like the only “solution” at this point would be for WordPress to do a browser sniff and remove the accept="image/heic" attribute if the browser is Safari. The only reason that was explicitly added was to get Chrome to support HEIC uploads; as I understand it, Safari would support them regardless, but explicitly declaring HEIC support is apparently what triggers Safari to make the conversion.

So, practically speaking, Safari users who want to upload PNGs to their WordPress sites just need to be sure to only upload via drag-and-drop, or the Media Library.

(I haven’t tested, but I suspect JPEG uploads are likewise getting converted to HEIC and then back to JPEG, which probably results in a reduction of image quality.)

Side note on how I discovered this in the first place: Two days ago I was writing another blog post somewhat critical of Apple, and I found when I was trying to upload a screenshot of a window from my Mac — Mac screenshots are saved as transparent PNGs — the transparency was turning black. I was so driven to distraction over the situation that I barely managed to finish writing the post.

¹ Saying those areas are flooded with color is an oversimplification. It looks like the color of each pixel is being determined consistently with how PNG compression works.

What’s that close paren doing after my video embed in WordPress?

Working on a new client site that has a lot of YouTube video embeds, I was alarmed this morning to find a stray close paren ) character in all of the posts right after the videos.

Knowing I had recently been tampering with the embed_handler_html and embed_oembed_html filters in the site theme, I figured it was something I had created. So I set about debugging my code but couldn’t get anywhere.

I decided to see if it was in fact a new problem in WordPress itself, by setting up a test post on this site with a YouTube video embed (this, of course). Sure enough, even on my unadulterated theme, the stray close paren appears.

I mean, just look at it!!!

Anyway, I hope/assume this will get fixed in the WordPress core soon, but in the meantime if you are running into this problem and want a quick fix, and you’re not afraid of editing the functions.php file in your theme, have a go at this little addition that will strip out the offending punctuation:

function embed_fix_stray_parens($content) {
return str_replace('</iframe>)','</iframe>',$content);
}
add_filter('the_content','embed_fix_stray_parens');

Update #1: I went to submit a bug report to the WordPress development team and found my report was a duplicate of this one. If I understand correctly, the close paren is actually being delivered by YouTube itself, not WordPress, via the oEmbed request. Isn’t the Internet fun?

Update #2: This really is YouTube’s problem… it even shows up in the embed code you get on their own site:

This issue is also showing up on StackOverflow now, including a more efficient temporary workaround for WordPress sites than my own hasty solution.

My (just-discovered) workaround to the WebKit letter-spacing bug

Update (5/29/2012): Upon working further with the project that formed the basis of this post, I discovered that my solution did not work, or at least, no longer worked. It’s not uncommon as I get deeper into a project with a large CSS file that there are subtle, inadvertent effects of the various CSS properties that get added along the way. Looking back now, I can’t determine for sure whether my solution did once work with the simpler version of the site, and something else I added later counteracted it, or if I was just too eager about a solution to realize it never quite worked in the first place. As a result, I had considered deleting this post entirely, but I have decided to leave it live, to further the discussion of the topic, or at the very least to serve as a monument to my challenges.

WebKit, the rendering engine “under the hood” in both Safari and Chrome, has a known issue handling the CSS letter-spacing property at certain small increments, and at certain font sizes.

Specifically, if defining letter-spacing in increments smaller than 1px or 0.1em, it seems to just ignore the property altogether… except at larger-than-default sizes.

I typically use em or % these days to define text sizes in CSS. So in my situation, I’ve found that my letter-spacing: 0.05em works if I also specify font-size: 125% (or larger), but if I have font-size set to 100% or less, the letter-spacing gets ignored.

Typically, after loading reset.css, I set a baseline font size for the document with body { font-size: 100%; } (or some size… actually it’s usually 80% but these days I’ve been leaning towards larger type).

I decided to play around with this a bit to see if I could resolve the letter-spacing issue, and I found a nice, easy solution that works at least for the particular site I’m currently testing it on. Your experience may vary, depending on how your HTML is structured and how complex your design is.

Here’s the solution:

body {
  font-size: 125%;
  letter-spacing: 0.05em;
  line-height: 1.3em;
}

body>* {
  font-size: 85%;
  line-height: 1.3em;
}

You may want to adjust the exact values of font-size to suit your needs. (And, yes, I’m aware that mathematically 125% and 85% don’t cancel each other out, but they’re close enough for my purposes.) It’s important to include the line-height property in body>* to define your target line height; otherwise your lines will be too far apart. Set it to whatever your ideal value is. (I usually prefer line-height: 1.5em personally, but for larger type, as on the site I’m currently working on, it gets too spaced-out.)

So what’s going on here? Well, strangely, it seems WebKit can actually render smaller type with line-spacing less than 1px or 0.1em just fine, but it won’t unless somewhere in the “cascade” the type has been defined as being a certain amount larger than 100%. I don’t get it, but until the bug (which it seems clearly to be after all of this) gets fixed, at least this seems to be a reasonably clean workaround.

It’s very important that you use body>* and not just body *. If you don’t know why, well… try it out and see. (The upshot: we’re applying a uniform scaling-down across the board on all elements directly under body, which is practically the same as just defining our target font size directly on body itself, but with the benefit of working around the letter-spacing bug.)

Note: I have only tested this using em as the unit of measure for letter-spacing. I’m aware of the issue with px as well, but I’m not sure this solution will work for that. But… really… just use em instead!

Why does Safari 4 Beta take SOOOOO LOOOONG to start up? Am I the only one having this problem?

I downloaded and began using the new Safari 4 Beta the day Apple released it. I’ve complained (mostly on Twitter) about various aspects of it, things that I’ve now (more or less) gotten used to: most significantly the still-awkward title bar tabs.

But one thing I haven’t gotten used to is the ridiculous amount of time Safari 4 Beta takes to get up and running, at least for me. The window appears promptly after clicking on the icon, but then I’m visited by the dreaded spinning beach ball of death. This situation endures for at least a minute or two (if anything, I am exaggerating that time down), and then things proceed as normal.

At first I thought maybe it was something peculiar about my own site (even though it loads just fine in other browsers, including Safari 3), which I have set to load as the home page. But I just waited out Safari’s ridiculous start-up time, then went into the preferences and set it to load with a blank page. And it still took just as long, not even loading anything from the Internet. So clearly it’s just something in the internal workings of the app itself.

I have not seen anything anywhere about this issue. Everyone seems to love Safari to death, and says nothing about its speed other than how blazing fast it is. I guess it’s pretty snappy once it gets going, but for me all I can think about is this ridiculous load time at the beginning.

And so, this humble blog post shall serve as a beacon in the darkness, calling out to all those who suffer as I do (oh, such suffering) from an inexcusable lag at the start-up of Safari 4 Beta.

For what it’s worth, I’m running a stock black MacBook purchased just last August (right before Apple retired them, of course), 2 GB of RAM, Mac OS X 10.5.6. In other words, this should not be happening.

Also, for what it’s worth, once Safari has gotten going, my site loads very fast… less than a second on my cable connection. So it’s definitely not something with my site (thankfully, since I can’t imagine what it would have been).

SimCity for iPhone: ASOD (Advisor Screen of Death)

I was ecstatic when I discovered SimCity for iPhone. It is, without a doubt, the best “deep” game for the iPhone that I’ve encountered. (Stuff like Bejeweled is great too, but they’re in a completely different league.)

I have long been a fan of the SimCity series. I haven’t really played SimCity 4 much, mainly because it seems that with each new version, ~~Maxis~~ EA gives the Mac version less and less attention. Or, more accurately, they give MacKiev even less time and a stingier budget to do the port from the PC version. So, it’s bloated and sluggish and slow. But for me, SimCity 3000 was great, and that is the edition that was the basis for the iPhone version.

I love it. It is unbelievable that they could pull off something like this on the iPhone, but they did it. Mostly. It’s great, but it’s buggy.

The worst bug I’ve encountered, twice now, happens occasionally when clicking one of the advisor links in the news ticker at the bottom of the screen. What you get is… ugh… this:

Sim City Advisor Screen of Death (ASOD)

In the spirit of the classic Windows 95 BSOD, I’m calling this bug the ASOD: Advisor Screen of Death. I have no experience with iPhone programming, but I suspect that the text you see is the variable names or some kind of parsed placeholder text where the actual advisor message is supposed to appear. Unfortunately, not only is the text not being properly loaded, the actions for the buttons aren’t, either, meaning that once this appears, there’s no way to make it go away… at least, no way other than clicking the iPhone’s Home button, which does a fine job of returning you to the home screen… but it quits SimCity in the process, and if you hadn’t saved in, say, the entire amount of time you had just been playing the game, it can be incredibly frustrating.

So… if you like SimCity and you own an iPhone or iPod Touch, by all means, buy this game. You will enjoy it immensely. Just remember two things:

1. Save. Often.
2. Think twice. Skip advice. (Or at least approach your advisors through the “…” menu instead of the ticker.)

Update: A few other bugs, or at least flaws, I’ve noticed: the city’s population seems to fluctuate wildly from month to month, with no logical explanation; demand for the different zones seems to bear no relation whatsoever to the tax rates for those zones, but almost seems to just follow an arbitrary pattern of ebb and flow; and the budget numbers do not adjust month-to-month, making it really hard to track current revenue levels. Maybe this last one is the same in the computer version too, but the budget seems to require a lot more close attention on the iPhone.