Tired of Safari

http://www.quirksmode.org/blog/archives/2015/02/tired_of_safari.html

by robin_reala • 11 years ago

283 119 11 years ago

0x0• 11 years ago

(Mobile) Safari is well under way to become the new IE6, especially for older iOS devices that do not receive further updates. :(

TazeTSchnitzel8• 11 years ago

"New IE6"? It gets new features.

FreakyT• 11 years ago

As that comment pointed out, once Apple decides that your device is "obsolete", it stops getting updates, so there are plenty of still-used iOS devices that will never have their Webkit versions updated.

Personally, I suspect this lack of updates has less to do with actual obsoleteness and more to do with ensuring that you always buy the latest device. (Note that this isn't a problem unique to Apple -- many companies, including many Android OEMs, are even worse about it. I honestly feel like it should be illegal to sell hardware and never update it, but I'm really not sure how something like that could be enforced.)

s_kilk• 11 years ago

I think the point is that whatever features it doesn't get will be a millstone around developers necks for years to come, much like the situation with IE6.

You'll be held back from using new web features widely because a significant chunk of the audience has a browser which won't support them.

pjmlp4• 11 years ago

Pretty much it.

Basically it is history repeating itself.

Companies embraced IE 6 because it was quite good when it came out, they love to target single browsers and thus we deserved what we got.

Younger developer generations bashed about IE6 all the time, embraced the Webkit gods, with the excuse that it is open source, forgetting that it doesn't matter if the user cannot update the browser.

So here we are, with Webkit being the new IE 6.

taf23• 11 years ago

Thanks to Google and Android it's not anywhere near as bad as IE6. Apple is not 99% of the market and that is exactly what Android was designed to ensure.

JohnTHaller2• 11 years ago

But, just like on Windows, you can install an alternative brows... oh... right.

legulere2• 11 years ago

This is a pretty ridiculous claim considering that iPhones get updates for four years while android devices get updates for less then two years.

tuananh• 11 years ago

Sponsored by IE.

Just saying.

maaaats• 11 years ago

Sponsored by Google

Right next to your citation.

melicerte• 11 years ago

Quoted from the homepage: "QuirksMode.org is the prime source for browser compatibility information on the Internet. It is maintained by Peter-Paul Koch, mobile platform strategist in Amsterdam, the Netherlands."

bhouston3• 11 years ago

I don't think that is undermines the importance of this post, but at least he is upfront about potential conflicts of interest.

panzi2• 11 years ago

While their browser really is subpar, Microsoft did contribute some important technologies to the web. E.g. AJAX (XMLHttpRequest) and (the precursor to) HTML5 Drag and Drop.

bsimpson2• 11 years ago

If AJAX was any good, we wouldn't need the Fetch API. It was only embraced because the web had literally no was to programaticly download assets before that.

tmzt• 11 years ago

Loading collapsed subtopics on MSDN was pretty awesome, first place I saw XMLHttpRequest in use. I remember tearing into that and duplicating it in Perl on my webhost.

lars• 11 years ago

Repeating what I said in previous thread: There are real problems with the Touch Events spec, and we need a replacement. One issue is that it is under specified w.r.t its compatibility with mouse events. A concrete example: Should the touchmove event trigger the mousemove event? I believe it does in IE and Firefox, while it does not in Chrome and Safari. This isn't specified anywhere, and can make it incredibly complex to implement something that works with both mouse and touch input. And it is exactly this type of thing that Pointer Events sets out to fix.

This is exactly the same story as with the <meta name="viewport"> tag. Apple did something without releasing a spec, and the others made not-fully compatible copies. That was 8 years ago. No exaggeration: Right now the only(!) thing that works consistently cross platform is setting width=device-width. It is insane, and it hurts the web.

TazeTSchnitzel8• 11 years ago

For whatever reason, despite all the standardisation out there, DOM input always has been this massive cross-browser incompatible inconsistent proprietary clusterfuck. quirksmode.org may be known to some of you as this guy's blog, but it is best known for its DOM event compatibility tables, which somehow still matter in 2015.

If browser vendors cannot fix mouse and keyboard, why would they fix touch?

gsnedders2• 11 years ago

A lot of time has been sunk into trying to fix keyboard especially, but it's a horrible, horrible mess — pretty much whatever you do will break websites, given so many do if (UAx) expect_behaviour_x() else if (UAy) expect_behaviour_y() etc., so even standardising on existing behaviour doesn't work. Then there's fact that some of it is down to locales and what the current keymap is… :(

bonn16• 11 years ago

It's obvious that Apple slowed down innovating the web since the core of their business is iOS and apps. They shouldn't have any interest in a fast innovating web that gets on par with native apps which is their main lock-in for iOS, just like Microsoft 15 years ago. They only speed up their rendering engine and JS core but don't try to help on standards improving the web experience.

BUT: I doubt this pointer event thing is a good example for their reluctance because it's really just a nice-to-have feature for the Surface and the Note series which is for my taste a too small target to justify a standard.

A good example for Apple reluctance to innovate the web is CSS Flexbox. CSS Flexbox is the best positioning standard I encountered, every vendor supports it, only Apple still prefixes it with -webkit.

Another example is their reluctance to make WKWebview fully workable, since months there is still a bug which prevents WKWebview loading local files, the bug was already fixed in an early beta of iOS 8 but then they put it again in. WKWebKit is way more performant than UIWebview and can produce butter smooth HTML5 apps with Cordova/Phonegap but this one bug makes it hard (people already build local web servers to work around this problem).

EDIT/ADDITION: A third and probably the most obvious indication that Apple doesn't want innovation in the browser space is their ban on 3rd party browsers on iOS. Benjaminjackman articulated this well in this thread below: "And yet here we are 15 years later and the iOS platform is doing just that, Apple is embracing this Microsoft strategy and extending it to a whole new level by flat out banning 3rd party browsers and so we all run the risk of having this great renaissance in browser application innovation extinguished into a second dark age."

bhouston3• 11 years ago

It's obvious that Apple slowed down innovating the web since the core of their business is iOS and apps. They shouldn't have any interest in a fast innovating web that gets on par with native apps which is their main lock-in for iOS

I worry about this regarding Google as well. Both Apple and Google benefit from App lockin. :/

NOTE: You can downvote me, but web apps are secondary on mobile -- remember all those Chrome apps people have on the desktop, they are not treated the same as Andriod Apps on mobile, even though they could be.

emodendroket• 11 years ago

Really? Google is still the company behind Chromebooks, Docs, Gmail, and other attempts to replace desktop apps with Web stuff.

TazeTSchnitzel8• 11 years ago

I doubt it's intentional malice. I think it's just Apple's engineers being spread too thin.

Before Blink, they had Google's manpower also helping them. Now that's gone.

Flexbox will come, it'll just take Apple a while to implement it.

matthewmacleod3• 11 years ago

Flexbox will come, it'll just take Apple a while to implement it.

Flexbox is already fully implemented in Safari and has been since 6.1. The only difference is the use of a prefix.

notthetup• 11 years ago

I have heard of a similar reasoning for Apple not supporting WebRTC.

matthewmacleod3• 11 years ago

It's obvious that Apple slowed down innovating the web since the core of their business is iOS and apps

No, it's not at all obvious, and the objections you've raised do not support your view at all.

CSS Flexbox is the best positioning standard I encountered, every vendor supports it, only Apple still prefixes it with -webkit

That's a really pedantic objection — prefixing CSS standards which aren't actually finished is exactly what prefixing is for. It's hardly an anti-web move to keep it prefixed, and anybody who wants to use it can already do so with minimal additional effort.

Another example is their reluctance to make WKWebview fully workable

I find that argument very suspect, since Apple could easily just not have released WKWebView in the first place if they wanted to prevent it's use.

TazeTSchnitzel8• 11 years ago

Apple only has finite resources, too. I doubt WKWebView is neglected, they may just be focussing on fixing something else.

bonn16• 11 years ago

... the objections you've raised do not support your view at all.

No reason to get emotional.

That's a really pedantic objection —

Pedantic? Positioning elements is the most important feature of a layout system and CSS is totally broken in this regards, just try to vertical center something. Flexbox is godsend and finalized—every vendor removed the prefix. Wondering who is pedantic.

Apple could easily just not have released WKWebView

The pressure they got for five years that they offer just the 10x slower UIWebview and give Safari the WKWebkit was the main reason and maybe they just released WKWebview to make the impression that they play along. This one bug makes WKWebview utterly useless.

However, would love to keep the tone in this discussion on a friendly level.

technojunkie2• 11 years ago

No, it's not at all obvious, and the objections you've raised do not support your view at all.

One could argue that the browser has matured to a point where, technically, they slowed down the innovation of Safari on all platforms. If you look at the amount of features introduced in every new version of the last few years, it is less. iOS7 Safari is a notable exception but Safari has not kept up with innovation that they once had.

prefixing CSS standards which aren't actually finished is exactly what prefixing is for.

Pedantic is Apple purposely lagging behind over said unfinished standards when the rest of the industry has moved on. Vendor prefixes are tedious for web developers to keep up with and tools such as Autoprefixer were forced to be developed b/c of them. Webkit has been unprefixed for ~6 months now and Safari and iOS have both seen updates since then without this change. This should be unacceptable and if there are still reasons to include it Apple needs to be way more transparent.

I'm not anti-Apple by any means, sitting here writing this on my MacBook Pro, but pressure on Apple to get their act together is absolutely warranted and needed to promote standards based design and development which will make a better User Experience for all.

sirn3• 11 years ago

CSS Flexbox is the best positioning standard I encountered, every vendor supports it, only Apple still prefixes it with -webkit.

Flexbox has been unprefixed in WebKit r173579[1][2]. Presumably, it will be available when Apple release the next version of Safari. Reading the Bugzilla, the reason of not unprefixing the feature seems to be lack of contributors on WebKit's part than anything.

[1] http://trac.webkit.org/changeset/173579

[2] https://bugs.webkit.org/show_bug.cgi?id=98420

bonn16• 11 years ago

Presumably, it will be available when Apple release the next version of Safari

How do you know? It's was unprefixed already ~3 months ago, so why should it happen with the next release? And when does the next release come? And why do their release cycles are not as short as those from Chrome or Firefox?

Because it's not their core business.

... to be lack of contributors on WebKit's part than anything.

Exactly what I wrote: Apple is focussing on other stuff than the web because—again—it's not their core business. They have two browsers, mobile Safari and desktop Safari and none of them got this important upgrade yet. A fast innovating web isn't in Apple's favor.

jasonsync• 11 years ago

How about Apple's refusal to fix blob URL download support?

https://github.com/eligrey/FileSaver.js/issues/12

BinaryIdiot2• 11 years ago

BUT: I doubt this pointer event thing is a good example for their reluctance because it's really just a nice-to-have feature for the Surface and the Note series which is for my taste a too small target to justify a standard.

This is inaccurate. The pointer events standard allows you to avoid the 300ms delay mobile / touch screen browsers have and is useful across all devices. Without it you have to continue using hacks to prevent the delay.

bonn16• 11 years ago

This is inaccurate. Nowadays, the 300ms goes already away if you set the meta viewport tag with width=device-width etc [1]

[1] http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-a...

electic• 11 years ago

It is quite simple. I have a few friends who work for Apple and they are exhausted. They don't have time to fix everything and they don't simply hire in mass because they believe in quality. A lot of these issues will not get fixed anytime soon at this rate. So you are right. Safari is starting to get neglected but it is not for the reasons you think.

pas• 11 years ago

Then they missed that mark with IndexedDB: https://news.ycombinator.com/item?id=9106752

bitdev• 11 years ago

Am I missing something? Banning 3rd party browsers?

Isn't there chrome for iOS, as well as atomic web browser? Just off the top of my head. Maybe others, for all I know.

orkoden• 11 years ago

They all use the same rendering engine as Safari though.

yoz-y2• 11 years ago

Judging from the comment thread on the Chromium tracker issue it does not look like people over at Google are any more eager to implement this than Apple is.

dimillian2• 11 years ago

If only there was a better/faster mobile browser than Safari. The fact is there isn't, true, Google is not allowed to have its own version of Webkit/blink on iOS, but is Chrome Android better/as reliable as Safari?

bhouston3• 11 years ago

Chrome on Android is pretty decent and fast I find.

Spoom• 11 years ago

is Chrome Android better/as reliable as Safari?

As a mobile web developer, yes, mobile Chrome is way better.

Mahn• 11 years ago

but is Chrome Android better/as reliable as Safari?

Absolutely, not sure what would make you think otherwise. Older versions (a year or two ago) used to have some minor inconveniences ocasionally, such as scrolling lag after using it for a while, but that was ironed out long ago. Chrome for Android is my main mobile browser and by and large the "app" I spend the most time with while on the go, and currently I have zero complains. It's fast, it's responsive and it gets the job done without getting on the way.

the_gipsy• 11 years ago

Also, apple only allows using the UIWebView, so Chrome for iOS is just safari's engine with a better interface: https://developer.chrome.com/multidevice/ios/overview And in previous iOS releases, the UIWebView had a significantly worse performance than safari: http://daringfireball.net/2011/03/nitro_ios_43

Both cases are explained as security measures. But they are coincidentally degrading web applications' performance, which benefits Apple's app store revenue.

TazeTSchnitzel8• 11 years ago

iOS added WKWebView.

dimillian2• 11 years ago

WKWebview is good for a very simple in app link opener, if you want to do a full featured browser around it (Chrome iOS), the public API is nowhere near ready for that.

evadne• 11 years ago

https://code.google.com/p/chromium/issues/detail?id=423444

jcampbell1• 11 years ago

IIRC, pointer events require an huge amount of hit testing, and don't deal with bypassing the CPU to do smooth scrolling. Pointer events are a good solution for the future, but I understand why Google and Apple aren't pushing it, as they make phones where performance is more critical.

streptomycin2• 11 years ago

Another example: they ignored IndexedDB for a couple years after every other major browser implemented it. Then they finally got around to releasing a version of Safari with IndexedDB support... and it's just hilariously broken in so many ways http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-B...

I literally cannot fathom how such a horribly buggy release could be made in good faith. It's like nobody even tried to test it or use it before releasing it.

So, conspiracy theory time: They're doing all this to cripple web apps and force people to write native apps. This conspiracy theory also fits in nicely with how they won't let you run other web browsers on iOS, which would make the deficiencies of Safari somewhat less problematic.

TazeTSchnitzel8• 11 years ago

It came late and it was buggy.

That rarely means malice. That usually means overstretched engineers.

hawleyal• 11 years ago

QED It's not a priority for them, which is the point.

streptomycin2• 11 years ago

It came years late and was laughably buggy. And 6 months later it's still laughably buggy.

There are plenty of pre-written tests used by the other browser vendors that would have shown them it's shit before they released it. Or they could have just tried using some websites that use IndexedDB and noticed that basically all of them broke in their browser.

That means malice, horrible incompetence, or horrible management. I doubt it's incompetence. It could be horrible management. But it's just so bad that you can't help but think about malice...

throwaway41597• 11 years ago

And there's the slow release cycle. It was common during the previous decade because of the stagnation of standards, but now that standards release early and often, it really shows their unwillingness to keep up.

When bugs ship with the first version of their implementation, it's really frustrating to have to wait for up to a year to see the fix go to users.

bluerobotcat• 11 years ago

Meanwhile Chrome and IE still don't support MathML. Now that is annoying.

QuantumRoar3• 11 years ago

Is MathML actually widely used? I can't believe anyone would really want to use something else than the LaTeX stuff for typesetting formulas. There's nothing as pretty as LaTeX for that.

Recently I wrote a small tool that enables me to write LaTeX code directly in HTML and the tool then renders the LaTeX code in PDF, converts it to SVG and places an appropriate img-tag with the reference to the generated SVG. I was under the assumption that most people do it kind of that way.

Or let me ask another way: Is there a reason to prefer MathML over using SVGs created with the LaTeX rendering engine?

jfb2• 11 years ago

Or let me ask another way: Is there a reason to prefer MathML over using SVGs created with the LaTeX rendering engine?

Accessibility?

dragonwriter• 11 years ago

Or let me ask another way: Is there a reason to prefer MathML over using SVGs created with the LaTeX rendering engine?

At least for MathML "Content Markup", it is semantic rather than presentational, so as well as being rendered as an equation, it could, in principal, be usefully processed in other ways.

bzbarsky• 11 years ago

Some reasons to prefer MathML:

1) Working find-in-page that lets you search equations too.

