New WebKit Features in Safari 11.1 | Hacker News Reader

New WebKit Features in Safari 11.1

webkit.org

99 pointsalwillis33 comments

All these new features, but HTML5 audio is still utterly busted on iOS Safari[0]. So much so that my music player PWA is essentially unusable on iOS Safari.

Bug filed here[1], simple repro here[2].

I appreciate that service worker is here. I appreciate that they are making progress on PWA support. It's good to see. But there are some longstanding HTML5 issues in the browser that need to be fixed. Would really appreciate some Apple devs solving it; the fix is conceptually simple: fire HTML5 audio .ended event when audio finishes playing, even if the screen is off or app is in the background.

[0]: http://debuggerdotbreak.judahgabriel.com/2016/12/13/its-almo...

[1]: https://bugs.webkit.org/show_bug.cgi?id=173332

[2]: https://bitshuvafiles01.com/iOSAudioBugRepro/audioError.html

Agreed. Making microphone input work in iOS Safari was a nightmare. The AudioContext has to be started in response to a tap, but the tap on the permissions dialog to grant microphone access doesn't count.

And, it still doesn't work on iPod Touch, because for some reason Safari there claims it doesn't have a microphone. (It does.)

I can't resolve the domain debuggerdotbreak.judahgabriel.com

Really? It's working fine here...

Now it's working. Did you change something? I tested against both @1.1.1.1 and @8.8.8.8 when I filed my comment and both (at the time) said the domain didn't exist.

Perhaps you have flaky authoritative nameservers?

The security model for service workers looks interesting. Will other browsers do similar things?

"A service worker registered by an example.com iframe inside a webkit.org page will be able to communicate to all service workers and clients that share the same (webkit.org, example.com) partition, but not to any other example.com or webkit.org client. A network load made by a (webkit.org, example.com) service worker will use the same cookies as if the network load was made in an example.com frame embedded in a webkit.org page. Similarly, private browsing mode is enforced in a service worker by partitioning service workers according the browsing session."

https://webkit.org/blog/8090/workers-at-your-service/

Really nice to see service worker in Safari. Now all major browsers support at least the bare minimum of SW - we'll see a big improvement in the web landscape though that :)

Also note Apple has added PWA support in iOS 11.3

https://medium.com/@firt/progressive-web-apps-on-ios-are-her...

Unfortunately, their PWA "add to homescreen" feature is so bad, it's unusable. I've had to tell my users not to add to the homescreen.

For example: sending a PWA to background causes it to die. For my music player app, this is a showstopper; the audio stops playing.

Bringing the PWA to the foreground causes a full refresh. Again, showstopper for my PWA.

Also a PWA which is "added to homescreen" actually LOSES access to at least some APIs (I know for a fact that getUserMedia is disabled when a page is added to a home screen).

