I have created a spec that extends CSS a little bit, allowing for more advanced backwards compatibility by surrounding new/perhaps-unsupported CSS rules with an at-rule. Read it here, let me know what you think (this was also announced on www-style).

Here are a few more screenshots, after discussion with mconnor and a few other devs. They are in my opinion, and others I’ve heard, the most pleasing to the eye, and integrate fairly well with the browser chrome:

A web application with minimal chrome would look like this (for example, when launched with the -chrome flag of xulrunner, or window.open()ed with all the features disabled:

After I prepared these screenshots, Firefox went back to forcing the status bar instead of the location bar. So maybe the site information/context menu could be under the content, instead of over it. The border is still necessary, to delineate where the untrusted content actually is.

In addition, it would be good to allow untrusted web apps to do more with UI, but users should always have the option of disabling these:

open modal windows
hide context menus
perhaps even block leaving a page

See bug 248207 for some more history/discussion.

I think the essence of my last post was lost in the screenshots. In particular, I am painfully aware of doron’s point that users don’t care about security. That’s not the point of this exercize. Instead, the point is to make sure that web content cannot be mistaken for browser chrome. This must involve (IMO at least) some sort of border around unsecure content. You can’t possible put a trustable border around all the browser chrome, but you can put a trustable border around untrusted content. Whether or not users actually read the security info is unimportant. You no longer have the opportunity to spoof the master password dialog.

There has been a long and wide-ranging discussion about UI spoofing in browsers (and of course Mozilla/Firefox in particular). Basically, bad-boy web content can pretend to be the location bar, the status bar, or other browser UI, and attempt to steal privacy information. The basic problem is covered in bug 22183. This is a problem that affects all browsers, since UI can be spoofed with simple images; however, it is easier in browsers that support XUL, since remote XUL tends to look the same as trusted browser XUL.

Gerv originally proposed a solution that always shows the status bar. This was deemed insufficient. The solution in place for Firefox 1.0 is to forbid untrusted websites from hiding the location bar (the URL bar). Here are the good reasons:

• Keeping the status bar open isn’t enough, because it is easy to push the status bar off the bottom of the screen (and hard to prevent).
• If you can see the location bar, it is pretty obvious what website you are visiting, and we make it even more obvious for secure sites by singling out the domain name from the certificate and displaying it prominently.
• The UI is discoverable. People use the URLbar all the time, they actually do get into the habit of looking at it. They know how to use it.

The disadvantages are not quite as obvious, and mainly have to do with enterprise applications: the location bar is large and can destroy the appearance of enterprise apps that open “dialog” windows and other small-UI windows. This is very important if Firefox is going to make inroads in corporate environments maintained by dedicated system engineers, and in many academic settings such as computer labs.

I have been thinking about this for a while, and read a lot of proposals, most of which were damn-ugly. But the core concept was good. Basically, the browser must delineate, obviously and discoverably on screen, between content from different security levels. It is not simply enough to say “the content below this line is untrusted” because you don’t know where the line ends. Instead, you need to wrap the untrusted content in a box, so that you know where it ends. Secondly, the UI has to be consistent. You can’t show one UI when it’s a chromeless window and a different UI when you add the chrome, or else users don’t know where to look for security information, and will not get accustomed to any solution. To this end, I have produced the following mockup images for your consideration:

The third example shows the problem with this approach. When you start adding back the browser chrome, it gets ugly quickly. The transition between the yellow and grey in the tab browser is harsh.

The status bar solution has all the problems listed above, but looks a lot better. Note that all of the status bar widgetry isn’t there, because this is a mockup. Use your imagination.

In combination with a tab browser, none of these solution are especially beautiful, at least yet. I’ll keep playing.

While googling using site-specific searches (trying to find out what glazou meant about “rainbow”) I quite by accident found http://directory.mozilla.org/, which redirects to http://www.dmoz.org/. What is it? Why is it there?

Somebody needs to explain why we’re getting rid of the JS console and View Source from default Firefox builds (they will be available in the “Custom” install option). Comeon, even Internet Explorer has view source!

If a mouse fails to operate or performs erratically, it may need a ball replacement. Mouse balls are now available as FRU (Field Replacement Units). Because of the delicate nature of this procedure, replacement of mouse balls should only be attempted by properly trained personnel. Before proceeding, determine the type of mouse balls by examining the underside of the mouse. Domestic balls will be larger and harder than foreign balls. Ball removal procedures differ depending upon the manufacturer of the mouse. Foreign balls can be replaced using the pop off method. Domestic balls are replaced by using the twist off method. Mouse balls are not usually static sensitive. However, excessive handling can
result in sudden discharge.

Upon completion of ball replacement, the mouse may be used immediately. It is recommended that each technician have a pair of spare balls for maintaining optimum customer satisfaction. Any customer missing his balls should contact the local personnel in charge of removing and replacing these necessary items. Please keep in mind that a customer without properly working balls is an unhappy customer.

Open standards cannot effectively compete with Microsoft XAML and other closed technologies for large market share without a good set of developer tools that make authoring and developing easy (or at least easier). Visual Basic 5-6 were limited and inefficient programming platforms, but were wildly popular simply because developers could drag/drop/insert UI and it would just work. Microsoft Access data applications have much the same appeal. If XUL is to compete with these closed technologies, it needs to have a good GUI editor. The mozilla2.0 team is acutely aware of the problem, but nobody has yet stepped forward to lead the charge.

I spoke briefly with Daniel Glazman about possible UI ideas for a GUI XUL editor, and how it might relate to the fantastic work that he is doing on NVU, the next-generation HTML editor. After a little bit of playing, it is obvious that the editing model for XUL would have to be very different from HTML.

One of the primary factors involves the selection model. In HTML, you select text in a mostly-linear fashion to edit it. Even floats and other out-of-line objects have their own little “flow”. This is simply not the case for XUL, where you must think in terms of boxes and flex, fitting to the available/desired space. In XUL editing, your “cursor” may be vertical or horizontal, and has a limited scope in the current containing box. Once you escape the immediate containing box, your cursor switches orientation from horizontal to vertical (and vice-versa).

I did a basic playground stylesheet with a simple XUL file, and created a special element <edit:cursor> which would act as a “heavy” cursor. What I want to do is steal large parts of DOM inspector code, so that there is a tree sidebar which matches the GUI view.

I found a few places where I need/would really love additions to core gecko… somebody please tell me how hard these are:

1) parse entity names with a special DOM element, instead of expanding them to text. This is pretty much a requirement to do large-scale apps that localize appropriately using the chrome registry