2) Ability to select, copy, paste the math bits.

3) Better accessibility. LaTeX in alt text is something, but actual semantic markup would allow the UA to present things to the user the way the user wants more easily (e.g. without having to re-parse the LaTeX).

4) Ease of editing and reuse (c.f. view source).

5) Ease of styling (e.g. you can use colors to highlight parts of an equation as needed and change it dynamically; some teaching sites put this to very good use).

Note that there do exist LaTeX to MathML converters, so you can still author in LaTeX if you want and export to MathML.

euroclydon• 11 years ago

Desktop Safari sucks too.

It has good battery life on a Mac, but tends to crash frequently for me.

The thing I hate the most though is this: On the favorites bar, click a folder to drop it down, now click another folder while the first is still dropped down -- nothing! I'm not even asking to be able to drag my pointer to the next folder and have it expand, but that would be even better.

ghawkescs• 11 years ago

Mobile Safari crashes all the time on my iPad Air as well. A lot of the time it is even on well-known sites like The Verge (granted, some of this is on the web site creator).

legulere2• 11 years ago

In fullscreen mode drag a tab somewhere so that a new window gets created. This new window will have some vertical offset broken and can't be fixed by anything you do (black stripe on the bottom in fullscreen mode, lots of strange behaviour)

_lce0• 11 years ago

  If you want to help, please star _this_ issue in the Chromium bug tracker and make some noise