This led to us needing to tell our users to NEVER add the page to the homescreen (pwa or otherwise) or the app will stop working, which confused many and made other suspicious (IMO rightly so, that's such a fucking weird thing to have to specify!)

This is really frustrating to me. Why are PWAs second class citizens when it comes to getUserMedia? Why is Apple perfectly happy to cripple websites when a user has specifically pinned it to the home screen, but allows full featured access in the browser?

Are they really worried mobile websites will overthrow the App Store in popularity?

Sometimes I really feel Safari is the new IE.

So in talking with some Safari engineers a while back when iOS 11 first came out, they say it's a technical limitation (Safari is a somewhat different codebase than the "web views" are on iOS, the webViews being more integrated into the OS), and technically an app added to the homescreen is run in a webView.

That being said, it does really suck, and it's something they NEED to get solved before the possibility of taking Safari and iOS seriously in the web-app space happens.

>Unfortunately, their PWA "add to homescreen" feature is so bad, it's unusable.

As it relates to audio apps -- not generally.

Well, it does limit use cases to applications that (a) don't need any background activity and (b) don't need to maintain stateful network connections. Granted, (b) is an issue for native iOS apps, too, but it's something I find mildly frustrating.

I'm not sure what's actually new there. You've been able to 'install' full-screen web pages to the home screen with a custom icon since before iOS 2.0 and the original app store.

The capabilities have grown over time as Safari on iOS supports more PWA features, but the article seems to be framing this as a new ability to install apps, when that isn't very new at all.

Service workers provide way more capabilities than just creating a shortcut. Google’s doc[1] provides a good introduction, but essentially you get things like push notifications and background sync in a cross-compatible way (chrome, Firefox, Edge, and now Safari). I’m particularly excited about the caches and sync APIs, which allows sites to be rendered and be interactive even when you’re offline or have a flaky connection.

1: https://developers.google.com/web/fundamentals/primers/servi...

Safari for iOS doesn't support background sync or push notifications.

I don't think Mobile Safari has push notification support yet.

It’s relatively poor. The pinafore.social mastodon app doesn’t work as a PWA in iOS at all because redirecting to a mastodon insance for authentication switches back to the browser, and cookies aren’t shared between the Safari app and PWAs.

I think `font-display: optional` is going to nice if sites actually use it - try to use the fancy font, but only if it's cached. Never hide the text or switch the font after rendering it.

Of course, there are going to be plenty of sites that still consider their fancy font to be more important than the actual text it's rendering...

It would be nice to have web API permissions so that users could disable some of these, e.g. Beacon on a global or per-site basis. The OS infrastructure already exists for mobile app permissions.

If you turn off Beacon, sites will just fall back to XHR/Fetch/redirect and performance will suffer.

Will we ever have a way to tell the browser engine to shrink images to some maximum dimensions before uploading them to the server, without javascript?

Is there any work being done in that direction? Javascript implementations like Pica - http://nodeca.github.io/pica/demo/ are slow even with wasm. It'd also be nice not to rely on javascript for such fundamental things.

Wouldn't that be pretty trivial with just a <canvas> element?

use the `drawImage` function to draw the image scaled to whatever size you want, then just call any of the APIs that you want to get either ImageData, a base64-encoded-URI, or a PNG Blob resized.

The exact method of resize is up to the useragent (IIRC i could be wrong on this), and it's done in "native" code, not in javascript.

png would be huge (since it is lossless) and jpg would incur double compression (source jpg and re-compressed from canvas) losing quality.

Is there any solution other than those 2 options?

Any resizing of a jpg to another jpg is going to incur double compression isn't it? Sure there are ways of mitigating it using various sampling and resizing algorithms, but it's not going to be perfect, and there is no "one-size-fits-all" best algorithm.

What would a "browser API" provide that you can't already get with canvas?The only thing I can think of is customizable resize algorithms, but I'd rather have the option to change that for a canvas, rather than a specific "resize this image API".

I was a long time safari user, but I stopped taking safari seriously when they started requiring you be an apple developer to create an extension - $99/year to even make one for yourself.

Apple is trying to create a closed ecosystem with the browser and I for one will not just let that go. Add all the features you want! You'll be treated like IE until you start playing nice with others.

Happy to see sub resource integrity and directory/clipboard API.

>The Styles sidebar in the Elements tab was reworked to use a different, but familiar model for editing style rules, properties and values. It also features improvements in navigating between different style views.

Does this mean they’ll finally go back to the style tag entry they used to use - the same one Chrome uses today? That would be a great help!

Looks like they have, yes.

>WebKit in Safari now supports loading H.264 encoded MP4 video with an HTML tag.

I was confused by this sentence, but it actually says "HTML <IMG> tag" (the "<IMG>" part of the text is unescaped, and does not render). Meaning you can use <img src="video.mp4">

"But we already have <video> and animated webP and..." is addresed in depth in the linked article: https://calendar.perfplanet.com/2017/animated-gif-without-th...

I was thinking about this the other day, in the best case scenario, we are only 5 years away from a patent free H.264 codec. And we finally have something to truly replace GIF.

I wonder what other things we could do to H.264 to further improve the standard while aiming to be patents free within a foreseeable time frame. And act As the baseline of the web to move forward.

Thanks for posting this. I highly recommend people read the linked article - interesting discussion into how browser's work in general.

Reply on news.ycombinator.com