2) a :-top-hover selector. I need a selector that only matches the topmost hovered element, not every hovered element.

3) a -moz-min-margin rule… I can work around this if necessary, but in order to give space between boxes for drag-n-drop and other activities, I would like a -moz-min-margin: 4px rule applied to *.

Did I just volunteer for something? I hope not ;)

A lot of Mozilla localizers think that the Mozilla Foundation doesn’t care about them. This is simply not true. Nobody I’ve talked to at MF denies the importance of localization. However, there is plenty of disagreement about what should be done, and who should do it. Many code developers (who deal with source code all day long) wonder why translators can’t just translate the source files. They look down on the semi-automated tools like Mozilla Translator as a crutch.

I like the automated tools. Anything that makes the workflow faster, without sacrificing quality, is great and should be supported. However, I don’t want the Mozilla applications to be a slave to the tools. I have designed changes to the localization system which will provide significant benefits in terms of the maintainability and scalability of the localization process. I believe that the model we have now, where we take a build and extract files to localize, and then repack the build, is a model that already scales poorly, and will get worse as we add more separate applications like NVU and Sunbird. In addition, it makes it pretty much impossible for mozilla.org to release official version of the localized build. Instead, the localizations should be done at the source level. This is bound to cause some difficulties simply because it is different than what is currently done. The goal is to provide automated scripts to reduce the pain as much as possible.

What I need is an enterprising hacker to modify Mozilla Translator just a little. I’ve tried to get in touch with Henrik Lynggaard but I haven’t been successful, so I’m going to try to pingback his weblog. In any case, MT does not like the directory structure of the new JAR files I am trying to feed it. I am hoping it would be simple to modify the assumptions of MT so that it recognizes the new directory structure (which is the directory structure in CVS).

Here is an incomplete example of the directory structure for the toolkit locale source. Java hackers, please help!

toolkit-en-US.jar
chrome/global/contents.rdf
chrome/global/localized.dtd
chrome/necko/contents.rdf
chrome/necko/localized.properties
installer/install.rdf # for installable langpack
installer/install.jst # for localized build

I also have a sample JAR (very incomplete) available for download.

I had an epiphany the other day, and I haven’t had time to explore every niggly little detail. So I am proposing a challenge for some enterprising hacker: make firefox.exe an out-of-process COM server for the mozilla activeX control.

Then, once it’s working, have the control register itself as a full-page handler for the text/xml, application/xhtml+xml, and application/vnd.mozilla.xul+xml mime types. This would allow IE to seamlessly/silently display XHTML and XUL content using the (much more powerful and standards-compliant) gecko rendering engine. Note: this would not replace the default IE HTML rendering engine, which is possible if you hack the IE binary or the windows registry, but isn’t a “good thing”.

I don’t have the time/energy to actually code this, at least not for a decent while, but I would happy to give detailed assistance to an enterprising hacker: what’s involved is basically calling CoRegisterClassObject during the bootstrap process (somewhere in nsAppRunner.cpp or nsNativeAppSupportWin.cpp). It’s likely that the existing activex control code can be used almost unchanged, but you would probably need to excise some of the custom profile-handling code. There’s a little bit of COM magic needed to inform the appshellservice that it shouldn’t shut down until all embedded instances have gone away, in addition to ordinary XUL/browser windows.

Note: I haven’t talked to Adam Lock about this yet… I just posted on the spur of the moment. If somebody wants to make this happen, we definitely need to talk with him.