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.)
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.
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.)
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.
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.