Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox for iOS on GitHub

github.com

Post reply on HN
Print view View original

81–90 of 145 posts

Re: Firefox for iOS on GitHub

#81

Post by graetzer »

valisystem wrote: post #76
graetzer wrote: post #42

I think it's great that they are going to officially support iOS again. Coincidentally I submitted a new version of my own browser app to the AppStore, on the same day they made the announcement. I added support for the new Firfox sync protocol - it took me forever to get it working and now it's kind of redundant :-/ Anyway, if someone is interested in the source: https://github.com/graetzer/Foxbrowser

Your version is out, their is not, it's whole lot of a difference. Thanks a lot and I'm installing it right away !

Thanks, just to clarify: the new version is still in the review process, the version in the AppStore only works with older Firefox versions.

You will have to install this from source to get the latest version

Re: Firefox for iOS on GitHub

#82

Post by ClashTheBunny »

bgarbiak wrote: post #66
oscargrouch wrote: post #35

Earlier quoted context omitted.

Also, when Chrome was launched, it was the only browser with a multi-process approach to a multi-tab browser world.. Also their approach to threads were right from the beginning, and that converge into a awesome no-lock and no-glitch browsing experience.. After that, every other browser followed them. So, to be fair, Chrome was much more than V8 (which was also a part of its voodoo)

Also, when Chrome was launched, it was the only browser with a multi-process approach to a multi-tab browser world.. Nope, IE8 was: http://blogs.msdn.com/b/ie/archive/2008/03/11/ie8-and-loosel...

Chrome still crashes a few tabs for every process crash. And it feels random the ones that are threads of the same process.

Re: Firefox for iOS on GitHub

#83

Post by orbifold »

jfaat wrote: post #38
cyborgx7 wrote: post #29

Earlier quoted context omitted.

There are other markets than the US and the antitrust laws were employed against Microsoft in the EU.

The US antitrust case[1] referred specifically to browser vendor lock-in. [1] http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp .

As did the European case, ultimately forcing them to give a choice to the user which default browser to download, if I recall correctly.

Re: Firefox for iOS on GitHub

#84

Post by Aissen »

nnethercote wrote: post #58
andyidsinga wrote: post #49

Earlier quoted context omitted.

they could release a firefox with gecko that works on jail broken ios ( or maybe it exists?)

There was one made about four years ago. Hardly anybody used it because hardly anybody jailbreaks their phones.

AFAIK, they never did. They did a launcher application that was sync-compatible to access all you bookmarks, etc.

Re: Firefox for iOS on GitHub

#85

Post by k-mcgrady »

flyosity wrote: post #37

And it's all written in Swift! This is probably the largest application written in Swift so far, and definitely the largest one on GitHub that I've seen. If you're looking to make the transition from Obj-C to Swift (or from any language to Swift) this is probably a solid example to learn from.

According to the GitHub language stats it's only 17% Swift. Nearly 70% C and 6% Objective-C.

Re: Firefox for iOS on GitHub

#86

Post by LeoNatan25 »

blub wrote: post #62
bla2 wrote: post #20

It's a bit sad that Firefox is caving in and shipping a browser using WKWebView. The rationale is that by using WKWebView they now get Nitro, and they have to "go where the users are" -- but a few years ago, it was a lot less clear that Android would be more prevalent than iOS. Also, iOS seems like a fairly hostile environment for 3rd-party browsers since it's not possible to change the system browser -- that's proba…

Besides having access to JIT, being multiprocess, getting the backward/forward swipe for free and finally having a decent way to estimate progress, WKWebView is actually worse than UIWebView and less customizable. UiWebView, as slow as it is permits you to do stuff like saving pages for offline viewing, ad blocking, cookie control and so on. If they use WKWebView I'm not even sure they can implement the features of a…

Some of your concerns are true, others are not. Cache and cookie control is currently impossible with WKWebView. However you can retrieve the contents of the page and load them just as you can with UIWebView, as well as ad block using the new user scripts features, which are a much better framework than what was available before.

Re: Firefox for iOS on GitHub

#87

Post by JetSpiegel »

rimantas wrote: post #78
JohnTHaller wrote: post #50

Earlier quoted context omitted.

It's still a Safari wrapper with sync support. Not sure what they'll call it yet. I really hope they don't just call it Firefox since it definitely isn't.

Is Chrome on iOS Chrome? If it is, why Firefox cannot be Firefox? Or should they ditch "Firefox" and just call everything Gecko, because you think that's the most important?

> Is Chrome on iOS Chrome?

It's not, and just because Google also caved in to Apple's tyranny doesn't make it right for everyone to do it.

Re: Firefox for iOS on GitHub

#88

Post by LeoNatan25 »

misiti3780 wrote: post #15

Here is an interesting comment: (KeyPayload.swift) We should also call super.isValid(), but that'll fail: Global is external, but doesn't have external or weak linkage! Swift compiler bug #18422804.

Yes, that is a known bug. Swift and its development toolset is still very much a work in progress and definitely not ready yet, despite the embracing of many developers. Like anything related to iOS 8, such as Xcode 6, Swift, Watchkit, OS frameworks, services, it's good six months to one year work away from being actually ready.

Re: Firefox for iOS on GitHub

#89

Post by wooger »

graetzer wrote: post #42

I think it's great that they are going to officially support iOS again. Coincidentally I submitted a new version of my own browser app to the AppStore, on the same day they made the announcement. I added support for the new Firfox sync protocol - it took me forever to get it working and now it's kind of redundant :-/ Anyway, if someone is interested in the source: https://github.com/graetzer/Foxbrowser

I don't use your browser, but I'll check it out.

Also I hope the dev of iCab reads HN and can get some benefit from your code - he's not added support for new FF sync yet.

Re: Firefox for iOS on GitHub

#90

Post by blub »

LeoNatan25 wrote: post #86
blub wrote: post #62

Earlier quoted context omitted.

Besides having access to JIT, being multiprocess, getting the backward/forward swipe for free and finally having a decent way to estimate progress, WKWebView is actually worse than UIWebView and less customizable. UiWebView, as slow as it is permits you to do stuff like saving pages for offline viewing, ad blocking, cookie control and so on. If they use WKWebView I'm not even sure they can implement the features of a…

Some of your concerns are true, others are not. Cache and cookie control is currently impossible with WKWebView. However you can retrieve the contents of the page and load them just as you can with UIWebView, as well as ad block using the new user scripts features, which are a much better framework than what was available before.

Can JS really block requests to a server or is it more ad hiding than blocking? I suppose WKUserScriptInjectionTimeAtDocomentStart could be used to inject something that will e.g remove ad-related DOM nodes, although this is more theoretical than a reality I guess. UIWebView can drop connections based on URL matches and also content analysis OTOH, and that's a pretty well understood way of doing things.

One more plus for WkWebView that I forgot - the history list and moving backwards/forwards in it. I agree it has some really nice pluses, but at least for my use cases (and the use cases I would be interested to see implemented in iFirefox) it doesn't seem to be the right choice.

Post reply on HN