Native UI for Firefox on Android | Hacker News Reader

Native UI for Firefox on Android

lucasr.org

56 pointslucasr8 comments

Not to take away from the performance improvements and improved integration that this will bring to Firefox for Mobile, but this new UI means that almost all mobile add-ons will have to be rewritten or significantly updated. Granted, there are less than 200 add-ons that support Mobile, but I'm responsible for 5% of those, and the time it will take to update them to support the native UI might not be worth the effort.

(A similar situation occurred between Mobile 1.0 and 2.0, when browser UI and Web content were separated into their own processes, requiring any add-on that dealt with content to be updated. I still haven't finished all of those changes.)

I don't mean to take anything away from your valid criticism, I'm just curious; what would you have them do instead?

I've been running the native UI build for a while and it is such a huge improvement. It's totally worth it for the browser to make it native.

It certainly will be work to port to the native Firefox on Android. The good news is it's not too hard. The bad news is you have to port... again. Like you said, Firefox Mobile already caused an add-on shift when multi-process was created. Now, we have removed the multi-process, but also removed the XUL front-end. The end result will be a great Firefox Mobile, but once again, we are asking add-on developers to re-work their add-ons. I know it's no consolation, but I wasn't too happy that we threw away 2+ years of work either.

I am happy that the new, native approach will address many of the problems that caused users to avoid Firefox on Android. This means more people will install and use Firefox, making it a more compelling platform for add-on developers.

We plan on writing some tutorials and documentation on porting add-ons to native Firefox on Android, but the basic information is: # Same add-on system. We didn't invent anything new here. # No multi-process. You can use the classic ways of interacting with web content. # No XUL UI. We can't overlay, or use DOM access for any UI. We have implemented several services using native UI and created a simple API for manipulating some native UI: # nsIPromptService and nsIAlertsService are available and use native services # NativeWindow is a new helper object that supports managing menu items, door hanger notifications and popup toast alerts (more coming too) # JS XPCOM components can still be used to override and implement Gecko platform behavior # Jetpack support is still in the works.

To try out the nightly build, here's a QR code:

http://api.qrserver.com/v1/create-qr-code/?data=http%3A%2F%2...

It's buggy but the new UI looks pretty slick already.

I actually made my own android web browser because I didn't like what was out there. https://market.android.com/details?id=com.nj.appiphiliac.bro...

Hopefully this re-threading will make firefox actually load web pages faster not just the ui.

I may give this a spin. I've been using xScope since it began development because I wanted a low-clutter, high-speed option.

Out of curiosity, had you tried xScope too and found it lacking?

xScope is good but not full screen. I wanted a browser which used the full height of the display.

I grabbed your browser and have been using it. It's nice and snappy. Just FYI, xScope goes to full screen if you hit the menu button. Cheers and keep up the good work on making apps.

Reply on news.ycombinator.com