[whatwg] Menubars and phishing

[Dylan Schiemann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Hickson wrote:
| I'm really stuck on this problem of how to handle running remote
| applications so they definitely look like they are remote, and an
| application on paypcl.com is definitely distinguishable from one on
| paypal.com, even if they use near-identical code.

The best thing that comes to mind is this... starting a web app could
have a mechanism much like starting a real application.  The first time
you start the web app, you would give consent to give the app a certain
level of permission, and a way to remember that permission level (much
like approving the installation of a program).  And this would need to
be easy enough to use that people wouldn't just click yes to everything.

| It should also always be possible for the user to control his windows
| completely -- resize "unresizable" ones, not have any popup windows that
| break out of the browser, always have access to the UA menu bar or
| toolbar, etc.

Yes and no.  Many traditional apps don't afford these rights to the
user.  I see more of a need to easily kill or end an application
session, that would clean-up everything from an offensive app, than
requiring every window of an app to be able to show menus and be resizable.

| Yet we want these applications to look nice, and have their own toolbars
| and so forth, without looking silly.

Agreed.

| For popup windows I think the best plan is probably to have "fake" popup
| windows that are basically just position <div>s (which can be resized,
| etc, but are restricted to the content area of the parent Web page). So
| that's not a big problem. The big problem is how to handle menus on the
| primary top-level Web application window.

part of the netWindows API does a great job with this.  I've used divs
which then have svg documents in them as well for popups.  I like to
call these windows "flyovers" rather than modal or modeless windows.

There are reasonable use cases for wanting the flyover to be outside the
area of the traditional parent window... for example, think of an
interface like the Gimp... basically sometimes you want to move the
flyover out of the way when working with an app... but you can't move it
out of the way if it has to be contained by the parent window.  This
gets much more complex in a multiple document system, where the parent
document might not have a reason to be very large.

| In fact, on Mac, there is no per-window menu bar, and there is no way that
| Web apps will ever have access to the top-level menu bar, so come to think
| of it menu bars in general are out.
|
| How should Web applications provide their feature access points?
|
| Any suggestions on how to handle this would be welcome.

http://www.konfabulator.com/ does some interesting stuff on the Mac with
widgets that might be in some way inspiring.

The question comes down to this: should web apps have control over
system menu controls?  Traditional software apps are afforded this
control, so why not "approved" web apps, provided there's an
unoverridable, obvious way to "escape" from the web app?  Or at a
minimum, why not one menu bar dropdown that has a title that is the name
of the web app, and its own level of options that are added/removed
through a standard API?  The same principle seems to be analogous for
context menus.  The Adobe SVG viewer has a context menu API:
http://www.protocol7.com/svg-wiki/default.asp?CustomizingContextMenu and
I proposed something similar for mozilla a long time ago in place of the
oncontextmenu event: http://bugzilla.mozilla.org/show_bug.cgi?id=87536

- --
Dylan Schiemann
http://www.sitepen.com/
http://www.dylanschiemann.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAyMQn8nLgh/JJsxERAtmXAJ9Arn+yLdqTMegsd7i2GtlB/WshJQCgjs3k
CnuLXvrdLSqAsFi7bcdiRyE=
=j3rN
-----END PGP SIGNATURE-----