Blog posts tagged: status-report
News and other things I find interesting
Firefox for Windows 8 Metro - Front end updates, crash reporting, pdfs, and more, status update 6
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.
Tags: firefox windows8 mozilla status-report
Add a new comment | 12 comment(s)
|
I believe we are now required by Microsoft to call this the UI formerly known as Metro. ;-) |
|
I'll start using another name when they update the MSDN documentation :D |
|
Sync? Does this mean that metro and desktop have different profiles? |
|
Yes, at least initially there will be 2 profiles and important data will be synchronized across them. |
|
What branch is the Metro (née "Windows 8-style UI", or "Modern UI") work currently on? |
|
On elm: |
|
Will I be able to use Firefox on just a Windows RT tablet with no x86 or x64 support? I hope this is the case as I love Firefox and can't wait to use it on Windows 8! |
|
Will it offer an option to get rid of the truly awful pdfjs? I've tried the various solutions on the web and I still can't read PDFs anymore, I have to specifically download them and then launch Foxit Reader. |
|
> Will I be able to use Firefox on just I don't think so, but you can get an x86 or x64 based tablet that also has a desktop environment and allows alternate metro browsers. > Will it offer an option to get rid of the I personally love it, but if it's not working right for you, you can turn it off. > I've tried the various solutions on the web You can change the default pdf reader in Firefox options, applications, in the search type pdf. Or I think there is an about:config option to disable it too. |
|
I would hate for users to need to set up sync just to use Metro Firefox properly. |
|
The old joke runs a Microsoft speakerman gnviig an speech against Mozilla et friends:"You know, these guys just release new and new versions of the software as they write it, waiting for the users to find the bugs and report back to them. On the other hand, we in Microsoft... er... hmm..., yes..., it is an amazing coincidence!." |
|
Any news :(? |
Firefox for Windows 8 Metro, status update 5
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.
Tags: firefox status-report windows8 mozilla
Add a new comment | 5 comment(s)
|
1 Question: (unlike Metro IE10 which currently forces an archaic whitelist of only public sites after a 10 week delay/approval process) |
|
Hope we can get this ahead of Windows 8 release! :D Is there some build we can try? I am planning to move to Windows 8 this weekend and maybe I can help providing some feedback. Thanks! |
|
Hi Brian, I tried "firefox.exe -metrodesktop" |
|
There are only builds available if you build from source code here: Once we get the code on mozilla-central though you'll be able to test things out with normal Nightly builds. |
|
Another thing: VC2012 defaults to SSE2 code generation. This can be disabled by using /arch:IA32. |
The latest on Firefox for Windows 8 Metro, status update 4
Last modified: Monday, April 23, 2012
We've made steady progress over the past 3 weeks on Firefox for Windows 8 Metro.
Platform Integration:
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.
Core Changes:
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.
Open Questions:
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.
Tags: firefox status-report mozilla windows8
Add a new comment | 7 comment(s)
|
Looking forward for this :) You guys are awesome!! |
|
I take it from this update that we are sticking with Fennec as the basis for the Metro version? You mentioned having the address bar on the top. All the Metro IE screenshots I've seen have it on the bottom. Is this an intentional deviation from the platform standard? What is our (hopefully significantly justified) motivation in that? |
|
Is it as simple as just double clicking FF's exe after you've built it? |
|
> I take it from this update that we are Yes that's correct. > All the Metro IE screenshots I've seen have it on the bottom. Yes this is intentional. > What is our (hopefully significantly justified) motivation in that? You'd have to ask someone from the UX team but I don't think there is a conflicting Metro guideline. Typically URL bars are on the top so IE is having the deviation here. > Is it as simple as just double clicking FF's Clicking the FF tile actually from the start screen. You can find more info here: |
|
I know you probably can't wait for Microsoft to make up their minds, but there is *a lot* of pressure on Microsoft to re-add XP support for VC11. And some of their comments under this blog post: (http://blogs.msdn.com/b/vcblog/archive/2012/04/18/10295093.aspx) seem like they're probably going to cave. |
|
Ya we have been reading that discussion and are hoping for a positive outcome. |
|
Are there any working Firefox Metro builds available? |
Firefox Metro development heating up, 2nd status update
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.
Development milestones
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 aCoreWindow, so extra new code was needed inside the graphics module. In particular I added most of this new code ingfx/thebesand ingfx/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 widget/windows/winrt.
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
The option --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.
UX milestones
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.
New contributors
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.
Meetings
We didn't have a meeting this week because we were actively keeping each other up to date on #windev on IRC.
Next update
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.
Tags: firefox windows8 mozilla status-report
Add a new comment | 4 comment(s)
|
Perhaps a technical term passed me by or my addled mind missed it, but will the Metro 8 browser run as a separate instance or will it be a part of the same process. Will it be drawing on the same executable file? |
|
It may be the same executable file, but it will be a different process. |
|
Since Metro doesn't allow plugins. Mozilla should accelerate plans to integrate h264 playback into the Metro version of Firefox b/c there is no flash fallback. Unless Firefox Metro wants to repeat the same mistakes as Firefox mobile. |
|
Hello, It will be interesting to see how C++/CX and C++ will be mixed and how it will evolve. I have exposed my point of view and the fact that Windows Team has done entire WinRT API in C++. (https://bugzilla.mozilla.org/show_bug.cgi?id=732518) Fully embracing the framework is the right way. But you should stay in fully standard C++ 11... stay connected. regards, |
Firefox Metro development begins, status update
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.
Development milestones
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
Meetings
We had our first weekly developer meeting half way through the week with attendees: Robert Strong, Tim Abraldes, Jim Mathies and myself (Brian R. Bondy).
Helping out
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.
Tags: firefox mozilla status-report windows8
Add a new comment | 11 comment(s)
|
Do you have to use XAML for the UI, or would it be possible to paint a XUL UI inside a direct X surface? I'm wondering if implementing the UI with XAML is a choice or a technical constraint here. |
|
Why do we have to use XAML for the UI? Are we able to use XAML just for the Metro UI, and retain the existing XUL interface for the desktop UI? |
|
So XAML UI was a bit misleading. If we use XAML it'll be very minimal and mostly just a frame that Direct X sits in. We'll still paint to Direct X and probably still use XUL as well. |
|
"I'm not certain if it will be allowed on the Windows store or not since it is not of Metro application type." |
|
The whitepaper says "on the x86/64 architecture". So are we blocked from shipping the same code for ARM? Is Windows 8 for ARM going to emulate Apple-style lock-down? |
|
Out of curiosity: Which of the 3 categories will Microsoft Office belong to? Or is the a fourth MS-only category. And thanks for doing the Firefox porting work! |
|
Are there also plans to support the ARM version of Windows 8, or does your work target the x86 version only, at the moment? |
|
> Re windows store: Sure it is possible, but I wouldn't be the one doing that discussion with them. > So are we blocked from shipping the same code for ARM? I don't think we have details on this yet. > Which of the 3 categories will Microsoft Office belong to? I haven't heard so not sure, but I can say for sure not the third category I mentioned. > Are there also plans to support the ARM version of Windows 8 We would love to, I'm unsure if it will be possible at this time. |
|
Sorry for a little noob question. Will FF on W8 Metro support Flash? This would be a very nice feature because IE10 will not and some people have to use Flash in special webapps that are not possible in HTML5 right now. |
|
> Will FF on W8 Metro support Flash? It's too early in development to know |
|
Much of what u say is that coding will employ these library interfaces a la metro, however, will the gecko engine also undergo changes or will it be comported to the overall UI? |