Safari Web Extension Storage Callbacks in the Wrong Order
“In a Safari web extension on both macOS 12 and iOS 15 (I filed this bug under Mac because there was no cross-platform category), if you call
storage.local.setand thenstorage.local.get, the callbacks are called in the opposite order, and indeed the opposite order from Chrome and Firefox extensions. Attached is a sample Xcode project demonstrating the bug.”[…]
By design, Safari web extensions use the same cross-platform API as Chrome and Firefox extensions so that extension developers can share code across browsers and easily port their extensions to Safari from other browsers. Thus, a behavioral difference between Safari and the other browsers means that extension developers can’t share code, defeating the fundamental design of Safari web extensions. For this reason alone, I would argue that the behavior of Safari extension storage callbacks is a bug and not a feature.
This is far from the first time I’ve seen the “Works as currently designed” response for Apple.
Previously:
3 Comments RSS · Twitter
When I find a bug that affects both macOS and iOS (and I can be arsed to file a report), I always file it against iOS because it's clearly the platform Apple cares about most.
"When I find a bug that affects both macOS and iOS (and I can be arsed to file a report), I always file it against iOS because it's clearly the platform Apple cares about most."
In most cases, I agree. In this case, I don't think it makes a difference, because I know that the Safari extension team is cross-platform. Also, on iOS there are no Chrome extensions, and only very limited Firefox extensions, so the cross-browser comparison is much easier on Mac.
“This is far from the first time I’ve seen the “Works as currently designed” response for Apple.” - my latest one is that they say that having a Product ID of 0x0000 on the keyboard on the M2 MacBook Air is working as designed. Sigh. Sure, it doesn't screw anything up for their code, who cares if it violates the USB HID specs?
