ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chrisccoulson@xxxxxxxxxx>]

Public bug reported:

There are several scenarios where we should request that the browser
doesn't hide its UI when in auto mode, including:

- SecurityStatus.securityLevel indicates a degraded status.
- The renderer is unresponsive.

We should also review some of the conditions in
https://chromium.googlesource.com/chromium/src.git/+/master/chrome/android/java/src/org/chromium/chrome/browser/tab/TopControlsVisibilityDelegate.java#31.
This logic should exist in Oxide so that we don't have to expose too
many low-level internals (we don't want to expose things like
isFocusedNodeEditable, for example).

The behaviour probably doesn't need to be configurable.

For the unresponsive renderer case we'll need some browser-side logic to
override the headerbar position, as this is normally driven by the
renderer compositor (which we can assume won't be producing any frames
in this case).

** Affects: oxide
     Importance: Medium
         Status: Triaged

** Changed in: oxide
   Importance: Undecided => Medium

** Changed in: oxide
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1628496

Title:
  LocationBarController improvements

Status in Oxide:
  Triaged

Bug description:
  There are several scenarios where we should request that the browser
  doesn't hide its UI when in auto mode, including:

  - SecurityStatus.securityLevel indicates a degraded status.
  - The renderer is unresponsive.

  We should also review some of the conditions in
  https://chromium.googlesource.com/chromium/src.git/+/master/chrome/android/java/src/org/chromium/chrome/browser/tab/TopControlsVisibilityDelegate.java#31.
  This logic should exist in Oxide so that we don't have to expose too
  many low-level internals (we don't want to expose things like
  isFocusedNodeEditable, for example).

  The behaviour probably doesn't need to be configurable.

  For the unresponsive renderer case we'll need some browser-side logic
  to override the headerbar position, as this is normally driven by the
  renderer compositor (which we can assume won't be producing any frames
  in this case).

To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1628496/+subscriptions