* https://code.google.com/p/chromium/issues/detail?id=162757

ebbv2• 11 years ago

I was really on board with this article until I got to this:

Although he is right in a literal sense, I do not think we should exaggerate the problem. Clueless web devs will be clueless (and they’re mostly blinded by iFever anyway)

So the author is saying that most clueless devs are rabid Apple fans? This is so ridiculous to the point of doing nothing but making the author look bad.

Yes, Apple is behaving badly with regards to this spec. All large companies have behaved badly with regard to Open Web Standards at one point or another. Let's pressure Apple to get on board with the Open Standard just like we have to pressure all other companies who are on the wrong side of this battle. It's not the first time it won't be the last time.

Taking it personally is not productive.

riquito• 11 years ago

You missed the context

creating a second bunch of events to do essentially the same as touch events would put undue pressure on web developers, since they would now have to code to two standards

He's talking about the fact that the devs that have problems with this are "clueless" and will be saved by someone else that does the hard part for them (write a unified interface)

ebbv2• 11 years ago

I did not miss the context. I read the article. I was not objecting to his characterization of devs being clueless. There are lots of clueless devs in the world. In my experience it's >50% of devs.

What I objected to was the absurd claim that "most" clueless devs have "iFrenzy." When obviously in reality, there's clueless Apple fans and clueless Apple haters and clueless everyone in-between.

