Open Bug 1596812 Opened 5 months ago Updated 14 days ago

Web-based stub installer UI (HTML/JS/CSS)


(Firefox :: Installer, enhancement, P1)




Install Update Workflow In Review


(Reporter: mhowell, Assigned: mhowell)


(Blocks 1 open bug)



(7 files)

Currently the stub installer's user interface code is highly fragile, error-prone, difficult to modify, and difficult to read. The number of engineers available to work on it is worryingly small, and it's extremely difficult to bring up new engineers because the code is so specialized. Replacing the current implementation with web pages rendered by a native web view will make modifying the UI and/or the visual design much faster and easier, so that specialist engineers would no longer be needed to make any changes, and changes can be made more frequently and with less risk. It would also remove a lot of limits that currently exist on what UI elements may be used and how they can be customized.

Note that currently "web-based" means "using HTML and CSS," not actually downloading any UI elements from the web at runtime.

That sounds very interesting from an l10n point of view. The installer is on the list of things stuck on very old hacks l10n-wise, and where we'd like to Fluent all-the-things. We'd love to be involved early in the design here to discuss the options.

Well, the problem is that the entire UI can't actually be converted; we still need some native message boxes and the web control isn't able to set the window title, so there still need to be some strings directly accessible to NSIS. So for now I'm planning on sticking with the current system, but this will make it possible to migrate most of the strings at a later time.

Here's a document I wrote that explains more about the rationale for this and why I've gone with the solution I have.

Minify this file by removing the dialogs we don't need and hide all the
unnecessary controls in the one we do need, so the stub installer code
doesn't have to do that manually (I would have removed those controls
altogether, but the NSIS compiler errors out if you do that).

This is all the code and build files for an NSIS plugin that enables
rendering a web page as the content of an NSIS dialog.

Documentation and the compiled binary are in later commits in this series.

Depends on D56576

Install Update Workflow: --- → In Review
Summary: Web-based stub installer UI → Web-based stub installer UI (HTML/JS/CSS)
Blocks: 1617957

Is this at a stage where we can try it out, and if so, how? I'd like to do some early a11y review if I can, as this is something we really need to get right for a11y. Thanks.

Flags: needinfo?(mhowell)

(In reply to James Teh [:Jamie] from comment #11)

Is this at a stage where we can try it out, and if so, how? I'd like to do some early a11y review if I can, as this is something we really need to get right for a11y. Thanks.

I don't have any builds yet (the reviews aren't quite finished), but I agree that's important, so I'll try to get you something as soon as I can. Leaving needinfo open until then.

Okay, here's a try build you can use (taken from this push). Might be a few last late-breaking changes (and of course I'll address anything you find), but that's very close to final. Since it's a one-off build, you'll probably get Windows SmartScreen complaining about; just ignore it.

Flags: needinfo?(mhowell)

I took this for a spin. There are definitely some problems which need to be addressed here.

  1. When the installer starts, focus goes to an unlabelled Win32 Button, which might actually be invisible.
  2. Tabbing moves focus to an HWND with class "Shell DocObject View". The HTML document (class: "Internet Explorer_Server") is a child HWND of the focus. That means a screen reader can't read the document because the document HWND doesn't get focus.
  3. If you tab again, you get to another unlabelled Win32 Button. Tabbing yet again takes you to an unlabelled Win32 check box (Button with BS_CHECKBOX). These are probably not visible either. The next press of tab cycles around to Shell DocObject View.

The actual web document is fine, including the progress bar. 👍

What needs to happen:

  1. Focus should start in the Internet Explorer_Server HWND.
  2. I'm guessing the buttons and check box aren't meant to be user perceivable. Either:
    • They need to be removed. But I'm guessing there's some NSIS limitation here?
    • They should be removed from the tab order by removing WS_TABSTOP. Again, not sure if that's possible with NSIS.
    • Given we're focusing the document as per 1), perhaps we can intercept keydown events in the web document with JS to prevent tab from moving focus to these controls? That's risky, though, because it could mess with things if we ever have focusable controls in the web content. We'd have to be very careful to fake the tab order in that case.

That's extremely good to know, thank you. I knew something was wrong with the focus, but hadn't identified exactly what. I'll experiment and see what I can do with those superfluous controls; you're right that the framework doesn't easily allow just removing them, but we should still have options.

You need to log in before you can comment on or make changes to this bug.