Blog posts tagged: status-report
News and other things I find interesting
Last modified: Wednesday, August 15, 2012
Work on the Metro style enabled desktop browser has progressed steadily and things are looking really good.
We have a Q3 goal of delivering a Metro preview. This preview will include primary browser UI for navigation and tabs, and will be delivered as a combined classic + metro browser. I believe there is a Q4 goal for a beta release as well.
We made significant progress since the last update, but there is still a lot to do.
In particular we got the following working:
- Crash reporting
- pdfjs (Built in PDF viewer without the need for a plugin)
- Windowless Flash, although full screen flash doesn't work yet
- Some accessibility hooks
- Front end event refactoring to be faster and to treat mouse input normally and distinct from touch input
- File pickers updated to be asynchronous on all platforms because it was needed for WinRT
- Front end awesomescreen work was done with results coming up as you type in the urlbar.
- While in metro, we also have the 'view this page on desktop' functionality working
- Various keyboard shortcuts added
- Various other fixes and refactoring
Add-ons will not be part of the initial release, but we will eventually be supporting Add-ons via the Add-on SDK. These initial limitations are only when in the Metro version of the browser on Windows 8.
We'll have some kind of sync functionality to sync data between your Metro interface and your desktop interface. We're hoping for a local, no setup sync functionality, but at worst it will be done through the current sync functionality.
We haven't merged to mozilla-central yet, which is where Nightly builds will show up. This is mainly because we're waiting on bug 755724 to be complete, which is to split platform and app resources up so that they can be loaded individually.
Last modified: Thursday, July 19, 2012
It's been a couple months since the last progress update on Firefox for Metro, but things have been progressing at a steady pace.
A new intern working under Frank Yan named Jonathan Wilde started working with us. He's focused on the Metro front-end code, and is really tearing through tasks fast. He's implemented the new URL bar and tab bar as seen here.
Since the last update we've also more or less finished work on the appbar control (the orange bar that appears when doing an edge gesture in Windows 8).
We determined that sharing the same Firefox profile in both Desktop and Metro is out of scope for the initial version, so instead we plan to sync the settings between 2 profiles using Firefox Sync augmented with some key local events to force a sync right away by using Windows Messages, events, and the registry.
We've cleaned up and tweaked a lot of the Windows 8 contracts work. Fixed soft keyboard issues, improved gesture input support, fixed support for invoking external applications, and more.
The graphics code has also been improved by getting rid of the Basic Layers support and moving to LayerManager.
The upgrade from Windows 8 Consumer Preview to Windows 8 Release Preview came with several changes as well that were fixed up.
We removed the XAML interop support because MS decided this was for Metro applications only and not Metro style enabled desktop browsers. To do this we had to change some startup code, gfx code, and re-implement the appbar using XBL/XUL/JS.
Tim Abraldes finished work on combining metrofirefox.exe with firefox.exe, so now there's only one shared exe that dynamically determines which front-end to use. Metro Firefox uses a modified copy of Fennec XUL front-end which is found in browser/metro/.
We also implemented various bugs to support the registration for default browser in Metro. In particular, Windows itself must be responsible for invoking the default browser UI, so we added code to get Windows to prompt for it. The code for detecting which browser is the default has also changed in Windows 8, so that was updated too.
An existing open question was how we would distribute one build that worked both with Windows XP and Windows 8. Microsoft announced that they will be providing support for this, so we won't have to worry too much about it.
Of particular note is Bug 755724 which is to split up platform and app resources so that they can be loaded individually. This is probably the main thing holding us up from landing on mozilla-central. It needs an owner so please reach out to us on #windev if you have time to help out with this task.
A new command line firefox.exe -metrodesktop can be used for viewing the metro front-end in desktop mode. This is useful for things like debugging since Windows kills your process if you have it paused for too long. We're also starting to use this now to get tests running with the Metro front end. There's another bug filed but not completed yet to get tests running actually in Metro mode.
Last modified: Monday, April 23, 2012
We've made steady progress over the past 3 weeks on Firefox for Windows 8 Metro.
We have secondary tiles working, you can pin secondary tiles temporarily via a menu item. Like Internet Explorer 10, you can pin any number of sites to your start screen. When you click on the secondary tile, it will load the pinned site in Metro whether or not Firefox is already open.
We also hooked up the Windows 8 settings contract which means you can access Firefox preferences via the Windows 8 Settings charm.
Work is in progress for the Play To contract and the print contract.
Accessibility and Input:
We now support the soft keyboard which is especially important for when a keyboard is not attached and you are using a touch device.
We are also working on hooking up Windows 8 touch events, Windows 8 gestures, and W3C DOM touch events.
We added support for XAML interop. This means that we can overlay XAML controls on top of our XUL / HTML rendered DirectX surface.
We don't know all of the use cases for this yet but we'll probably use this for at least the app bar.
The app bar is a bar of controls you can slide up from the bottom edge or your screen or popup via right click.
We also figured out PRI files in Windows 8. PRI files is an undocumented file type for storing resources.
We were using another program's PRI file until recently.
We fixed up some memory leaks on shutdown as well; these were not introduced but happened on Win32 Fennec which we are based on.
Approval for Current Plan:
We're hoping to get approval for the tentative plan which includes moving over the work to the main mozilla-central repository. The mozilla-central repository is where Nightly builds are made.
Up until now we've been developing and landing code on the elm repository.
There are still several open questions, but the one we've been investigating during the period of this update most is how to handle compiling with the Visual Studio 2011 Beta tools and still have support for running those binaries on Windows XP.
To compile Firefox on Metro you have to use Visual Studio 11 Beta, but VS2011 cannot build binaries that are compatible for Windows XP. In bug 744942 we're discussing either patching the CRT, compiling a DLL with the WinRT code separately (2 compiler build process), or packaging a Windows 8 installer separate from the existing Windows installers and updates.
In any case, we will be supporting Windows XP in the same way we always have. I'm personally disappointed that VS 2011 drops XP support given that Windows XP has extended support up until April 8th, 2014.
Firefox Work Week:
Perhaps some of the most exciting work so far will happen this week coming up.
On Monday I'm heading to Toronto for the Firefox work week. One of the hacking goals during this week is to get some significant initial work done on the UI for Firefox on Metro. This work will be based on the UX work from Stephen Horlander and Yuan Wang. In the initial work we'll have the tab bar and address bar on the top and site specific options such as pin site on an app bar accessible from the bottom edge.
Last modified: Sunday, March 18, 2012
This post is a continuation of the Windows 8 status update first started on this blog post.
We're now past the hardly documented parts of development we were fighting with last week, and things are really starting to heat up. From here, most WinRT development topics should be nicely documented because they are now similar to any work done in a C++ Metro application.
We're keeping organized via an etherpad similar to how the snappy project stays connected. Please ping someone on #windev on IRC if you'd like the URL.
Languages we'll be programming in
We're moving ahead with C++/CX and dropping down into WRL when needed. It is still possible that we will one day port the C++/CX parts to only WRL.
In the end though, with C++/CX you get native code, code that is 10x less the size, and code that is less prone to leaks. Less code means less to maintain and faster innovation. C++/CX is also documented and supported a lot better than WRL.
We have a XAML window and we use DirectX to paint to it taking up the entire area of the screen.
This week Jim Mathies was a rock star and made significant progress in many areas:
- He added in the build config needed to build Fennec or Firefox as a Metro application.
- He started work on a new widget layer.
- He also got events working. Getting events working was hard because the UI thread is not the main thread.
This week I spent some of my time finishing an old project and the rest on Windows 8 work:
- I hooked up the WinRT window to our graphics code (WinRT to Thebes).
Metro does not give us easy and reliable access to an
HWNDand instead has a
CoreWindow, so extra new code was needed inside the graphics module. In particular I added most of this new code in
gfx/cairo. We don't have support for the Azure back end yet. The new code added in the graphics modules does not use C++/CX.
- I also implemented support for Metro snap in regards to our rendering code. This means you can have a metro application beside our browser when in Metro mode.
Firefox on Metro will not simply be Firefox desktop copied into the Metro environment, we are embracing the framework instead of fighting it.
How to get the development environment setup yourself
The code for this project is happening in the elm branch, you can see the changelog and checkout the project using hg here. The metro subfolder contains our research but most of the new code is going in
We're currently compiling and working with a fennec mozconfig setup with the following options added:
ac_add_options --enable-win8metro ac_add_options --with-windows-version=602
--enable-win8metro adds in the
-ZW flag in the
widget/windows/winrt module only, which makes it so C++/CX code is allowed.
This LIBPATH environment variable must also exist.
Stephen Horlander started work on the Metro splashscreen and tile. You can see some experimentation on the tile and splashscreen here.
I added these resources into the elm repository, it's definitely more exciting to develop when you click on a meaningful tile and see a cool splashscreen.
Several developers have expressed interest in helping the project including Tim Abraldes, Wes Johnston, David Woolbright, Burak Yigit Kaya, and Berker Peksag. I'm excited to have more hands on the project in the coming weeks.
Next development steps
Now that we have event handling and thebes hooked up, we should be pretty close to getting something resembling a browser. We're still very early in development but we're making great progress.
We didn't have a meeting this week because we were actively keeping each other up to date on #windev on IRC.
I'll be away next week so probably won't write another update for a couple weeks. Feel free to email me if you'd like to get involved.
Last modified: Saturday, March 17, 2012
As of Monday of this week, development work began on Firefox for Metro.
A bit of background on Windows 8 Metro and Firefox
It turns out that on Windows 8 there are 3 types of applications:
- Classic desktop applications
- Metro applications
- Metro style enabled desktop browsers
Firefox will fall into the third category, meaning you can run Firefox as a desktop application, and you can run it as a Metro application. Supporting the Metro side of things will require a lot of new code, so this is a very large project.
Unlike Metro applications, Metro style enabled desktop browsers have the ability to run outside of the Metro sandbox. Meaning not only can we build a browser, but we can build a powerful browser which gives an experience equal to that of a classic Desktop browser.
Metro style enabled desktop browsers have access to most Win32 API and the entire new WinRT API.
Unfortunately a browser can only participate in Metro mode if it is the default browser. So if Firefox is not the default browser on a system, you can't use it in Metro mode. This is a decision made by Microsoft.
The Firefox Metro enabled desktop browser can be, and will be included and packaged in the traditional way. I'm not certain if it will be allowed on the Windows store or not since it is not of Metro application type.
Languages we'll be programming in
We will be using the Windows Runtime C++ Template Library (WRL) which is similar to C++ / ATL.
We may also be using C++/CX which does compile down to native code but has some non-standard C++ extensions that allow for code to be about 1/10 the size.
Our hesitation in using any C++/CX code is that it will definitely require a new build environment. Personally I think it would be worth using C++/CX in the long run. WRL and C++/CX code can freely be mixed even in the same source file.
The GUI will be made mostly by painting to DirectX. XAML may be used in a very limited fashion. XAML is the main presentation layer in Windows 8 Metro if you are using a .NET enabled language or native C++. XAML is a declarative XML-based language similar to Mozilla's own XUL. XAML is familiar to WPF and Silverlight developers. XUL will most likely still be rendered to the DirectX surface.
Windows 8 has a minimum requirement of hardware that supports Direct X 9 and I'm not aware of any alternative like GDI available. So the Direct X blacklist of graphic cards we currently maintain may not be applicable in Metro mode.
Our first major goal is to get an experimental build of Fennec or Firefox running in Metro. This work is mainly being tracked in Bug 732518.
To get started we read the MSDN whitepaper entitled Developing a Metro style enabled Desktop Browser. This document lacked quite a bit of information though so a lot of registry hacking was needed to get things working. Jim and I documented a lot of this missing information here and here.
Most of our week was spent with registry exports, diffs, Process Monitor logs, and other tools. The first couple minor goals were to get a recognized Metro tile showing up, getting it to launch our process, and then finally displaying a Metro app.
Jim and I hit those first milestones and made a basic application which launches in Metro mode as a medium integrity process. The application doesn't do anything exciting except display a DirectX surface and draw some text to the surface that tracks mouse movement.
As a developer, your job gets pretty hard when you do a Google search for topics surrounding this barely supported third Metro application type and consistently get zero, one, or if you are lucky, two search results. All results being only slightly on topic.
Next development steps
We have several smaller goals that we want to tackle next week:
- Figure out how to make our own PRI files with our own resources.
- Get a C++/XAML application working
- Get our app launching through a delegate DLL instead of an EXE
- Figure out how to interop XAML / DirectX.
- Start to figure out how we will paint content to our DirectX surface with the graphics layer
- Figure out how to implement other contracts
- Look into native theme rendering
- Probably others
We're still extremely early in development so we're not ready for help with things like how the UI should look yet.
If you want to help with the development effort to get Firefox up and running in Metro, we'd love to hear from you. Please sync up with us in #windev on IRC or email me directly at netzen at gmail.com.