Firefox for iOS on GitHub • Hacker News Board

Re: Firefox for iOS on GitHub

#141

Post by avggeek » Mon, Dec 08, 2014, 2:06 AM UTC

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 just got the 3.0 update on my phone and connected it to my Firefox account. Unfortunately, after the initial sync completes the app goes into a constant crash loop, making it unusable.

This is on an iPhone 5S running iOS 8.1.1, with about 200 bookmarks. If there are any crash logs I can provide, let me know.

Re: Firefox for iOS on GitHub

#142

Post by eclipxe » Mon, Dec 08, 2014, 7:49 AM UTC

air wrote: post #43

eclipxe wrote: post #39

Earlier quoted context omitted.

Rendering engines are okay. Its the Javascript execution engine that is not allowed. You can render all the HTML you want, you just can't allow untrusted code to be executed.

> Rendering engines are okay. Its the Javascript execution engine that is not allowed. No, they must use WebKit: "Apps that browse the web must use the iOS WebKit framework and WebKit Javascript" https://developer.apple.com/app-store/review/guidelines/

You can render HTML content with a custom rendering engine - for example ePub ebooks are essentially bundled HTML + CSS content - there are several HTML rendering engines that read ePub ebooks but don't use Webkit.

Also, you can build a UI using web languages and render to native controls, all without using WebKit if you'd like.

Re: Firefox for iOS on GitHub

#143

Post by eclipxe » Mon, Dec 08, 2014, 7:50 AM UTC

shadowmint wrote: post #41

eclipxe wrote: post #39

Earlier quoted context omitted.

Rendering engines are okay. Its the Javascript execution engine that is not allowed. You can render all the HTML you want, you just can't allow untrusted code to be executed.

Well, since you can't use the native javascript engine with a separate rendering engine, there's not much difference though is there? (if you could, everyone would just do that to get dynamic behavior using javascript in their apps as a scripting language)

Not all content created with web technologies and renderable with an HTML/CSS rendering engine require Javascript

Re: Firefox for iOS on GitHub

#144

Post by bzbarsky » Mon, Dec 08, 2014, 7:59 AM UTC

eclipxe wrote: post #142

air wrote: post #43

Earlier quoted context omitted.

> Rendering engines are okay. Its the Javascript execution engine that is not allowed. No, they must use WebKit: "Apps that browse the web must use the iOS WebKit framework and WebKit Javascript" https://developer.apple.com/app-store/review/guidelines/

You can render HTML content with a custom rendering engine - for example ePub ebooks are essentially bundled HTML + CSS content - there are several HTML rendering engines that read ePub ebooks but don't use Webkit. Also, you can build a UI using web languages and render to native controls, all without using WebKit if you'd like.

Right, rendering HTML is fine. As long as you don't download it from the internet on-demand, or so.

Re: Firefox for iOS on GitHub

#145

Post by LeoNatan25 » Mon, Dec 08, 2014, 9:05 PM UTC

blub wrote: post #90

LeoNatan25 wrote: post #86

Earlier quoted context omitted.

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…

I think it's also important to remember that this is a very much 0.5 release, very much not ready for prime time. In a year or so, likely the state of WKWebView will improve greatly.