Making such a, frankly, stupid assertion undermined the entirety of his post.

thrillgore• 11 years ago

And Google has now closed discussion on the issue tracker, as linked to by PPK. https://code.google.com/p/chromium/issues/detail?id=162757

It got salty but not to the extent that merited this being closed. It looks like this will remain closed and wontfix for the immediate time being.

emehrkay• 11 years ago

Interesting twist in this article. I've seen a lot of praise for his writing style (inverted pyramid) on HN, but that Google portion came out of nowhere. He is understandably upset that Apple is slowing down progress, but doesn't seem as upset that Google is doing the same thing.

pornel• 11 years ago

To me more worrying is Apple's complete silence on Service Worker: https://jakearchibald.github.io/isserviceworkerready/

I agree with sentiment of the article, but I don't care about PointerEvents in particular. Good UI needs to have separate code paths for touch and mouse anyway, e.g. swiping with a mouse feels stupid.

For trivial stuff TouchEvents already simulate mouse events and every new technology will — these events are our common compatibility layer already.

TouchEvents are a bit of a mess, but it's fixable and it's being worked on, e.g. standardising simulated mouse events, removing click delay, adding ability to prevent scroll from any touchmove event.

TouchEvents even sometimes nicer to work with, e.g. touchend will be fired on the same element that received touchstart (there are edge cases in there, but I've never ran into them), while this is not guaranteed with pointerup, so it's easy to write bad code that causes dragged elements become "sticky".

gsnedders2• 11 years ago

Apple are frequently silent on things until they start to implement them. They almost never promise to implement things until they are almost done.

madsravn• 11 years ago

On the subject of things I'm tired about. That website uses 448 px for the main content. For me that is 448 px of 1905 px. That's not even a quarter of my screen. Why in the world would you do something like this?

ickwabe• 11 years ago

A few arguments:

http://www.humanfactors.com/newsletters/optimal_line_length....

http://www.ninjapost.com/blog/on-the-importance-of-narrow-co...

http://socialtriggers.com/perfect-content-width/

munsoji2• 11 years ago

As a developer who spent the last few months trying to get a website with touch events to work on the surface 3, I need to get this off my chest.

Microsoft, make up your mind. Do you want a browser that websites 'just work' in or do you want to keep implementing broken standards and forcing other browsers to adopt them? Pick one and don't try to find some weird middle ground where you implement webkit touch events on ie11 mobile but not desktop even though you want us to treat them as the same browser. I'm also looking at you, pointermove events that don't ever give you x and y values other than 0. You tell us you want us to do feature detection instead of browser detection, but how am I supposed to do that when window.pointerEnabled is true for all instances of ie11 even though I don't want to register touch events when I know the user is using a mouse? Before you respond with "you should just be listening for pointer events and not worry about type", you've just asked me to make my site incompatible with every other browser on the market instead of making it slower on ie11 by registering lots of unnecessary event listeners.

Microsoft, it's over. I'm moving on, and don't try to pretend like you can change with project spartan.

JoeAltmaier• 11 years ago

A bug, and an extra event listener? That's enough to drive you mad? Sorry, that seems pretty mild. I understand getting wound up after spending too much time figuring out an issue. Maybe walk away from it for an hour, get a cup of something, vent on HN. Oh! That's what you're doing.

taf23• 11 years ago

Here's the thing this is just one example of one issue of thousands. And at the end of the day the difference is with Mozilla and Chromium I can jump on irc and talk directly to the people working on those browsers and get their advice for the best way to work around a current issue. I can get insight into whether a fix is in progress and I can vent my frustrations. I can also rest easy knowing that in 1-3 months a fix is likely to arrive... For IE this is all none- existent. The original comment is spot on IMO about the state of Microsoft and IE. Safari, has it's issues and I wish Apple would innovate faster but at least the core of Safari is open via Webkit and similar to Mozilla and Chromium I have someone to reach out to... I have nothing from MS/IE - I don't even target that browser anymore. If a customer complains about the site not working - it means either.

a. they're on Window XP and no worth the trouble.

b. they just need to open chrome.

And yes - this is a much better web than we had with MS/IE

munsoji2• 11 years ago

Maybe not enough to drive one mad on an intuitive, functional device, but enough to push one over the edge when debugging on a surface. I feel like I'm being tasked with drawing an idyllic landscape on a grain of rice with only a box of crayons, in that while it will be impressive to the .01% of users that might see it the other 99.99% will never notice nor appreciate the effort.

eridius• 11 years ago

Comments like

(and they’re mostly blinded by iFever anyway)

do nothing but make the author look bad and make many readers (such as myself) inclined to discount the entire piece. It's really disappointing to see something like this in an article that otherwise has a legitimate point.

bsimpson2• 11 years ago

I understand the frustration behind Google abandoning Pointer Events, but they have good reasons for doing so. For years, one of the bars to get a new feature added to Chrome has been "Does this increase or maintain performance?" For Pointer Events, they determined the answer was "no" because of the extra hit testing it requires, and they refuse to regress performance on the web.

My primary input device has been a stylus for over a decade, so I'd love to see unified input support on the web, but with all the talk of getting to 60 FPS, I can understand why a spec that contradicts that isn't being implemented.

https://code.google.com/p/chromium/issues/detail?id=162757#c...

vardump• 11 years ago

Tired of Safari, but for different reasons. Mobile Safari is probably the biggest reason I don't want to use iPad or iPhone. No reflow of text after zoom, and I don't want to move back and forth right and left to read larger size text. Very useful when reading while walking or when website text is just too small. Reading list doesn't replace good zoom text reflow.

I have an iPhone, but I use it so rarely it's sometimes out of battery for weeks. I guess it's too "one size fits all" device to me. Some things are deceptively nice in it, it's smooth... but it doesn't respect my wishes.

Using Opera on Android instead. Perfect mobile browser for a mobile phone after enabling flow option in the settings (Text wrap).

Another app I couldn't live without is f.lux or equivalent. I wish iOS could have it without jailbreak.

Tired of Safari

Related Stories