ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chrisccoulson@xxxxxxxxxx>]

Public bug reported:

Updating WebView::editingCapabilities isn't cheap if the clipboard
selection owner changes because we need to read data from the clipboard
to update the paste bit. Previous experience suggests this can take
>100ms in some cases. This used to be a bigger problem, although it was
improved significantly by caching clipboard status.

However, as part of bug 1666002, we're going to be refreshing
WebView::editingCapabilities from more callbacks. This is wasteful, and
I'd prefer we just stopped doing it.

In addition to this, CanUndo and CanRedo are always unset, because there
is currently no visibility of this on the browser side and no way to get
notifications for them from blink.

What we should do is:
- Stop continuously updating WebView::editingCapabilities.
- Add a new method to WebView to trigger an asynchronous refresh of the WebView::editingCapabilities. property. Applications can call this when displaying a UI that requires it (such as a window menu). This will perform a renderer round trip to get the undo/redo capabilities from blink.
- Refresh WebView::editingCapabilities when displaying the touch editing UI, to avoid breaking what looks like the only consumer of this API in webbrowser-app.

** Affects: oxide
     Importance: Medium
         Status: Triaged

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

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

** Description changed:

  Updating WebView::editingCapabilities isn't cheap if the clipboard
  selection owner changes because we need to read data from the clipboard
- to update the paste bit. This used to be a bigger problem, although it
- was improved significantly by caching clipboard status.
+ to update the paste bit. Previous experience suggests this can take
+ >100ms in some cases. This used to be a bigger problem, although it was
+ improved significantly by caching clipboard status.
  
  However, as part of bug 1666002, we're going to be refreshing
  WebView::editingCapabilities from more callbacks. This is wasteful, and
  I'd prefer we just stopped doing it.
  
  In addition to this, CanUndo and CanRedo are always unset, because there
  is currently no visibility of this on the browser side and no way to get
  notifications for them from blink.
  
  What we should do is:
  - Stop continuously updating WebView::editingCapabilities.
  - Add a new method to WebView to trigger an asynchronous refresh of the WebView::editingCapabilities. property. Applications can call this when displaying a UI that requires it (such as a window menu).
  - Refresh WebView::editingCapabilities when displaying the touch editing UI, to avoid breaking what looks like the only consumer of this API in webbrowser-app.

** Description changed:

  Updating WebView::editingCapabilities isn't cheap if the clipboard
  selection owner changes because we need to read data from the clipboard
  to update the paste bit. Previous experience suggests this can take
  >100ms in some cases. This used to be a bigger problem, although it was
  improved significantly by caching clipboard status.
  
  However, as part of bug 1666002, we're going to be refreshing
  WebView::editingCapabilities from more callbacks. This is wasteful, and
  I'd prefer we just stopped doing it.
  
  In addition to this, CanUndo and CanRedo are always unset, because there
  is currently no visibility of this on the browser side and no way to get
  notifications for them from blink.
  
  What we should do is:
  - Stop continuously updating WebView::editingCapabilities.
- - Add a new method to WebView to trigger an asynchronous refresh of the WebView::editingCapabilities. property. Applications can call this when displaying a UI that requires it (such as a window menu).
+ - Add a new method to WebView to trigger an asynchronous refresh of the WebView::editingCapabilities. property. Applications can call this when displaying a UI that requires it (such as a window menu). This will perform a renderer round trip to get the undo/redo capabilities from blink.
  - Refresh WebView::editingCapabilities when displaying the touch editing UI, to avoid breaking what looks like the only consumer of this API in webbrowser-app.

-- 
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/1666866

Title:
  Stop continuously updating WebView::editingCapabilities

Status in Oxide:
  Triaged

Bug description:
  Updating WebView::editingCapabilities isn't cheap if the clipboard
  selection owner changes because we need to read data from the
  clipboard to update the paste bit. Previous experience suggests this
  can take >100ms in some cases. This used to be a bigger problem,
  although it was improved significantly by caching clipboard status.

  However, as part of bug 1666002, we're going to be refreshing
  WebView::editingCapabilities from more callbacks. This is wasteful,
  and I'd prefer we just stopped doing it.

  In addition to this, CanUndo and CanRedo are always unset, because
  there is currently no visibility of this on the browser side and no
  way to get notifications for them from blink.

  What we should do is:
  - Stop continuously updating WebView::editingCapabilities.
  - Add a new method to WebView to trigger an asynchronous refresh of the WebView::editingCapabilities. property. Applications can call this when displaying a UI that requires it (such as a window menu). This will perform a renderer round trip to get the undo/redo capabilities from blink.
  - Refresh WebView::editingCapabilities when displaying the touch editing UI, to avoid breaking what looks like the only consumer of this API in webbrowser-app.

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