On prompting, part 2

In the previous episode, I talked a bit about why I really, really don’t like the existing prompting code in Mozilla. I’ve been working on improving the situation.

The first big chunk of work is up for review in bug 563274. This basically removes all of the existing prompting code from /embedding, and creates a new component in /toolkit to replace it. The code is _much_ cleaner (though I may be biased!), and it’s written in JavaScript instead of C++.

For this first step, I’ve tried to keep things backwards-compatible and avoid breaking existing code. In fact, the UI is the exactly the same and the pile of nsIPrompt* / nsIAuthPrompt* interfaces are unchanged; there’s just a shiny new implementation underneath it all. But if anyone’s likely to find surprises, it’s probably embedders who are providing their own implementation of the existing code (eg, to implement their own non-XUL prompts). In theory those existing implementations should still work, but there might be some subtle bugs, build-goop changes, or patch dependencies on now-deleted code… The typical kinds of things that are expected when overhauling crufty old code, but these shouldn’t be hard to fix.

That said, this is just the first step. Upcoming steps are more likely to require changes that may break existing code. Even previously frozen interfaces like nsIPrompt / nsIPromptService might be thawed and changed (though we won’t take that step lightly). A few of the things I’m mulling over:

  • Make password manager watch prompt notifications, instead of implementing prompt interfaces.
  • Implementing tab-modal prompts.
  • Eliminate the nsIAuthPrompt-in-nsIAuthPrompt2 wrappers
  • Simplify the way chrome XHR handlers can override the default authentication prompting
  • Simplify the existing pile of interfaces (so instead of having 6 ways to do the same thing there are only 2 or 3. 🙂

More updates as plans solidify.


4 thoughts on “On prompting, part 2”

  1. I’d certainly like a better way of doing the prompts & password obtaining in the password manager – the existing ones don’t totally meet what mailnews really wants, plus at some stage, we don’t necessarily want a modal prompt, we might want something else (possibly similar to your tab modal idea, but not fleshed out yet).

  2. Do you already know how you’re going to implement tab-modal prompts? Will they be simple XUL boxes stacked on top of the tab’s browser, or panels that get hidden and re-shown when you switch tabs?
    I’m asking because I think I can get native sheets on Mac OS X working with the second solution – sheets that act like panels and are not modal for their window.

  3. Per-tab notifications sound great. They could fix the pages that send alerts() to lock the browser, too.

    Do the other changes mean I’ll only get prompted with a master password once, possibly with a list of extensions that made the request?

Comments are closed.