Comment 1 for bug 1352338

The real issue is with most webapps passing the --enable-back-forward and/or --enable-addressbar command line switches to the container. Most webapps probably don’t need that any longer, but for backward compatibility I kept the mapping of those switches to showing the chrome.

Note that the new chrome is not intended to behave like the old one: either it’s shown, and then it autohide upon scrolling, or it’s hidden, and it nevers appears (the latter is the default, and probably what most webapps want).

There can’t be a swipe to reveal/hide gesture for the new chrome, as it would conflict with interaction with the indicators. The new chrome has the same behaviour as the new header component from the SDK, its visibility is tied to the contents of the page, not triggered by explicit manual interaction.

Also note that with the new container, even when there’s no chrome at all, there will always be a thin progress bar shown at the top while loading, which gives some feedback to the user that something is happening (IIRC the --enable-addressbar switch was initially introduced to work around the lack of an external progress indicator, since the progress bar used to be embedded inside the address bar).

So I think the fix is to assess for each webapp whether they really need the legacy command line switches, and remove them accordingly.