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 -- Mailing list: https://launchpad.net/~ubuntu-webapps-bugs Post to : ubuntu-webapps-bugs@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-webapps-bugs More help : https://help.launchpad.net/ListHelp